How to identify technology dependencies in your company

What a technology dependency is and why it matters to identify it

Identifying a company's technology dependencies means knowing which systems, suppliers and integrations the operation depends on and what happens if any of them fails, changes or becomes unavailable. To do this, the company starts from critical processes and, for each one, records the platforms, external services, connections and people it depends on, and assesses the impact and the available alternative in each case.

Depending on systems, suppliers and integrations is part of any company's operation. The risk arises when the impact of that dependency is not known, no alternative has been defined or nobody knows how to act in the face of a failure.

What types of dependency exist

System dependencies are the most obvious: the invoicing process depends on the invoicing software, and order management depends on the management system. Supplier dependencies include services hosted outside the company, such as hosting, email or third-party platforms, over which the company does not control maintenance or evolution. Integration dependencies are more discreet: an integration between two systems may be the only way for information to reach a process and, if it stops working, the process halts without either system being broken.

There are also dependencies on people, when the knowledge needed to operate or change a system sits in the memory of a specific employee or supplier, a topic we covered in the article on what should be documented in a technology project.

Often, several types coincide in the same process: it depends on a system, on an integration built by a supplier and on a person who knows how to fix it. These categories help show how dependencies relate to one another and which of them can compromise operations.

Starting with processes to identify dependencies

Listing the tools the company uses gives an incomplete picture, because it does not show what depends on what. A more useful starting point is the processes the operation cannot do without, such as invoicing, receiving orders, serving customers or paying suppliers. For each one, it is worth knowing which systems, external services, integrations and people it depends on, and what stops working if one of those dependencies fails.

It also helps to distinguish two timescales: one is how long the company can keep the process going without a particular system or service, and with which alternatives; the other is the time needed to restore operation or replace the solution, and who can do it. A company may be able to record orders manually for a few hours but not for a week, and replacing a platform can take far longer than restoring a connection. Manual alternatives may allow part of the operation to continue, but they are not necessarily viable for every process or for extended periods.

The answers do not need to be exact. A reasonable estimate, validated by those who work on the process, is enough to rank dependencies by impact and see which need attention first. If nobody can answer one of these questions, that gap is in itself a relevant sign.

Signs of a dependency that deserves attention

Some signs indicate that a dependency deserves attention: the process only works while a particular person is available, there is no alternative, not even a manual one, in case of failure, or nobody knows who is responsible for the account or contract of a service.

Not knowing how long or how much it would cost to replace something also weighs, as do changes in one system that cause unexpected failures in another. A dependency can deserve attention even when only one of these signs is present. What determines how critical it is, above all, is the impact its unavailability could have on operations and the company's ability to respond.

What to do with what has been identified?

Once dependencies have been identified, the company should assess which of them could compromise critical processes, what alternatives exist and how quickly operation could be restored. This analysis makes it possible to distinguish situations that call for preventive measures from those whose risk can be accepted or monitored. The likelihood of failure can be considered when there is enough information to estimate it, but its absence does not prevent priorities from being set.

Reducing may mean creating a manual contingency procedure, documenting the connection and how it works, setting a second contact at the supplier or in the team, reviewing how the systems are integrated, a topic we covered in the article on how to choose how to integrate enterprise systems, or, in the most critical cases, assessing a technical alternative. Accepting is a reasonable option when the impact is low, as long as it is made consciously.

The map should be reviewed when there are relevant changes, such as adopting a new system, changing a supplier or altering a process, because each one can create new dependencies or remove others.

Where InovaDigital can contribute

InovaDigital develops system integration solutions and custom software to respond to companies' specific needs. Where there are dependencies linked to the flow of information between platforms, these skills can help review existing connections, reduce manual intervention and develop solutions better suited to the operation. Priorities should be set according to the impact of each dependency on business processes.

Knowing the dependency before it fails

A company does not need to analyse all its systems at the same time. It can start with the three processes most important to operations and identify, in each, what it depends on. The next step is to assess what would happen in the event of a failure, what alternatives exist and who would be responsible for recovery.

This review makes it possible to identify dependencies that had gone unnoticed and decide where it makes sense to act first. Some dependencies will remain, and it is legitimate that they do, provided the company knows their consequences and is prepared to respond when one of them fails.