A trend I see in modern software is that every platform wants to become a "little bit of everything".
Document management systems now include workflow engines...
Project management tools include databases...
Storage platforms have automation...
Collaboration platforms have low-code applications...
... and of course, every platform wants to be your AI best friend!
It seems that every platform is steadily expanding beyond its original purpose. I don't necessarily see some of these as bad things. Many of these features are genuinely useful additions to a platform.
The mistake is assuming that because a platform can perform a task, it therefore should own that responsibility.
I think there is an architectural principle hiding here that I like to think of as the Centre of Gravity.
Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.
-- Dr. Ian Malcolm
Every Problem Has a Centre of Gravity#
Every piece of work has a natural centre of gravity.
It's the place where most of the context lives. It's the system that best understands why something is happening, not just what is happening.
The challenge is identifying where that centre of gravity actually is.
Consider a very simple example:
- A user uploads a collection of files into a document repository.
- Those files need to be renamed and moved into an appropriate folder.
Everything begins in the repository. Everything ends in the repository.
The data lives there... The trigger originates there... The outcome remains there...
The centre of gravity is clearly the document platform.
Using its built-in automation capabilities is not only reasonable, it's probably the simplest and most maintainable solution. Introducing a complete automation platform for such a task would be an unnecessary architectural complexity.
When the Centre Moves#
Now imagine the requirements evolve.
The initial event still involves a document, but now additional information must be retrieved from various other systems. Data needs to be transformed, validated, enriched... Decisions are made based on information held across multiple platforms... Several APIs are called... Different business rules apply depending on conditions in the data. Downstream systems are updated, tasks happen in parallel...
At this point, the document hasn't become more important. The document is simply one participant in a much larger business process.
The centre of gravity has shifted.
The problem is no longer primarily about documents. It is about orchestration.
Of course, this is two extreme ends of the scale, and sometimes the reality can be a bit more muddy. A small task can snowball into a complex process.
(And lets just skip over the debugging and maintenance of these for the now!)
Platform-Centric vs Process-Centric#
Most built-in platform automation is designed with a very specific philosophy.
It extends the platform.
The primary concern is events occurring within that platform, data owned by that platform, and actions performed by thta platform.
There is nothing wrong with this.
In fact, that focus is usually what makes these tools approachable, efficient, and easy to maintain for platform-specific workflows. Dedicated integration and automation platforms solve a fundamentally different problem. Their purpose isn't to extend a single platform. Their purpose is to connect many platforms.
Their centre of gravity is process rather than product.
The Expanding Platform#
This principle extends well beyond automation... AI provides another good example.
It seems every product from ERPs to toasters have AI agents these days. And those features are often decent within the context of the platform or product itself. They understand the data they own. They understand the objects they manage. They can answer questions and perform actions that make perfect sense within their own ecosystem.
But they inevitably see the world through the lens of that platform.
As soon as the problem spans multiple knowledge domains, multiple systems, or organisational/operational context beyond that single platform, the centre of gravity begins to move again.
The same principle applies to reporting, analytics, search, identity, workflow, approvals, notifications, and countless other capabilities that increasingly appear across a business technology stack.
The question is rarely whether the feature works - the question is whether that platform is still the natural owner of the responsibility.
Architectural Jurisdiction#
Perhaps the better way to think about software architecture is through jurisdiction.
Every system has a domain where it should be authoritative.
- A CRM platform should own customer relationships.
- A document platform should own documents.
- An identity platform should own identity.
- An integration platform should own integration.
Problems arise when systems begin taking ownership of responsibilities that primarily belong elsewhere.
Sometimes this happens because requirements have grown gradually over time. Sometimes it's because a platform continues adding new capabilities. Sometimes it's simply because using one product feels "easier" (or cheaper!) than introducing another.
None of these reasons necessarily make the architecture better. Good architecture isn't neccisarily about minimising the number of products. Nor is it about maximising the capabilities of a particular platform.
It's about assigning responsibility to the place where that responsibility most naturally belongs.
Asking the Better Question#
When evaluating a new feature (or whole platform), it's tempting to ask a simple question:
"Can this platform do X?"
Most of the time, the answer will be yes... asterisk.
I think a better question is:
"Where is the centre of gravity for problem Y?"
We shift perspective from the feature/platform to the problem. The problem becomes the key.
If a platform naturally owns the data, the events, the business context, and the outcome, then it has likely earned the right to own the solution.
If it has become merely one participant in a broader business process, then perhaps the responsibility belongs elsewhere. Or perhaps the platform is a solution in search of a problem...
Technology will continue to evolve, and platforms will continue to absorb more features. That's both inevitable and, in many cases, beneficial.
But capability alone shouldn't determine ownership. As architects, our job isn't simply to choose software that can perform a task. Our job is to understand which system has earned the architectural right to own it.
For me, that's the real value of thinking in terms of the Centre of Gravity.