The Atlassian Friend #7: Invisible Architecture
Good architecture doesn’t remove complexity. It decides where complexity should live.
I’ve been thinking a lot about simplicity lately.
Not because software is becoming simpler.
Quite the opposite.
Every year we add more systems, more integrations, more security controls, more compliance requirements, more approvals, more automation, and now AI on top of everything else.
Enterprise software isn’t getting simpler.
It’s getting more complex than ever.
So why do some experiences still feel effortless?
That question has been stuck in my head for a while.
And the more I think about it, the more I believe we’ve been asking the wrong question.
We often say that good architecture reduces complexity.
I’m not sure that’s true anymore.
I think good architecture does something much more interesting.
It decides where complexity should live.
Imagine you’re an employee who needs help.
You don’t wake up in the morning thinking:
“I need to create a Jira Service Management request.”
You don’t think:
“I wonder which department owns this process.”
You certainly don’t think:
“Which request type should I choose?”
You have a much simpler thought.
“I need a new laptop.”
Or:
“I can’t log in.”
Or simply:
“Can someone help me?”
That’s your problem.
Everything else is ours.
As architects, engineers, and service designers, we sometimes forget that.
We spend so much time designing workflows that we accidentally ask employees to understand them too.
We ask them to navigate portals.
Choose categories.
Fill in forms.
Understand internal terminology.
Know which team owns what.
Provide information we already have somewhere else.
Little by little, we’re transferring our complexity to the people we’re trying to help.
Not because we intended to.
But because it’s easy to confuse process design with user experience.
The longer I’ve worked with enterprise platforms, the more I’ve realised something.
Complexity never disappears.
It always exists somewhere.
There will always be business rules.
There will always be approvals.
Identity management isn’t going away.
Neither are asset inventories, security policies, integrations, or audit requirements.
Pretending we can eliminate complexity is unrealistic.
But deciding who has to deal with it…
That’s architecture.
To me, that’s what invisible architecture really means.
The employee sees a simple experience.
Behind that experience, dozens of systems may be working together.
Identity is resolved.
Policies are evaluated.
Assets are checked.
Automations run.
Approvals are triggered.
Notifications are sent.
Records are updated.
Everything happens exactly as it should.
The employee doesn’t need to know.
And that’s not because those things aren’t important.
It’s because they are.
They deserve to be handled consistently, automatically, and reliably instead of becoming another burden for the employee.
This way of thinking has changed how I look at service management.
For years, we’ve focused on making portals better.
Better layouts.
Better categories.
Better forms.
But maybe that’s solving the wrong problem.
Maybe employees shouldn’t have to navigate our architecture at all.
Maybe architecture should navigate itself.
The employee simply describes what they need.
The platform figures out the rest.
This is why I’m so interested in the combination of conversational AI, service management, automation, and contextual data.
Not because AI replaces ITSM.
It doesn’t.
Not because conversations replace governance.
They shouldn’t.
But because conversations can replace navigation.
That’s a very different idea.
Instead of asking employees to learn how our organisation works, we can build systems that understand enough context to guide them naturally.
The complexity stays exactly where it belongs.
Inside the architecture.
Not inside the employee’s head.
Ironically, the more sophisticated an enterprise becomes, the less sophisticated the experience should feel.
That’s the paradox.
A single conversation may trigger twenty systems.
A simple request may involve security, HR, procurement, identity management, asset management, approvals, and automation.
The employee shouldn’t have to care.
Their job isn’t to understand our architecture.
Our job is to build architecture that understands enough to help them.
The more I think about it, the more I realise this article isn’t really about AI, Jira Service Management, or any particular technology.
It’s about a question I’ve found myself asking more and more over the years.
Who should carry the complexity?
For a long time, I thought architecture was about connecting systems, designing workflows, and making processes more efficient.
Those things are still important.
But today, I think they’re the consequence, not the goal.
The goal is much simpler.
When someone needs help, they shouldn’t have to understand how we’ve organised ourselves to get it.
They shouldn’t need to know how many systems are involved, who owns each process, or why a particular approval exists.
That’s our complexity.
Not theirs.
Maybe that’s what architecture has gradually come to mean for me.
Not removing complexity.
Not pretending it doesn’t exist.
But accepting it… and making a conscious decision about where it should live.
If we’ve done our job well, the employee never has to think about any of it.
They simply get on with their day.
And perhaps that’s one of the most satisfying parts of being an architect.
Building things that most people will never notice.
Not because they aren’t important…
But because they quietly did exactly what they were supposed to do.
Maybe that’s what invisible architecture really is.
About The Atlassian Friend
The Atlassian Friend is a series of stories, practical guides and personal reflections inspired by years of working with the Atlassian ecosystem.
Rather than simply explaining features, each article explores the ideas, patterns and experiences behind them.
To learn together, share openly, and grow as a community.
Have you ever participated in an Early Access Program?
I'd love to hear your experience.
See you in the next chapter of The Atlassian Friend. 💙
Was this helpful?
Thanks!
Antonio Ferruz
1 comment