The Transformation Diaries
Trying something a little different. :) The Transformation Diaries — 52 Weeks Inside Technology Change. One fictional organisation. One consultant. One year of transformation. The characters may be fictional, but the challenges around cloud, AWS, DevOps, migration, security, modernisation, people and eventually AI are very real. Week 1: Welcome to the Transformation — What does transformation actually mean, and how far does an organisation really need to go? A new chapter every weekend.
Series: The Transformation Diaries - 52 Weeks Journey (10 articles)
- 1The Transformation Diaries This article
52 Weeks Inside Technology Change
I'm trying something a little different.
Over the next 52 weeks, I'm going to tell the story of a fictional organisation going through a year-long technology transformation.
One week. One chapter. Every weekend.
The organisation is fictional. The characters are fictional (well you decide 😉).
The problems are very real.
Cloud. AWS. Legacy infrastructure. Migration. DevOps. Security. Cost. Architecture. Platform engineering. Modernisation. Culture. Skills. And eventually, AI.
But this isn't intended to be 52 technical articles with a fictional story added around them.
Real transformation doesn't happen that neatly. There are people with different priorities. Architecture decisions made years ago for reasons nobody quite remembers. Applications that everyone wants to modernise and applications nobody wants to touch. Budgets. Deadlines. Security concerns. Technical debt. Skills gaps. New technologies. Old technologies.
And somewhere amongst all of that, an organisation is trying to change.
There will be successes, there will be failures, there will be disagreements. Some technology will be introduced at exactly the right time. Some will be introduced too early.
And occasionally, the right transformation decision might be to leave something exactly where it is.
At the centre of the story is Narayan, a Senior Principal Consultant at Enestron Consulting, brought in to help Westbridge Group through a twelve-month technology transformation.
Narayan is an experienced technology consultant, but his journey to get here wasn't a straight one. He arrived in the country years ago as an international student and built his career through opportunities, setbacks, plenty of rejections and a lot of learning along the way. Those experiences shaped not only the consultant he became, but also the way he works with people.
He is technically strong, curious and not afraid to challenge an idea, but he also knows that experience doesn't mean having all the answers. He has a particular soft corner for interns, graduates and people finding their feet — perhaps because he still remembers what it felt like to be one of them.
Westbridge Group is a large privately owned Australasian logistics and infrastructure organisation. It has thousands of employees, more than two decades of technology behind it, a significant AWS footprint and plenty still running outside the cloud.
Over the next 52 weeks, we'll experience Westbridge's transformation largely through Narayan's perspective.
He doesn't know exactly how the next twelve months will unfold.
Nobody walking into a real transformation does.
And while Narayan has been brought in to help transform Westbridge, there's every chance the journey will change him too.
So, welcome to The Transformation Diaries.
Let's begin.
Week 1 — Welcome to the Transformation
For once, the motorway was moving.
Narayan wasn't sure whether to take that as a good sign.
His coffee sat untouched in the cup holder. His laptop bag was beside him, and his suit jacket hung neatly behind the driver's seat.
Somewhere ahead was Westbridge Group.
For the next twelve months, Narayan would be working with Westbridge on what the engagement documents repeatedly called its technology transformation.
He had spent much of the previous week reading.
Architecture diagrams. AWS account inventories. Application lists. Cost reports. Security assessments. Migration plans. Strategy presentations.
Hundreds of pages describing where Westbridge was and where it wanted to go.
And yet one question remained surprisingly difficult to answer.
What exactly was Westbridge trying to transform?
Transformation means different things to different people
Narayan had been working in technology consulting long enough to know that the word transformation was dangerously easy to use.
Digital transformation.
Cloud transformation.
DevOps transformation.
Application transformation.
Data transformation.
Security transformation.
And increasingly, AI transformation.
The problem wasn't the terminology.
The problem was that two people could sit in the same transformation programme and be talking about completely different things.
Westbridge was already demonstrating that.
Rachel Chen, the CIO, viewed transformation primarily through the business.
She wanted technology teams to respond faster when the business needed something. New products shouldn't take months because infrastructure, security and deployment processes couldn't keep up. Technology needed to become an enabler rather than something the business planned around.
For Rachel, transformation meant agility and business capability.
Mark Bennett, Head of Infrastructure & Operations, saw a different problem.
Westbridge still operated ageing infrastructure. Some platforms were expensive to maintain. Knowledge of certain systems sat with a handful of people. There was technical debt accumulated through years of growth and acquisitions.
For Mark, transformation meant simplification, stability and reducing dependency on legacy technology.
Priya Nair, Head of Engineering, looked at the same organisation and saw engineering friction.
Some teams had mature pipelines and modern development practices. Others still waited for infrastructure tickets, manually coordinated releases and navigated lengthy approval processes.
For Priya, transformation meant automation, DevOps, modern engineering practices and giving developers greater autonomy.
And Sarah Mitchell, the CISO, had another perspective.
Moving faster was useful only if Westbridge could do it safely. Moving faster was useful only if Westbridge could do it safely.
The organisation's cloud footprint had expanded. Teams had adopted services differently. Security controls weren't always consistent, and increasing automation also meant increasing the speed at which a mistake could propagate.
For Sarah, transformation meant building security and governance into the way technology operated rather than adding them afterwards.
Four leaders.
One transformation programme.
Four perfectly reasonable interpretations of what transformation meant.
Narayan didn't think any of them were wrong. They were simply looking at the same transformation through four different lenses business, operations, engineering and security. The challenge wasn't choosing which view was right, it was bringing them together into one transformation.
How Far Does Westbridge Need to Go?
This was where Narayan thought transformation conversations often became too focused on technology.
Westbridge had hundreds of applications at very different stages of their lifecycle.
Take two hypothetical applications from its estate.
The first is a large monolithic application that changes frequently and supports an important digital service.
Westbridge might decide to modernise it significantly: break appropriate components into smaller services, containerise them, introduce automated CI/CD and Infrastructure as Code, improve observability and potentially run the workloads on a managed Kubernetes platform such as Amazon EKS.
Technology changes.
Architecture changes.
Deployment changes.
Operations change.
The way engineers work changes.
That's clearly a significant transformation.
But another Westbridge application might be completely different.
Perhaps it's a stable application running on VMware. It rarely changes, has another three years of expected life, but sits in a data centre Westbridge wants to exit.
Moving that workload to Amazon EC2 without rewriting it might be exactly the right decision.
It removes the dependency on the data centre, gets the workload onto a supported platform and allows Westbridge to focus its modernisation investment elsewhere.
Is rehosting the application itself a major modernisation?
No.
Can it still be an important step in Westbridge's wider transformation? Absolutely.
That distinction mattered to Narayan.
He didn't want Westbridge measuring transformation by how sophisticated its architecture diagrams became.
A Kubernetes cluster wasn't evidence of transformation.
Neither was an EC2 instance evidence that transformation hadn't happened.
The question was whether the change moved Westbridge meaningfully towards the outcome it needed.
The Destination Has to Fit Westbridge
Narayan had seen technically impressive platforms struggle because the organisation wasn't ready to operate them.
That was something he wanted Westbridge to avoid.
If Priya wanted greater developer self-service, what capabilities did the engineering teams need?
If Mark wanted to reduce legacy infrastructure, which applications genuinely justified modernisation and which should simply be migrated or retired?
If Sarah wanted stronger security, could those controls be automated rather than creating another layer of approvals?
And if Rachel wanted greater business agility, would all of these technology investments actually make Westbridge faster?
Those questions mattered more than whether the target architecture contained Kubernetes, serverless or the latest AWS service.
Narayan sometimes described platform maturity with a deliberately simple analogy:
If a customer needs a bicycle, give them the bicycle — not the spaceship.
The spaceship may be more advanced, but if the organisation doesn't have the skills, processes or operational maturity to fly it, it hasn't really moved forward.
Westbridge's transformation therefore couldn't simply be:
On-premises → EC2 → Containers → Kubernetes → Serverless → AI
Technology isn't a maturity ladder.
Different workloads would take different paths.
Some would be modernised.
Some migrated.
Some retired.
Some left alone.
And eventually, when Westbridge had the right foundations, skills, governance and use cases, AI would become part of the journey too.
But Narayan wasn't interested in starting there.
Not yet.
Where Does Westbridge Start?
Narayan pulled into the Westbridge car park and switched off the engine.
The building stood ahead of him.
He had plenty of information about Westbridge.
What he didn't yet have was a shared understanding of its destination.
Before Westbridge rushed into plans, programmes, platforms or technology decisions, Narayan wanted the organisation to step back and answer four basic questionss:
Where are we today?
Not where the strategy says they are. Where they actually are.
Where do we need to go?
Not which technology they want to implement. What capability needs to change.
Why do we need to go there?
What business or technology problem makes the change worthwhile?
And finally:
Are we ready to operate when we get there?
Narayan reached into the back seat and put on his jacket.
He liked wearing a suit. Perhaps a little old-fashioned, but first impressions still mattered.
He picked up his laptop bag and started walking towards reception.
Westbridge wanted to transform.
That much was clear.
What wasn't clear was whether Rachel, Mark, Priya, Sarah and the rest of the organisation were imagining the same destination.
Narayan suspected they weren't.
And before Westbridge could decide how to transform, they were going to have to agree on what they were actually trying to achieve.
That conversation was about to begin.
Next week:
Everyone Wants Change. Nobody Agrees on What Change Means.
Series: The Transformation Diaries - 52 Weeks Journey (10 articles)
- 1The Transformation Diaries 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