Let's talk about IT homologation

According to Wikipedia, homologation is the granting of approval by an official authority. For an IT department, this means determining which products are authorized, available and supported. Having an homologation process helps your IT department transition to a services organization. Approved products support the services provided; and the means of obtaining them must be known . Because, let's not forget, your purpose is to support activities and needs by allowing users the optimal use of the IT resources and tools made available to them.

IT homologation involves four elements.

1. Responding to users requests for new products. For example: A request for new software or equipment for a specific need, how and what to respond?

2. Making cloud solutions accessible. Rather than wanting to block everything, open a space (software center, business store) in which users can upload and install applications that you have previously homologated and approved.

3. Managing the life cycle of the products supplied . A new version of software is available, the old version is no longer supported. What are you doing ?

4. Defining and applying homologation rules and criterias that are consistent with the enterprise architecture and IT governance.

Properly managing an IT services requires establishing what product are available and are effective. This involves publishing a product repository (both software and hardware), updating it and, above all, making it accessible to users. This ensures better communication with customers and business sectors; who can consult and request the products they need from those available.

The product repository will help you define your service offering according to the solutions (hardware and software) on the market, and select and approve those selected and in force in your organisation. You thus play the role of facilitator by selecting products that meet the different needs according to your approval criteria. This implies some rules , for example The products supplied and approved:

1. Must be related to the business needs and professional activities of your organization's users.

2. Must not offer features covered by products already available in the product repository.

3. Must be compatible with your workstations and the technological architecture of your organization.

4. Must be available in a supported version; products offered as free, open source or public domain software must have reasonable assurance of quality (review, price and awards) and support (forum, community, FAQ, links with developers, etc.).

5. Must meet your procurement rules (CAPEX, OPEX). From an accounting perspective, purchasing a product is different from taking out a subscription.

6. Must be free of cybersecurity risks and subject to security advisories.

7. Must have been tested (functional, acceptance, integration).

8. Must be able to be deployed automatically.

9. Must not alter the conditions of provision of the services provided; particularly in terms of capacity, availability and continuity of operations.

10. Must be legitimized by a license or right of use recognized by the manufacturer or supplier.

11. If required, must meet your organization's language requirements.

Four triggers allow the repository to be updated:

1- New products

New products added based on requests for services for which favorable decisions have been rendered. These decisions must be supported by established and known principles; this is to avoid arbitrary decisions. A client wants a tool to manage calls for tenders. Monitor the market, recommend a product and obtain approval for the one selected.

2- Standardization of your fleet

To facilitate support and operation, you must standardize the best solution or product among those available and installed in your fleet. For example, you might decide that PDF Element is the preferred PDF editing software. It is thus supported, installed and supported by the IT department. Other PDF document editing products will then be retired.

3- The product life cycle

As a responsible service provider , you cannot provide obsolete products (even if they still work). Let's not forget that using end-of-life or no longer supported products increases your technology debt and can be a source of incidents, threats and vulnerabilities.

When a new version is available, you should check if:

• You adopt it, by approving it, and by approving the change, the conditions of use and support, the technological prerequisites and, if applicable, the conditions of obtaining (subscription, license, SAAS, etc. premise, etc.).

• You replace the product with another equivalent, more efficient or less expensive, etc., that we have approved.

• You abandon it. The product is removed and uninstalled.

• Accept the risk and keep the product available.

4- Security risks

Frequently, products are subject to vulnerability and present risks. You must analyze the situation and take action. So, depending on the case, you can decide to:

• Remove the product, for example, block TikTok.

• Apply a manufacturer's patch.

• Replace the product with an equivalent product.

• Accept the risk and keep the product available.

Your repository will then be updated to reflect the situation.

Supplement to the service catalog

The publication of the repository of products available at the DTI is a complement to your service catalog . The two go together. For example, the desktop service is described in the catalog, while the product repository informs users of available software. By managing available products, you move towards a service mode through which you can better serve your customers and users. This allows :

1. A better established customer-supplier relationship.

2. Product delivery and query execution more efficient and transparent.

3. Better user support .

4. La réduction du Shadow IT.

5. Controlling cybersecurity risks .

What do you think? Any questions, do not hesitate to write to me..