The Transformation Diaries Week 6: The First Well-Architected Conversation
Week 6 of The Transformation Diaries is here. This week, Narayan introduces the team to the AWS Well-Architected Framework and its six pillars — but adds one more to the whiteboard: Value Realization. Because an architecture can be secure, reliable, efficient and operationally sound… but if it isn't delivering the outcome the business actually needs, is it truly well architected? Week 6 — The First Well-Architected Conversation
Series: The Transformation Diaries - 52 Weeks Journey (10 articles)
- …
- 6The Transformation Diaries Week 6: The First Well-Architected Conversation This article
By Monday morning, Narayan's whiteboard had become difficult to ignore.
Over the previous few weeks, Westbridge had uncovered 500+ EC2 instances, infrastructure drift, unclear ownership, more than 100 NAT Gateways, 300+ VPC interface endpoints, unexplained CloudWatch costs, production-sized non-production environments, questionable backup requirements and more than a few things that existed because nobody had asked why for a very long time.
Each discovery had started as its own problem.
Cost.
Security.
Networking.
Operations.
Resilience.
But Narayan was beginning to think that was the wrong way to look at them.
Tom appeared beside him with a coffee.
“Please tell me we're not finding another hundred NAT Gateways this week.”
Narayan looked at the whiteboard.
“Actually, I think we need to stop looking at NAT Gateways.”
Tom raised an eyebrow.
“Best idea you've had since you got here.”
Maybe We Need to Stop Looking at Services
Raghu joined them a few minutes later.
Narayan pointed at the collection of findings.
“We keep looking at these as individual AWS problems.”
Tom nodded. “Because they are individual AWS problems.”
“Are they?”
Narayan pointed at the NAT Gateways.
They had first appeared because of cost. But decentralised egress had also raised questions about security and governance. Centralising it would introduce questions around resilience and failure domains. And whatever they eventually built would need to be operated and monitored properly.
One architectural decision had touched several different concerns.
The VPC interface endpoints were similar. Something that may originally have been introduced as a security improvement had multiplied into hundreds of resources, increasing cost and operational complexity without a clearly understood requirement.
Narayan looked at Tom.
“Maybe the question isn't whether the NAT Gateway is right.”
“What is it then?”
“Whether the workload is well architected.”
Tom took another sip of coffee.
“That sounds suspiciously like you've got a framework for this.”
Narayan smiled.
Six Pillars, Sounds Simple !!!
The words AWS Well-Architected Framework appeared on the screen.
Tom sighed.
“I knew there'd be a framework.”
The idea itself was straightforward. Instead of judging architecture by whether it used the newest AWS services or looked impressive on a diagram, the Well-Architected Framework gave teams a structured way to think about workloads across six areas:
Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization and Sustainability.
The names weren't what interested Narayan.
The conversations behind them were.
How did the team operate the workload?
What happened when something failed?
How were security controls applied?
Was infrastructure being used efficiently?
Did the architecture achieve the required performance without unnecessary resources?
Could it evolve without creating more operational burden?
The framework wasn't there to tell Westbridge which AWS services to use.
It was there to make Westbridge ask better questions about the services it had already chosen.
Tom looked at the six pillars.
“So we put everything we've found into six buckets and suddenly it's architecture?”
Narayan shook his head.
“No. We use six buckets to discover everything we haven't found yet.”
Tom looked at Raghu.
“He does realise that's worse, right?”
Raghu smiled. “I'm letting you discover that yourself.”
Tom Counted Seven
Narayan added another word to the whiteboard.
VALUE
Tom looked at it.
Then at Narayan.
Then back at the six pillars.
“You said six.”
“I did.”
Tom counted them unnecessarily with his finger.
“That's seven.”
Narayan nodded.
“This one's mine.”
Tom stared at him.
“Does AWS know?”
“Let's not bother them just yet.”
Narayan had always felt there was another conversation that architecture reviews didn't have often enough.
The six official pillars could help determine whether a workload was secure, reliable, operationally sound, efficient, cost optimised and sustainable.
But Narayan still wanted to ask:
“Is it actually delivering what the business needs?”
A technically excellent architecture could still be the wrong architecture.
Westbridge's non-production environments had demonstrated that beautifully.
Three hundred VPC interface endpoints could be deployed consistently, securely and reliably. But if the workloads didn't need them, what value were they creating?
A Dev database could be highly available across multiple Availability Zones. But if nobody required that availability, what outcome was Westbridge paying for?
A team could modernise an application onto the latest services, but if Westbridge didn't have the skills or operational maturity to support it, had the organisation really moved forward?
Narayan thought of it as Value Realization i.e. connecting architecture back to business outcomes, measurable value and the organisation's ability to operate what it built.
The first six pillars protected the system. The seventh protected its purpose.
Tom looked at the whiteboard.
“So this isn't officially part of Well-Architected?”
“No.”
“Good.”
“Why good?”
“For a moment I thought I hadn't been reading the release notes properly.”
Cost Was Never Just Cost
They went back to the NAT Gateways.
A week earlier, more than 100 NAT Gateways had looked like a potential cost-saving opportunity.
Now Narayan asked them to look at the same finding through the pillars.
Cost Optimization asked the obvious question: why was Westbridge paying for so many decentralised NAT Gateways?
Security raised another: were all those internet exit points going through the inspection and monitoring controls Westbridge expected?
Operational Excellence asked who managed the pattern and how consistently it was operated.
Reliability complicated the proposed solution further. Moving towards centralised egress might reduce cost and improve governance, but what happened if that central network path failed?
Tom pointed at Narayan.
“So the three NAT Gateways you liked last week aren't automatically the answer either?”
“Correct.”
Tom smiled.
“I'm going to write that down. Consultant admits architecture is complicated.”
Narayan laughed.
The point wasn't whether three NAT Gateways or a hundred were inherently right.
The point was that the decision needed to consider cost, security, operations and resilience together.
That was what Narayan liked about Well-Architected.
The pillars weren't six independent conversations.
They forced the same architecture to survive six different conversations.
And Narayan would quietly add a seventh.
Security Wasn't Just Security Either
Sarah joined them when the conversation moved to the VPC interface endpoints.
Narayan explained what they had discovered.
Most of the 300+ interface endpoints were sitting in non-production. Production used relatively few. Nobody had yet found a broad written compliance requirement explaining why Dev and Test required private connectivity to all those AWS services.
Sarah wasn't particularly impressed by the argument that they should remain simply because private connectivity sounded more secure.
“A security control should exist because we're managing a risk,” she said. “Not because somebody once put it in a Terraform module.”
Tom nodded.
Narayan smiled.
“I might steal that.”
“I'm charging consulting rates.”
The endpoints had started life as a security conversation.
But now they were also a cost problem, an operational complexity problem and potentially an architecture problem involving DNS, routing and security groups.
More wasn't automatically better.
As Sarah put it:
“If we don't understand why a control exists, eventually it becomes another thing we have to secure.”
Another item on the whiteboard crossed several pillars.
The pattern was becoming obvious.
Which Application Are We Reviewing?
By Wednesday afternoon, Tom had another question.
“So which application are we actually doing this to?”
Narayan looked at him.
“What do you mean?”
“We've got hundreds of workloads. Unless you've discovered an eighth pillar called unlimited consulting budget, we're probably not reviewing all of them.”
Raghu laughed.
Tom had a point.
Westbridge couldn't put the entire AWS estate into one enormous Well-Architected Review and expect anything useful to come out of it.
The framework worked best when the conversation had context.
A workload.
A business purpose.
Owners.
Users.
Dependencies.
Operational requirements.
Narayan looked through the application information they had started collecting in Week 3.
“Let's pick one.”
Not the worst application.
Not the most modern.
Not the one with the biggest AWS bill.
A meaningful Westbridge workload with enough business importance and technical complexity to make the conversation useful.
Something that touched compute, databases, networking, security, operations and real customers.
Tom nodded.
“So we're finally going to stop reviewing AWS and review something that actually uses AWS?”
Narayan smiled.
“Now you're getting it.”
Nobody Gets a Score
Once the workload was selected, the invitations went out.
The application owner.
Engineering.
Operations.
Security.
Architecture.
Narayan deliberately avoided describing the session as an audit.
It wasn't one.
At the start of the workshop, Tom asked the question Narayan suspected someone eventually would.
“So what's considered a good Well-Architected score?”
“There isn't one.”
Tom looked genuinely disappointed.
“No score?”
“No.”
“No percentage?”
“No.”
“No green badge at the end?”
“No.”
Tom leaned back.
“Seven pillars and you couldn't even give me a score?”
Narayan laughed.
The point wasn't to prove that Westbridge was 85 percent Well-Architected.
It wasn't to make every answer green or produce a certificate that could disappear into Confluence.
The purpose was to expose risks, assumptions and opportunities for improvement and then decide which ones actually mattered.
“We're not grading the team,” Narayan said. “We're trying to understand the workload.”
That changed the mood in the room.
People stopped trying to defend the architecture.
And started explaining it.
The First Question Changed the Room
Narayan deliberately started somewhere simple.
Not with encryption.
Not with Multi-AZ.
Not with instance types.
He asked how the workload was operated when something went wrong.
The Operations team described the process.
Engineering added something different.
The application owner interrupted.
“I thought that was automated.”
Tom looked across the table.
“It isn't.”
There was a pause.
Someone opened the documentation.
The documentation described something else again.
Tom slowly turned towards Narayan.
“I'm guessing this is the bit where you tell us that's bad?”
Narayan shook his head.
“No. This is the bit where the review becomes useful.”
Nothing had failed.
No incident had occurred.
No customer had complained.
But in less than an hour, a Well-Architected conversation had exposed something weeks of looking at AWS resources hadn't.
Different teams had different understandings of how the same workload actually operated.
Narayan looked at the remaining questions.
There were a lot of them.
Tom followed his eyes.
“How long did you book this room for?”
“Two hours.”
Tom laughed.
“That's optimistic.”
By Friday, They Had More Questions Than Answers
By Friday, Westbridge's first Well-Architected conversation had generated considerably more questions than answers.
Narayan considered that progress.
The previous weeks had shown them what existed, what it cost, and where some of the assumptions lived.
Now they were beginning to understand something deeper.
Architecture wasn't just the boxes on a diagram.
It was how those boxes were operated, secured, recovered, scaled, paid for and connected to the outcomes Westbridge expected from them.
Tom walked past Narayan's desk late that afternoon.
“Just so I'm clear…”
Narayan looked up.
“We started this week with six pillars.”
“Yes.”
“You added another one.”
“Yes.”
“And somehow we ended up with more problems than we started with.”
Narayan smiled.
“Questions, Tom. We ended up with more questions.”
Tom continued walking.
“Whatever helps you sleep.”
Narayan looked back at the findings.
Operational Excellence had questions.
Security had questions.
Reliability had questions.
Performance Efficiency had questions.
Cost Optimization definitely had questions.
Sustainability hadn't exactly escaped either.
And Value Realization was beginning to challenge why some of the architecture existed in the first place.
Six pillars.
One unofficial seventh.
And considerably more than six problems.
Narayan closed his laptop.
Next week was going to need a bigger whiteboard.
Next week: Week 7 - Six Pillars, Fifty Problems.
Series: The Transformation Diaries - 52 Weeks Journey (10 articles)
- …
- 6The Transformation Diaries Week 6: The First Well-Architected Conversation 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