540 days after request
Late in the refresh diagnostic, the renewal architecture was displayed on three slides.
The first showed the customer journey: a row of pale boxes connected by arrows. The second showed applications: Digital Renewal, Rating, Policy Administration, Documents, Payments and Customer Contact. The third showed services. There were forty-seven of them, which created the impression that the company had decomposed the problem with unusual thoroughness.
The customer correction touched eleven.
Some services owned their data, several shared the policy database, two wrote different representations of renewal state, one had been separated from the policy system so that it could be released independently but still could not be meaningfully changed without a coordinated database migration, and another existed mainly to translate the event emitted by a third into the language expected by a fourth.
The diagram described independent boxes. The release plan described a convoy.
The senior engineer who had drawn the real process showed Felix a change from the previous year. A new underwriting question had altered the web journey, rating request, policy record, adviser screen, document and audit event. Six teams had made compatible changes across four release windows. The work spent twelve days in development and fourteen weeks waiting for joined decisions and environments.
“The promise was that microservices would give teams autonomy,” Felix said.
“Each service team can release its own box,” the engineer said. “The trouble is that the customer change is not inside any one box. So the services are autonomous, if that is what we are measuring. I still need six teams to change renewal.”
When the architecture problem was made visible, an executive offered the customary correction.
“Nobody pays us to have the perfect architecture.”
He was right about the invoice. Customers do not buy dependency graphs. They buy a service that improves, works when required and recovers when it fails. Regulators expect the institution to control changes and account for their effects. The best employees expect their work to reach a useful result often enough that ambition remains a rational habit.
Architecture is the arrangement that makes those things easier or harder. It had already charged the insurer through delayed changes, incidents, duplicate state, programme staff and engineers paid to wait. It had merely used several cost codes, which gave the bill a reassuringly distributed appearance.
At another company Felix later heard the sentence, “There is deliberately no deliberate design.” There, hundreds of engineers could deploy microservices while struggling to alter a complete outcome. The absence of a named architect had not suspended cause and effect. Reporting lines, access policies, platform mandates, budgets and urgent exceptions had designed the system by default.
There is no no-design. There is deliberate design and default design. The absence of competence is not an absence of architecture; it is architecture selected without understanding its consequences.
The pattern becomes easier to see in an imaginary restaurant. Suppose management notices that the kitchen uses oil, the bar vodka, the dining room water and the cleaners soap. All four are liquids, so an efficiency programme creates a Liquid Department.
The department standardises containers, centralises procurement and introduces a request form. Its utilisation is excellent. Unfortunately, the bartender cannot make a drink when a cooking-oil order occupies the shared queue, and the kitchen cannot get vinegar while the department is responding to a spill. A lift failure stops dinner, drinks and cleaning simultaneously, so management improves the service-level agreement.
The insurer's shared release and platform queues were less absurd mainly because their names were familiar.
Central services are not inherently foolish. Scarce expertise, aggregate risk, network effects and scale can justify them. The Liquid Department fails because its boundary follows a property of the inputs rather than the outcomes that must change and recover independently. Oil and vodka are both liquids; they belong to different operating purposes.
The same mistake appears in companies with Data, Platforms, Change, Customer Communications or Engineering treated as internally uniform substances. A centre pools something that looks technically similar, declares local copies to be duplication and measures its own efficient use. Operating units inherit the queue and common failure domain. When they route around it, the centre discovers a governance problem.
The design test asks whether the chosen boundary contains what must normally change together while keeping genuine constraints explicit. A payment ledger may remain a shared institutional service because consistency, settlement and fraud control matter across products. It should publish a contract that lets a renewal unit use it without seeking permission for each ordinary journey change. A risk function should retain an independent stop right for defined exposure, not an informal right to redesign every feature.
After the consultancy engagement Felix moved to a logistics client. Marianne said he had become very good at converting difficult findings into executable programmes. She meant it as praise and, by then, it was true.
The mileage request stayed with the insurer. So did the slides, the forum and the architecture.
547 days after request
By the eighteenth month in the portfolio, the chief operating officer asked Lisa Morgan, a newly appointed executive, why a customer still had to telephone to correct a number already displayed on the screen.
Lisa's account begins there. Felix was no longer in the building, although parts of his work were. What follows was reconstructed from the process register, charter, decision and release records, then checked in later interviews with Lisa and the people around her. Where the narrative reports what she expected or noticed, she supplied the account. The records supply the parts memory tends to improve. Where records and a witness disagree, both appear.