IT Cost and Supplier Risk: Contracts, Applications and Critical Functions
Finance tracks contracts and their cost; the risk function tracks ICT providers. Both views concern the same applications. A shared repository connects these objects and shows the costs, end dates and dependencies to review.
Updated on
Two questions about the same objects
Finance tracks the cost of the application estate in a budget. The risk function tracks ICT providers in a register. Both files describe the same applications, contracts and suppliers, often with different names and dates.
While the files stay separate, someone reconciles them by hand. An application flagged for renewal may also depend on a provider that supports several critical functions. That link only appears when the contract, the application and the function are connected in the same repository.
The contract, its supplier and the applications it covers
In ArchiLU, a contract is linked to its supplier and to the applications it covers. The Contracts page shows the supplier, annual cost, end date and any automatic renewal detected. When a contract covers several applications, its cost is allocated to each one with the reasoning for the split.
Each application carries its owner, criticality, lifecycle and supplier. The capability map calculates the licence cost of each capability from its applications. The CIO dashboard brings together contract commitments by currency and technology support deadlines.
Amounts come from contracts and accounting records. An unknown amount stays unknown: the portfolio review never counts it as zero.
Concentration and supplier dependency
A single dependency looks reasonable on its own: running one critical function with one cloud provider is an architecture choice. Twelve critical functions with the same provider form a concentration that often builds up without an explicit decision. Seeing it means following each function to its applications, then to their providers.
ArchiLU’s exposure analysis starts from an application or a provider and works up to the critical or important functions that depend on it. It calculates its findings: concentration, obsolescence, critical objects without an owner and open exceptions. Each finding leads to a request, a risk or a Board decision.
Each capability shows its dominant supplier and that supplier’s share. The provider record holds its substitutability and exit plan. These elements document the analysis; risk assessment and contract negotiation remain with the risk, procurement and legal functions.
From the map to a rationalisation decision
A rationalisation candidate often combines several signals: a high cost, a capability already supported by another application, a supplier the organisation relies on heavily. These signals can be read together when cost, capability and supplier are attached to the same object.
In ArchiLU, the application owner proposes a TIME class with a reason, and the enterprise architect confirms it. Before a retirement, the 360 view shows the processes, interfaces and contracts that depend on the application. Retirement follows four steps: impact, replacement, decision and execution.
- Identify the applications where cost, duplication and supplier exposure overlap.
- Check their criticality and dependencies before any retirement.
- Record the decision and its reasoning against the applications concerned.
- Follow estimated and then realised savings in the portfolio review, each with its period and currency.
DORA: documentation, not a certificate
DORA requires financial entities to manage ICT third-party risk, to distinguish arrangements that support critical or important functions and to keep a register of information. A chain already maintained from function to contract supplies part of the data for this work.
In ArchiLU, each function carries its criticality under DORA. The chain links that function to its processes, applications, ICT services, providers and their contracts. It documents the dependencies needed for the register of information. Compliance is assessed by the entity, its auditors and the competent authority.
Context for a regulated EU entity
A map linking critical functions, suppliers and costs is sensitive information. In ArchiLU, each organisation has its own dedicated instance, hosted in the European Union; deployment on your infrastructure is an optional service, quoted separately. ArchiLU is published in Luxembourg by MIP-IT SARL.
Finance, risk, procurement and architecture read the same map. Screens, tasks and help are available in French, English and German.
In ArchiLU
Frequently asked questions
- What is ICT concentration risk?
- It is the exposure that builds up when several critical or important functions depend on the same provider: one cloud provider, one core banking vendor, one data centre. DORA requires financial entities to identify and manage this risk. A repository shows where dependencies cluster; it does not make the entity compliant.
- How are contract costs linked to applications?
- The contract is linked to the applications it covers, and its cost is allocated to each one with the reasoning for the split. The capability map derives the licence cost of each capability from it. The portfolio review shows the cost of the retirement candidates.
- Does ArchiLU make an entity DORA compliant?
- No. ArchiLU documents the chain from critical function to contract, calculates the exposure analysis findings and produces the register of information as a regulatory report. Compliance is assessed by the entity, its auditors and the competent authority.
- Why combine cost and supplier risk in one repository?
- Both views concern the same objects. The most expensive application sometimes depends on the supplier the organisation relies on most. When the application is linked to its contract and supplier, one view answers both the CFO and the risk function.