Every enterprise I have worked with has a service catalogue. It is a spreadsheet that was last updated in 2022.

I know this because I have inherited them. Multiple times. At a large retailer, the service catalogue was an Excel file with 340 rows, no owner column, and a "last reviewed" date field that was blank for 60% of the entries. At a public sector organisation, it was a Confluence page with a table that somebody had copy-pasted from SharePoint two years earlier. At a government department, there were three competing catalogues maintained by three different teams, none of which agreed on the total number of services the organisation operated.

The service catalogue is one of the most valuable assets an IT organisation can maintain, and one of the most consistently neglected. Not because people do not recognise its value, but because the way most organisations build them guarantees they will decay.

This article is about building a service catalogue that stays alive. Not the theory — the practice.

Why service catalogues die

Service catalogues fail for three reasons, and they are the same three reasons every time.

No ownership model. The catalogue is created as a project deliverable. An enterprise architect or service management team builds it, populates it, and presents it to leadership. Everyone agrees it is valuable. Then the project ends, and nobody is responsible for keeping it current. Six months later, three new services have been deployed without being added to the catalogue, two services have been decommissioned without being removed, and the data quality has degraded past the point of usefulness.

No audit trail. Nobody knows when a service record was last reviewed, who changed it, or why. There is no mechanism to enforce periodic review. The "last updated" field, if it exists, is manually maintained and therefore unreliable. When someone does update a record, there is no history of what changed — just the current state of the spreadsheet.

Disconnected from decisions. The catalogue exists in isolation. It is not connected to the architecture decisions that shape the technology landscape, the suppliers that support the services, the contracts that govern those supplier relationships, or the business cases that funded the services in the first place. Because it is not connected to anything, it is not part of any decision-making process. And because it is not part of any decision-making process, nobody has a reason to keep it current.

A service catalogue that nobody uses to make decisions will not be maintained. Full stop. The data decays because nobody depends on it.

What a modern service catalogue needs

Forget the ITIL textbook definition for a moment. In practice, a service catalogue that actually works needs five things.

Named ownership

Every service needs two named owners: a business owner and a technical owner. Not a team. Not a department. A person. The business owner is accountable for the service's strategic direction and funding. The technical owner is accountable for its operation, security, and architecture.

When I say "named," I mean their name appears on the service record, and they know it is there. Ownership is not meaningful unless the owner knows they are the owner and understands what that means. I have seen catalogues where ownership was assigned by a project team without telling the people listed. That is not ownership. That is a populated field.

Lifecycle status tracking

A service is not a static entity. It moves through a lifecycle: proposed, in development, live, being sunset, decommissioned. Your catalogue needs to track where each service is in that lifecycle, and the transitions between states should be recorded with timestamps and the person who made the change.

This matters more than most people think. I worked with an organisation that had forty-seven services listed as "live" in their catalogue. When we audited, eleven of them had been decommissioned. Three had never actually gone live — they were pilot projects that were quietly abandoned. The catalogue said they were all running, so the risk assessment treated them all as active dependencies. The risk picture was fundamentally wrong.

Criticality classification

Not all services are equal. A service that processes customer payments is not the same as an internal wiki. Your catalogue needs a criticality classification that reflects the business impact of service failure.

Keep it simple. Three tiers works for most organisations:

  • Tier 1: Critical — Failure directly impacts customers, revenue, or regulatory compliance. These services need the highest resilience, the most frequent review, and the tightest supplier SLAs.
  • Tier 2: Important — Failure causes significant operational disruption but does not immediately impact customers. These need robust monitoring and documented recovery procedures.
  • Tier 3: Standard — Failure is inconvenient but manageable. These can tolerate longer recovery times and lighter governance.

The criticality classification should drive everything downstream: how often the service is reviewed, what supplier SLAs are required, how much redundancy is built in, and what the incident response looks like.

Dependency mapping

Every service depends on other services, and other services depend on it. These dependencies are where the real risk lives. A Tier 3 service that is a dependency of four Tier 1 services is not really Tier 3 — it is a hidden critical path.

Dependency mapping answers the question that matters most during an incident: "If this service goes down, what else breaks?" Without it, you are doing impact analysis by memory and best guesses. With it, you know immediately which business processes, customers, and downstream services are affected.

At a large retailer, we mapped service dependencies for the first time and discovered that a single internal authentication service — classified as Tier 3 because it was "just" an internal tool — was a dependency for eleven customer-facing services. It had no redundancy, no disaster recovery plan, and no documented owner. If it went down, online banking went with it. Nobody knew this until we drew the dependency graph.

Cost data and commercial links

Every service costs money. Licences, hosting, support contracts, internal labour. Your catalogue should capture or link to the cost data so you can answer basic questions: What does this service cost us annually? Which supplier provides it? What contract governs the relationship? When does that contract expire?

