By Paul Preiss
I have been thinking about this one for a while. Mostly because I keep watching organizations spend enormous energy designing services and then wondering six months later why nothing changed. The business case looked great. The architecture was solid. The services went live. And then… nothing. Or at least nothing anyone can prove.
Here is what I think is happening. We have confused services with APIs. And we have separated services from the one thing that actually makes them matter: benefits realization.
The BTABoK is pretty clear on what a service actually is. Not an endpoint. Not a container. A logical representation of a repeatable business activity with a specified outcome, self-contained, and a black box to whoever consumes it. The consumer doesn’t care how it works. They care what they get from it. And so does the organization that funded it.
If you can’t connect the service to an outcome someone actually cares about, you haven’t designed a service. You’ve designed infrastructure with ambitions.
The Visibility Problem
Here is the thing that drives me crazy. In most organizations there is almost zero visibility between what the average team builds on a Tuesday and the organization’s mission. Zero. People are working hard, delivering things, hitting sprint goals, and the connection to actual value just… isn’t there. Or isn’t measurable. Which is the same thing.
The BTABoK calls this a visibility problem. And the answer it proposes is Value Management. I know, blah, another acronym, but the idea is genuinely useful. It is an iterative method for making sure investments keep returning value rather than declaring victory at go-live and moving on.
What makes it different from most benefits tracking I have seen is the insistence on three types of indicators, not one. And this is where most programs get it badly wrong.
Three Types of Indicators. Most Programs Use One.
Most organizations track lagging indicators. Revenue went up. Cost went down. Customer satisfaction improved. These are fine. They are also useless for governing an investment while it is happening. By the time a lagging indicator moves, you have already spent the money.
The BTABoK’s method requires three:
Early Validation Indicators. Things you can measure in the first 30 to 90 days. If you can’t identify anything measurable in the first month, I would argue you don’t have a clear enough service design. These exist to tell you fast whether you are on the right track before the whole investment is committed.
Leading Indicators. Things you measure between 90 days and a year. A good leading indicator should be predictive. If the leading indicator is healthy and the lagging indicator doesn’t move, your causal model is wrong. Which is useful to know.
Lagging Indicators. The end result. Did it work? These matter. But they can’t be the only thing you’re watching.
The BTABoK is explicit that these must chain. Early indicators connect to leading indicators. Leading indicators connect to lagging indicators. Lagging indicators connect to objectives. Break any link and you can’t govern the investment. You can only hope.
And architects are supposed to be the people who build that chain. Not document it. Build it. Own it. Govern it.
The Service Contract Is Important. Start Treating It That Way.
The BTABoK describes a service contract as three things: a service level agreement, a service specification, and a commercial agreement. Most teams treat the contract as a handoff document. Something you write so the consuming team knows how to call the API. Done.
That is completely wrong and we need to stop doing it.
The service specification lists what the service actually delivers to its consumer. That is your starting point for benefits traceability. If you cannot write down what the service delivers in plain language, you cannot define what benefit it is supposed to generate. And if you can’t define the benefit, you cannot define the leading indicators. And if you can’t define the leading indicators, you are running a hope-based architecture program.
The SLA defines quality of service. Availability. Performance. Security. Support response. These translate directly into your early validation indicators. Is the service performing at the committed level in week two? If not, the service is not delivering its contract. And the benefit case is already at risk before the business even knows there is a problem.
Every service you design should have an answer to three questions before it goes live. What can I measure in the first 30 days that tells me this service is working? What leading indicators over the next year tell me the benefit is on track? What lagging indicator is this service supposed to move? If you can’t answer those three questions, the service isn’t ready. The design isn’t done.
Service Design Mistakes That Kill Benefits Realization
I am going to be direct here because I have seen all of these and they are entirely avoidable.
Fragmentation for its own sake. The BTABoK is specific about this. If the overhead of managing your services outweighs the flexibility benefit, you have fragmented too far. Consolidate. There is nothing architecturally heroic about forty microservices when seven would have done it. Especially when you can’t trace any of them to a benefit.
No service catalog. If your consumers can’t find your services, reuse doesn’t happen. You reinvent. You duplicate. You waste. The BTABoK describes a service landscape as the map of all services across the organization. Without it you don’t have a service architecture, you have a pile of APIs with documentation stored in someone’s head.
Benefits tracked at program level but services are the delivery unit. This one is subtle and it kills you slowly. If benefits are measured at the program and services are what actually get built, you can never attribute value to a specific capability. You can’t govern at the right granularity. Underperforming services stay funded. High-value services don’t get the investment they deserve. The VALUE MAP doesn’t work if the unit of measurement and the unit of delivery don’t match.
Stateful services at scale. If your SLA commits to availability and your service maintains consumer state, you have created a scaling problem that will eventually become a benefits problem. When the service can’t scale to meet the committed level, the early validation indicators fail. And they fail quietly, because nobody built them in the first place.
The Architect Owns the Traceability. Not the PMO. Not Finance. You.
The BTABoK maturity model for benefits realization starts at a place most organizations recognize: value is claimed, rarely confirmed, no benefits register, nobody owns the outcomes. It ends at a place most organizations have never seen: benefits tracked across the full lifecycle, reinvestment driven by data, enterprise benefit optimization reported regularly.
Getting from one to the other is an architecture function. Not a project management function. Not a finance function. Architecture.
The architect maintains traceability from technology strategy to outcomes. The architect enables scenario modeling for investment decisions. The architect ensures governance requires benefit traceability before more funding is released. The BTABoK is not subtle about this. It is the architect’s job.
And yet most of the conversations I have with architecture teams, benefits realization either belongs to the PMO or to nobody. And then everyone is surprised when the portfolio review can’t answer whether the last three years of investment delivered anything.
The Value Map Is a Living Document.
The Rapid Value Management method in the BTABoK produces a value map. A canvas that shows which programs, capabilities, and services connect to which objectives and ultimately to the mission. This is not a document you create at kickoff and present to a steering committee. It is updated at minimum every two weeks. Investments that show early value continue. Investments that don’t get restructured or stopped.
I know what you are thinking. That sounds like a lot of governance overhead. It is not. The BTABoK says the first version of this canvas should take three hours. Three hours to have a defensible map of how your technology investments connect to the mission. If your organization can’t find three hours for that, the problem is not the method.
The service domain canvas in the BTABoK asks you to state the value of each service, its strategic intention using the TIME model (tolerate, invest, migrate, eliminate), and its dependencies. If you have done that work, you have most of what you need for a benefits register. The information is already there. It just isn’t being used that way.
Look. I have been fighting for this profession for a long time. And one of the clearest patterns I have seen is that when architecture cannot demonstrate its value in terms an executive can verify, architecture gets cut. Or ignored. Or replaced by a vendor promise that sounds a lot more concrete.
Services and benefits realization are two sides of the same thing. The service is the delivery unit. The benefit is the reason it exists. You can’t run one without the other and call it architecture.
Start building the chain. Define your indicators before the service goes live. Update the value map. Own the traceability. That is the job.