The Transformation Diaries Week 8: The Transformation Plan That Survived Contact with Reality
Week 8 of The Transformation Diaries is here. After seven weeks of discovering problems, Westbridge finally has a transformation plan. Then someone asks the most dangerous question: “This looks great. Who’s doing it?” 😄 Apparently, transformation planning also makes slightly more sense over a beer, whisky and ginger beer. 🍺🥃😄
Series: The Transformation Diaries - 52 Weeks Journey (10 articles)
- …
- 8The Transformation Diaries Week 8: The Transformation Plan That Survived Contact with Reality This article
By Monday morning, Westbridge had a transformation plan.
At least, technically, it had several.
There was the original transformation roadmap. The cloud optimisation work. The engineering backlog. Security remediation. Operational improvements. The Well-Architected findings from the previous week.
And somewhere in the middle of all of that sat a CloudFormation stack managing more than fifty Security Groups across more than fifty older applications.
Narayan looked at the whiteboard.
Seven weeks ago, the problem had been understanding what Westbridge needed to transform.
Now they had a different problem.
They had discovered enough things to keep themselves busy for years.
Tom walked into the room carrying coffee.
"How many problems did we finish with?"
"Thirty-seven."
Tom nodded.
"Good."
Narayan looked at him.
"Good?"
"We didn't get to fifty."
Raghu looked up from his laptop.
"Yet."
Nobody laughed quite as confidently as they would have the week before.
Production had been down on Monday.
Thirty-Seven Problems. One Monday Morning.
The production incident had changed the mood.
Until then, many of the findings had been things Westbridge knew it should eventually address.
Too many NAT Gateways.
Hundreds of VPC interface endpoints.
Inconsistent tagging.
Non-production environments running like Production.
Different generations of Infrastructure as Code.
Shared VPCs.
Unclear ownership.
Then came the outage.
One routine firewall change had exposed a central CloudFormation stack managing Security Groups across more than fifty older applications.
Suddenly, words like blast radius, ownership and standardisation weren't architecture terminology.
Westbridge had experienced them.
Narayan wrote the major findings on the whiteboard.
Rachel looked at the list.
"So what do we fix first?"
That was the question everyone had been waiting for.
Unfortunately, everyone had a different answer.
Everything Was Priority One
Sarah naturally wanted the highest security risks addressed first.
Mark was concerned about anything that could cause another production incident.
Priya wanted to tackle automation, IaC consistency and the engineering practices that had allowed some of these problems to accumulate.
Daniel had a different list.
The NAT Gateways and VPC interface endpoints were difficult to ignore when the potential savings alone appeared to exceed $150,000 annually.
Tom wanted to untangle the Security Group stack.
Rachel wanted all of it.
Preferably this financial year.
Narayan listened for a while.
Then he stood up and wrote on the whiteboard:
PRIORITY 1
Underneath it, he started listing everything people had called Priority 1.
The list grew.
And grew.
Tom eventually interrupted him.
"I think you've made your point."
Narayan put the marker down.
"If everything is Priority One, we don't have priorities. We have a queue."
The room went quiet.
Transformation needed ambition.
But ambition without sequencing was just a very expensive backlog.
Fix What Hurts. Fix What Unlocks. Fix What Pays.
Narayan and Raghu spent the afternoon simplifying the problem.
They didn't need another framework with twelve categories and a colourful maturity model.
They needed a practical way to decide what deserved attention.
Eventually, three questions remained on the whiteboard.
What is hurting us today?
Production risk. Security exposure. Operational burden. Things capable of creating another Monday morning.
What is preventing us from moving faster?
Manual processes. Inconsistent IaC. Unclear ownership. Architectural coupling. Things that made every future change harder.
What are we paying for unnecessarily?
Infrastructure that existed because of historical decisions, copied patterns or requirements nobody could now explain.
Some initiatives answered only one of those questions.
The interesting ones answered several.
And one of them had been sitting in front of Westbridge for weeks.
The First Project Was Already Staring at Them
Narayan pulled together three findings that had originally appeared unrelated.
From the cost review:
100+ NAT Gateways.
From the non-production review:
300+ VPC interface endpoints, with a large proportion sitting in non-production environments without a clearly established requirement.
From the previous week's production incident:
50+ Security Groups supporting 50+ older applications, centrally managed through a CloudFormation stack across shared VPC environments.
Three different findings.
Cost.
Networking.
Security.
But the more Narayan looked at them, the less sense it made to solve them independently.
If Westbridge removed NAT Gateways first, redesigned its Security Group model later and tackled VPC endpoints somewhere in between, it risked changing the same environments multiple times without ever agreeing on the architecture it was moving towards.
Instead, Narayan proposed one broader initiative.
Network and Security Simplification.
The objective wasn't simply to delete infrastructure.
It was to establish the target model first.
Where appropriate, internet egress could move toward Westbridge's centralised inspection model rather than every VPC carrying its own exit path.
Interface endpoints could remain where private connectivity was genuinely required and be removed where they had simply been inherited from reusable modules.
Shared VPC dependencies could gradually be reduced where the blast radius justified it.
And application-specific Security Groups could move away from one enormous horizontal control plane and closer to the vertical application stacks that depended on them.
Terraform could become the consistent IaC model as those workloads were modernised.
The Network and Firewall Operations team would still own the network foundations and enterprise guardrails.
But they wouldn't necessarily need to own every application firewall rule forever.
Tom looked at the proposed workstream.
"So NAT Gateways, endpoints, Security Groups, shared VPCs and Terraform."
"That's the general idea."
Tom looked at Narayan.
"You have an interesting definition of simplification."
Raghu smiled.
"First we simplify the architecture."
Tom nodded.
"And then?"
"Then we simplify the slide."
Spend Once. Benefit for Years.
Daniel's question came quickly.
"How much is this going to cost?"
Narayan didn't avoid it.
There would be engineering effort.
Architecture work.
Testing.
Application engagement.
Migration planning.
Potentially months of carefully sequenced changes.
Nobody should touch a stack connected to more than fifty applications because a PowerPoint said the target architecture looked cleaner.
"That's the right question," Narayan said.
Then he added:
"As long as we also ask what it costs us not to do it."
The networking findings alone had indicated more than $150,000 in potential annual savings.
One year mattered.
Five years changed the conversation.
And that was before considering future growth, operational effort, reduced blast radius, stronger security boundaries and fewer unnecessary components to support.
Daniel looked at the numbers.
"So we're spending money now to stop spending money every year?"
"Pretty much."
Daniel smiled.
"Finance really needs better terminology for that."
But there was another way Narayan wanted them to look at it.
Westbridge had several large technology decisions ahead of it. VMware and the increasing cost of Broadcom licensing was one of them.
Perhaps Westbridge would ultimately reduce that footprint significantly.
Perhaps some workloads would migrate.
Perhaps there would eventually be no reason to renew parts of it at all.
But if the business did decide to retain or renew some of that estate, money recovered elsewhere created options.
Savings weren't required to disappear into a finance spreadsheet.
They could fund the next migration.
The next modernisation initiative.
Security improvements.
Automation.
Or help offset another unavoidable technology cost.
Over several years, recurring cloud savings could become meaningful financial capacity against something as substantial as a future Broadcom licensing decision.
Narayan wrote another sentence on the board:
Transformation isn't only about finding savings. Sometimes it's about deciding what those savings allow you to do next.
That was Value Realisation again, the 7th Pillar Narayan has been referencing from last 2-3 weeks of WAFR exercise.
Not another architecture pillar to score but a way of connecting technical improvement to what Westbridge could do because of it.
Not Everything Needed a Project
There was another problem with transformation programmes.
They had a habit of turning every problem into a project.
Narayan didn't want thirty-seven findings to become thirty-seven project codes.
Some findings needed programmes of work.
Some needed architectural decisions.
Some belonged in engineering backlogs.
Some could become standards.
Some risks might even be consciously accepted.
And some simply needed someone to fix them.
The CloudWatch investigation from the earlier cost review was a good example.
The team had finally traced a disproportionate amount of logging cost back to a Lambda workload generating enormous volumes of debug logging.
Nobody needed a steering committee for that.
Tom looked at the finding.
"So what's the transformation programme called?"
Narayan thought for a moment.
"Turn Off Debug Logging."
"How many phases?"
"One."
"Architecture review?"
"No."
Tom looked disappointed.
"Consultants really are changing."
Some problems deserved transformation, others deserved a pull request. Knowing the difference mattered.
This Looks Great. Who's Doing It?
By Wednesday afternoon, Narayan had what he thought was a strong roadmap.
Network and Security Simplification.
IaC standardisation.
Ownership and tagging improvements.
Non-production optimisation.
Operational visibility.
Security and resilience remediation.
Application discovery.
Foundational platform improvements.
The sequencing made sense.
The dependencies made sense.
Even the slide looked good.
Narayan presented it.
Rachel liked the direction.
Priya could see how the engineering pieces connected.
Sarah could see the security improvements.
Daniel could see where investment translated into measurable benefit.
Then Mark spoke.
He had been unusually quiet.
"This looks great."
Narayan knew immediately there was another sentence coming.
Mark looked around the room.
"Who's doing it?"
Silence.
The same engineers expected to transform Westbridge were already running Westbridge.
They had incidents.
Patching.
Vulnerability remediation.
Existing projects.
Application releases.
Operational commitments.
Production support.
And, occasionally, a Monday where everything else stopped because Production did.
Narayan looked back at his roadmap.
It was architecturally sound.
Strategically aligned.
Financially defensible.
And probably impossible.
Raghu leaned towards him.
"Contact with reality."
Narayan closed the slide.
"Give me until tomorrow."
Version Two Was Less Impressive
The second roadmap had fewer initiatives.
Some were combined.
Some moved later.
Some became engineering backlog items instead of projects.
Some depended on visibility and ownership work that Westbridge hadn't completed yet.
The Network and Security Simplification initiative remained near the top.
The production incident had established the risk.
The NAT Gateways and endpoints established the financial opportunity.
The security model established the architectural need.
And the same work could improve several Well-Architected areas while producing measurable business value.
Other initiatives would follow when the foundations and people were ready.
The new roadmap didn't fit quite as beautifully on one slide.
The timeline was longer.
There were fewer impressive arrows.
Narayan liked it considerably more.
The first roadmap showed everything Westbridge wanted to change.
Mark looked through it again.
"This I can staff."
For Narayan, that was worth considerably more than another green status box.
For the first time since he had arrived at Westbridge, transformation wasn't simply something people were discussing.
It had work attached to it.
Three Drinks and a Transformation Plan
By Friday evening, Raghu decided they'd seen enough architecture diagrams for one week.
They ended up at a pub nearby.
Tom ordered a beer.
Raghu ordered whisky.
Narayan ordered a ginger beer.
Tom looked at him.
"Ginger beer?"
Tom looked across the bar at the rows of bottles.
"You know, this is basically our roadmap."
Narayan already regretted asking.
"How?"
Tom pointed at his beer.
"Quick win."
Then Raghu's whisky.
"High priority."
Then an expensive bottle on the top shelf.
"Strategic initiative requiring executive approval."
Raghu nodded. "He's learning."
Narayan looked across the bar.
Dozens of choices. They couldn't have everything just because everything was available.
Some things made sense now. Some could wait. Some they didn't need at all.
Transformation wasn't that different.
Narayan: "You can't do everything at once."
They laughed.
Tom raised his beer.
"At least a bad decision here only takes us down."
Raghu looked at him.
"Unless you put all fifty drinks in one CloudFormation stack."
Tom raised his glass.
"UPDATE_COMPLETE."
Narayan lifted his ginger beer.
"Tomorrow morning disagrees."
Eight weeks in, Westbridge hadn't solved everything.
But they had finally stopped trying to solve everything at once.
Next Week: You Can't Transform What You Can't See
Series: The Transformation Diaries - 52 Weeks Journey (10 articles)
- …
- 8The Transformation Diaries Week 8: The Transformation Plan That Survived Contact with Reality This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article