The Transformation Diaries Week 10: Who Actually Owns This Application?
The Transformation Diaries | Week 10: Who Actually Owns This Application? ☁️ Engineering maintains it. Operations supports it. Security manages the risks. Finance pays the bill. But who actually owns it? 🤔 This week, we welcome Alex, a new engineering intern, whose simple questions uncover some interesting gaps in application ownership, outdated documentation and hidden dependencies. Because the cloud might be someone else's computer, but the responsibility is still yours! 😄 📖 or 🎧 listen on Spotify.
Series: The Transformation Diaries - 52 Weeks Journey (10 articles)
- …
- 10The Transformation Diaries Week 10: Who Actually Owns This Application? This article
Prefer listening to the story?
A Small Win. A Bigger Question.
Monday morning at Westbridge started with something everyone appreciated.
Good news.
The CloudWatch optimisation from the previous week was delivering results. Retiring a legacy Lambda function that had been invoked more than 22 million times a month had helped reduce the organisation's CloudWatch costs by approximately 60%.
The estimated annualised saving was around US$80,000.
Daniel Foster, Westbridge's CFO, was pleased.
"Not bad for deleting something," he said.
Tom Walker smiled. "Technically, we spent several days proving we could delete something."
"Even better. Can we delete anything else?"
The room laughed.
Then Rachel Chen asked a question.
"Who actually approved retiring that application?"
Justin Richards explained that Engineering had validated the dependencies. Mark confirmed Operations had reviewed the monitoring. Sarah had checked the security implications.
Everything had been handled carefully.
But Rachel wasn't asking who had helped.
She was asking who was accountable.
The room went quiet.
Tom finally broke the silence.
"Well, at least we know who doesn't own it anymore."
Narayan smiled, but the question stayed with him.
For nine weeks, they'd been discussing architecture, cost, security and transformation.
Somewhere along the way, they'd assumed Westbridge knew who owned its applications.
Perhaps that assumption needed another look.
A New Face at Westbridge
Later that morning, Narayan met Alex Morgan, a new engineering intern, standing in front of the office coffee machine.
"First day?" Narayan asked.
"Is it that obvious?"
"Only because you're reading the instructions. Most of us gave up months ago."
Alex laughed.
He had recently joined Priya's engineering team. He knew some Python, Git and AWS, but this was his first experience inside a large enterprise.
"It's a little overwhelming," Alex admitted. "I looked at the architecture diagrams. There are so many AWS accounts."
Narayan smiled.
"Wait until you see the VPCs."
"Actually, I did. I thought I was looking at the same diagram twice."
"Unfortunately, that's also normal."
Narayan remembered his own early career, sitting in meetings surrounded by experienced engineers, afraid to ask questions because everyone else seemed to understand everything.
It had taken him years to realise that sometimes they didn't.
They were simply better at looking confident.
"One piece of advice," he told Alex. "Never be afraid to ask questions, even if they sound basic."
Alex nodded.
"And if someone tells you it's a stupid question, ask them to explain the answer."
Everyone Knows the Application. Nobody Owns It.
Priya had assigned Alex a straightforward task: help update the ownership and dependency information for five logistics applications.
Alex started with an older application running on EC2, behind an Application Load Balancer, with an RDS database and several integrations.
The infrastructure was easy enough to identify.
The owner wasn't.
The AWS Owner tag referenced a team that no longer existed.
So Alex asked Tom.
"Operations supports it."
Justin gave a different answer.
"Engineering maintains the code."
Raghu remembered that the application originally belonged to the Logistics Systems team, although the business had since reorganised.
Three people. Three answers.
Alex returned to Tom.
"Sorry, I'm confused. Who actually owns it?"
Tom leaned back.
"Depends. Is it working?"
"Yes."
"Then Engineering."
"And if it breaks?"
"Apparently Operations."
Narayan, listening nearby, laughed.
But Alex had uncovered something important.
Everyone understood a part of the application.
Nobody seemed certain who was accountable for the whole thing.
The Spreadsheet That Outlived Its Owners
By Wednesday, the team was reviewing Westbridge's application inventory.
Some records were detailed. Others were less impressive.
One application's owner was listed as "TBC".
Another named someone who had left eighteen months earlier.
Several simply said "IT".
Mark looked at the screen.
"Well, that narrows it down."
Alex frowned.
"Couldn't we just automate this?"
Tom nodded thoughtfully.
"Absolutely. We could automate the collection of incorrect information."
Alex looked confused.
"Then we'd have incorrect information in real time. Progress."
The room laughed.
But Tom had a point.
The problem wasn't simply collecting information. It was knowing whether that information was still accurate.
Priya explained that application ownership often started with a project. The project delivered, the team moved on, people changed roles, and the application continued running.
Raghu added:
"The inventory tells us what someone believed was true when they entered it. Not necessarily what's true today."
An outdated spreadsheet could be just as misleading as an outdated architecture diagram.
And automating it wouldn't necessarily make it any more accurate.
Five Owners. Zero Accountability.
The discussion eventually brought Rachel, Mark, Priya, Sarah and Daniel together.
"What does owning an application actually mean?" Rachel asked.
Priya spoke about code, deployments and technical direction.
Mark talked about monitoring, incidents and keeping the application running.
Sarah wanted clear accountability for security risks.
Daniel wanted to know which business function benefited from the application and whether its cost was justified.
Raghu smiled.
"Five people. Five definitions. One word."
Mark leaned back.
"It's funny how everyone owns an application when it's getting launched. Six months later, when something breaks at two in the morning, apparently Operations adopted it."
Even Priya laughed.
Narayan walked to the whiteboard and wrote:
- Business accountability: Who decides whether the application is needed and approves significant business changes?
- Technical stewardship: Who understands the architecture, code and dependencies?
- Operational support: Who monitors it, responds to incidents and restores service?
- Risk and governance: Who addresses or accepts risks through the appropriate authority?
- Cost visibility: Who understands what it costs and the value it delivers?
"These don't necessarily need five different owners," Narayan explained. "But the responsibilities need to be clear."
An AWS tag could identify a contact.
It couldn't automatically establish accountability.
It Worked Yesterday. Whose Problem Is It Today?
That afternoon, an older logistics integration began producing intermittent errors in shipment status updates.
Nothing catastrophic.
But resolving it took longer than expected.
Operations confirmed the servers were healthy.
Engineering investigated the application.
Another team checked a downstream integration.
Eventually, they traced the issue to a configuration mismatch in a scheduled job.
The fix was straightforward.
Finding the right people and understanding the dependency had taken most of the time.
"The infrastructure was healthy," Tom pointed out.
Mark nodded.
"Unfortunately, the shipments weren't."
Alex quietly updated his notes.
"So an application can be technically healthy while the business process is broken?"
"Exactly," Narayan replied.
For years, Westbridge had organised much of its operational thinking around servers, databases and networks.
But the business didn't experience an EC2 instance.
It experienced a service.
And a green dashboard didn't always mean the customer was having a good day.
A RACI Matrix Walks Into a Meeting
On Thursday, Raghu suggested clarifying ownership through a simple responsibility model.
Tom looked suspicious.
"Please tell me we're not creating a forty-page RACI document."
"Only thirty-nine," Raghu replied.
"Excellent. Transformation is accelerating."
Narayan understood the concern.
Westbridge didn't need another governance document that looked impressive but changed nothing.
Instead, they agreed to start small.
For each application, they would identify the accountable business owner, technical steward, operational support team, critical dependencies and relevant risk contacts.
More importantly, they'd test whether those records answered practical questions.
Who approves a major change?
Who decides whether the application can be retired?
Who accepts the business impact of downtime?
Who gets called when something fails?
And who makes sure the information stays current?
"Ownership isn't just about documenting a name," Narayan said. "It's about knowing who can make a decision."
Sometimes Fresh Eyes See What Experience Misses
Later that day, Alex noticed something unusual while reviewing one of the applications.
The architecture diagram showed its database and downstream service.
But the configuration referenced an S3 bucket that wasn't documented.
Justin investigated.
The bucket supported an older reporting integration that was still active.
Interestingly, the application had been marked as a potential retirement candidate during an earlier assessment.
"If we retired this application, would the reporting process stop?" Alex asked.
"Potentially," Justin replied. "We'd need to validate that dependency first."
Tom looked at the diagram.
"So we've got another missing connection."
Alex seemed slightly uncomfortable.
"Sorry, I wasn't trying to find a problem. I was just following the configuration."
Narayan smiled.
"That's usually how you find the interesting ones."
It wasn't a groundbreaking discovery.
But it mattered.
Westbridge was preparing to modernise and migrate applications. An undocumented dependency could turn an ordinary retirement or migration into a very unpleasant weekend.
Narayan thought back to the previous week's Lambda investigation.
That change had succeeded because the team had validated what depended on the function before retiring it.
Different application. Same lesson.
You cannot safely change what you don't fully understand.
Ownership Isn't Just Another AWS Tag
By Friday, Alex had reviewed five applications.
Some had clear technical contacts but uncertain business ownership.
Others had outdated records or incomplete dependencies.
One had an active reporting integration missing from the architecture diagram.
The findings weren't particularly flattering.
But they were useful.
Rather than launching another massive transformation initiative, Narayan suggested integrating ownership validation into the work already planned.
Applications being migrated would need confirmed business and technical accountability.
Applications being modernised would need agreed operational responsibilities.
Applications being retired would require approval from the people accountable for their business purpose.
And the most critical applications would be prioritised first.
Priya would help incorporate ownership into engineering processes. Mark would validate support arrangements. Raghu would help establish the reference model.
Alex would continue working with the team.
Tom looked at him.
"Congratulations. You've inherited the spreadsheet."
"Is that a promotion?" Alex asked.
"Depends. Is it working?"
Friday Afternoon: Five Applications, A Hundred Questions
As the office emptied, Narayan found Alex packing his laptop.
"How was your first week?"
Alex smiled.
"I thought I'd spend most of my time learning AWS. Instead, I've spent most of it figuring out who to talk to."
Narayan laughed.
"That's a useful skill."
Alex hesitated.
"Does it ever get easier? Understanding all of this?"
"Some parts do. You learn the technology, the architecture, the patterns."
"And the other parts?"
"You learn to become comfortable not knowing everything."
Narayan paused.
"The trick isn't having all the answers. It's knowing which questions matter."
Alex nodded.
Across the room, Tom called out.
"Alex! Before you leave, can you update the application inventory?"
Alex grinned.
"See? Already getting responsibilities."
"Just make sure you don't become the owner of all five applications," Narayan replied.
As he headed towards the lift, Narayan reflected on the week.
He'd spent years helping organisations untangle complex architectures. Networks, databases, applications and dependencies.
Yet sometimes, the hardest thing to find wasn't a missing connection between two systems.
It was the person who could confidently say, "This one's mine."
Alex had arrived expecting to learn about AWS.
Instead, he'd discovered something no certification exam had prepared him for.
The cloud might be someone else's computer. But the responsibility was still yours.
Next Week — The Landing Zone Isn't Quite a Landing Zone
With application ownership becoming clearer, Narayan and Raghu turn their attention to the AWS foundations supporting those applications.
The landing zone was supposed to provide a consistent, governed starting point.
But as they review the account structure, security boundaries and shared services, they discover that the word standard has been interpreted rather creatively over the years.
And somewhere in the middle of it all is a familiar question.
Who approved this?
Join us next week for Week 11 of The Transformation Diaries: The Landing Zone Isn't Quite a Landing Zone.
Because sometimes, the most interesting architecture decisions are the ones nobody remembers making.
Series: The Transformation Diaries - 52 Weeks Journey (10 articles)
- …
- 10The Transformation Diaries Week 10: Who Actually Owns This Application? 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