Connecting services to their commercial underpinnings transforms the catalogue from an IT asset list into a management tool. When a supplier raises their prices by 30%, you can immediately see which services are affected, who owns them, and what the business impact would be if you switched providers.

The ownership problem

I said every service needs a named owner. Now let me explain why that is difficult and how to make it work anyway.

The first problem is resistance. Nobody wants to be named as the owner of a service they did not build and do not fully understand. This is especially common with legacy services that have been running for years with no clear lineage. Assigning ownership feels like assigning blame in advance.

The fix is to separate ownership from accountability for historical decisions. The owner is responsible for the service going forward, not for the decisions that created its current state. Make this explicit when assigning ownership. "You are not responsible for the technical debt. You are responsible for knowing it exists and having a plan."

The second problem is enforcement. Ownership is meaningless unless the owner is periodically required to review their service record and confirm it is current. Build this into your governance cycle. Once per quarter, every service owner reviews their record: Is the status correct? Are the dependencies still accurate? Is the criticality classification still right? Have there been any changes?

The review should be lightweight — fifteen minutes per service. But it must happen. And it must be tracked. If a service owner has not reviewed their record in six months, that should be visible to leadership. Not as a punishment mechanism, but as a data quality signal.

Connecting services to everything else

A service catalogue in isolation is an inventory. A service catalogue connected to your governance records is a management tool.

The connections that matter:

  • Services to architecture decisions. Which ADRs affect this service? If you decided to migrate to a new database platform, which services are in scope? The ADR should link to the services it impacts, and vice versa.
  • Services to suppliers. Which supplier operates or supports this service? What is their risk rating? If that supplier has a major incident, which of your services are affected?
  • Services to contracts. What contract governs the supplier relationship for this service? When does it expire? What are the SLA terms? If a contract renewal is approaching, which services depend on that contract?
  • Services to capabilities. Which business capabilities does this service support? This is the bridge between the technology view and the business view. When a business leader asks "what technology supports our customer onboarding process," the answer should come from your service catalogue, not from a three-day discovery exercise.
  • Services to business cases. Which investment funded this service? What was the original business justification? Did the service deliver what was promised?

Each of these connections individually adds some value. Together, they transform the catalogue into the connective tissue of your governance model. When an auditor asks about your technology landscape, or a board member asks about supplier concentration risk, or a CTO asks about the blast radius of decommissioning a platform — the answers are all derivable from a well-connected service catalogue.

Getting started

If you are reading this and recognising your own organisation, here is the practical path forward. I have done this four times across different industries, and the approach that works is always the same.

Step 1: Import what you have. You already have a service catalogue, even if it is terrible. It is in a spreadsheet, or Confluence, or ServiceNow, or someone's head. Import it into a structured system. Do not try to clean it first. Get it in, warts and all. You need a baseline to work from.

Step 2: Validate the basics. Go through the imported data and answer three questions for each service: Is it still running? Who is the business owner? Who is the technical owner? Do not try to answer every question about every service upfront. Get the minimum viable data right first. You will be surprised how many entries in your existing catalogue refer to services that no longer exist.

Step 3: Assign owners and tell them. Assign named owners to every service. Then — and this is the step people skip — tell the owners. Send them their service list. Ask them to review it. Make it clear that this is now their responsibility. Some will push back. That is fine. The pushback usually reveals useful information about organisational structure and accountability gaps.

Step 4: Add criticality classification. With owners assigned, ask each owner to classify their services by criticality. This usually triggers the first round of useful disagreements: "We classified this as Tier 3 but the payments team depends on it." Good. That is exactly the kind of discovery you want.

Step 5: Map dependencies. Start with your Tier 1 services. For each one, identify what it depends on and what depends on it. Work outward from there. Do not try to map every dependency in the entire catalogue at once. Start with the critical path and expand.

Step 6: Connect to suppliers and contracts. For each service, link it to the supplier that provides or supports it and the contract that governs that relationship. This is where the catalogue starts becoming genuinely useful for commercial and risk management.

Step 7: Establish the review cadence. Set up quarterly owner reviews. Make them lightweight but mandatory. Track completion. Report on data quality. The catalogue is only as good as its last review.

You do not need a perfect service catalogue. You need a living one. Eighty percent accuracy maintained quarterly beats ninety-nine percent accuracy that degrades to fifty percent in six months.

The difference between a service catalogue that dies and one that lives is not the technology, the template, or the ITIL compliance. It is whether the catalogue is connected to decisions that people actually make. If it is — if architecture decisions reference it, supplier assessments depend on it, and risk analysis draws from it — then people have a reason to keep it current. And they will.

If it sits in a spreadsheet that nobody opens between audits, no amount of process or good intentions will save it. Connect it. Own it. Use it. That is the entire best practice, distilled.