IT Cost and Supplier Risk: One Map for Money and DORA

Two questions, one inventory

Ask a regulated firm two questions and you usually get two unrelated answers. "What does our application landscape cost?" goes to finance, who open a budget spreadsheet. "Which third parties are we exposed to?" goes to risk, who open a supplier register. Both answers are built from the same underlying objects — the applications you run and the suppliers behind them — yet they live in different files, owned by different teams, reconciled by hand if at all.

That split is expensive in both directions. The CFO cannot see that the application flagged for renewal is also a single point of vendor dependence. The risk officer cannot see that the supplier they are over-concentrated on is also the one quietly inflating the run-rate. Each team optimises its own view and misses the obvious move that only appears when cost and supplier exposure sit on the same map.

This article is about closing that gap with one model. An enterprise architecture repository is, at heart, an inventory of what you run and how it connects. When that inventory carries cost signals on one side and supplier links on the other, a single question answers both teams at once — and, not incidentally, produces the kind of evidence a DORA-minded review expects.

What an application portfolio view actually holds

An EA application register is more than a list of names. Each application can carry attributes that turn it into something you can reason over: an owner, a criticality rating, where it is hosted, the technology it sits on, the suppliers it depends on, and cost signals. ArchiLU's application portfolio capability is built around exactly this — application health, supplier exposure, technology footprint, cost signals and rationalisation candidates — so the register is an analytical surface, not a static catalogue.

The point of attaching these attributes in one place is the joins they enable. Because an application points to its supplier and carries its cost, you can pivot the same data set into a cost view, a supplier-exposure view or a rationalisation shortlist without rebuilding it. The honest caveat: the model is only as good as the data you put in it, and cost figures in particular need a real source — finance feeds, contracts, license counts. The repository organises and connects that data; it does not invent it.

• Application register with owner, criticality and hosting
• Supplier and vendor links per application
• Technology footprint, so you can see platform sprawl
• Cost signals attached to the same objects, from real sources
• Rationalisation candidates surfaced from the combined picture

Surfacing concentration and license exposure

Concentration risk is hard to see precisely because each individual dependency looks reasonable on its own. One critical function on one cloud provider is a sensible architecture decision. Twelve critical functions on the same provider is a concentration you may not have chosen deliberately — it accreted. The only way to see it is to follow every critical function down to the supplier behind it and count where the lines converge.

A mapped model makes that count mechanical instead of archaeological. Trace each critical or important function to its applications, each application to its suppliers, and the clusters appear: the vendor that sits behind a disproportionate share of what matters, the platform that quietly became load-bearing. The same model surfaces license exposure from the other direction — where you are paying for seats or capacity you no longer use, and where a single contract underpins more than its price suggests.

None of this is a compliance verdict, and we will keep saying so. DORA compliance is decided by regulators and auditors against your measures, not by a chart. What the model gives you is sight: a defensible, current view of where dependencies and money concentrate, which is the input to the risk and contractual work — not a substitute for it.

From the map to a rationalisation decision

The combined view earns its keep when it changes a decision. A rationalisation candidate is rarely just "the expensive one" — it is the application that is expensive and duplicated and tied to a vendor you are over-concentrated on. That triangulation is invisible in any single spreadsheet and obvious on a model where cost, duplication and supplier sit on the same object.

The practical workflow is unglamorous and that is the point. Shortlist candidates from the combined picture, check each against its criticality and dependencies so you do not retire something load-bearing, then record the decision — context, options, choice, rationale — against the affected applications. The map proposes; the human disposes; the decision record keeps the trail. That trail is what turns a one-off cost cut into a documented, repeatable governance act.

• Shortlist where cost, duplication and supplier exposure overlap
• Validate against criticality and dependency maps before retiring
• Record the decision against the affected applications
• Keep the trail so the next review starts from evidence, not memory

The DORA-minded view: documentation and evidence, not a guarantee

Under DORA, regulated financial entities are expected to know and document their ICT dependencies, identify those supporting critical or important functions, and manage third-party and concentration risk. A repository that already maps applications to functions, suppliers and cost is producing that documentation as a by-product of how it is used, rather than as a separate annual scramble.

We are deliberate about the limit. ArchiLU does not ship a prebuilt DORA control library or a certification, and it would be dishonest to imply otherwise. What it offers is the analytical and documentary backbone — the current, connected model from which evidence is faster to assemble. Treat it as an aid to your risk, legal and security work, not a replacement for it; the regulatory determination stays with the people and the contracts, where it belongs.

Why this fits a regulated EU institution specifically

Three of ArchiLU's properties matter more in a regulated European context than anywhere else. It can be hosted in the EU or on-premise, so the sensitive map of what depends on what and what it costs does not leave a boundary you control. It is available natively in French and English, which matters when the same model has to serve a French-speaking risk committee and an English-language audit. And it is licensed for unlimited users rather than per seat, so the finance, risk and architecture people who all need to read the same map are not gated by a seat count — if you want the commercial detail, it lives on the pricing page rather than here.

The combination is the wedge: a sovereign-hostable, multilingual repository where cost and supplier exposure share one model. For the fastest read on where your own practice stands across portfolio, governance and risk dimensions, the free EA Maturity Assessment scores ten dimensions and returns a prioritised plan in about ten minutes — a sensible first step before deciding whether to see the portfolio view on your own data in a demo.