The How
The methods behind the three services: how a change to a core service gets worked through, and how decisions get made along the way.
Five layers, from the business down
Replacing or modernising a core service touches every layer. Each one has a question to answer before moving to the next, and a trap to avoid.
-
1Business capabilities
What must the new service do, and what should get better?
Map capabilities, not features. Like-for-like is a trap: replicate the needs, not the old customisations and workarounds.
-
2Data
Who owns which data, and is it clean enough to move?
Name data owners, set a single point of entry, and cleanse before migration. Data is the biggest migration risk and the no-regrets work.
-
3Integration
What connects to the service today?
Inventory every interface. Put stable APIs in front so consumers don’t break during the swap, and decide the future of existing middleware explicitly.
-
4Application and technology
What are we choosing, and how?
Agree selection criteria up front: fit, five-year cost, group and platform standards, cloud fit, supportability and exit options.
-
5Operations and support
Will the new service be more reliable than the old one?
Find the root causes of today’s major incidents. Causes in integration, data or change control travel to the new platform unless they’re fixed.
How decisions get made
The same habits on every engagement, whatever the sector.
-
Evaluating options
“If we can’t say what would change our mind, we haven’t evaluated it.”
Criteria first. At least three options, always compared against doing nothing.
-
Making architecture decisions
“Most decisions should be made by the principles, not by me.”
Principles answer most questions by default, so only exceptions need a forum. Decisions are recorded, and the process matches how reversible the decision is.
-
Risk, cost and commercial benefit
“A cheap option that risks revenue isn’t cheap.”
All three in one view. Ranges, not single numbers. Cost of delay included, and a named owner for each risk.
-
Strategic prioritisation
“If everything is priority one, nothing is.”
Every item tied to a business goal, weighed on value, cost of delay, effort and risk. Honest about capacity, with work in progress kept limited.
-
What to defer, and why
“Deferring is a decision, not neglect.”
Defer when it’s reversible, the cost of delay is low, it depends on an unresolved decision, or waiting lets you learn cheaply. Never defer security, compliance or basic data quality. Every deferral is recorded with a revisit date.
-
Best practice versus business need
“I’ll bend a standard for the business, but never by accident.”
Best practice is the default, not a rule. Departures are deliberate, with a recorded reason, an owner and a way back, and tracked as technical debt.
-
Working with partners
“A sound integration with a poor contract behind it still fails.”
Technical alignment to the roadmap and commercial accountability after signature are managed together, not by separate teams.
See how it would apply to you.
A short conversation about your situation, not a pitch deck.