(1)
In a fun thread on Facebook, where a bunch of my fellow architects and I interacted, a question came up:
What is this operational thing you keep talking about?
And well, I thought it might be worthwhile to define.
I borrowed the terms from military games and my long-standing fascination with the first and second world war. Generally speaking, a tactical engagement is one involving a small number of soldiers that is part of some battle. An operational engagement is a large battle like the Battle of Kursk or the Invasion of Normandy. A strategic engagement is the Liberation of Europe or even grander the Defeat of the Axis. And the lines I just drew are not as simple as that.
For me, the key points are that the bigger the scope:
- the more the resources are available
- the more impact decisions of the past have in the present,
- the bigger the stakes.
Using that mental model:
- Tactical software architecture is a bug or a feature spanning a single release
- Operational software architecture is about a product spanning multiple releases
- Strategic software architecture is about multiple products spanning multiple releases.
Using that mental model, we can answer the question that was posed as a follow on:
When do I pick a new language or stack?
Definitely out of scope for a tactical software architecture. You’re incrementally improving the product within a bigger operational software architecture, and you should use the tools provided.
That’s an operational software architecture question. The overall strategic software architecture may constrain some choices. However, an operational software architect should have some degrees of freedom.
At the strategic software architecture level, there is never one language or stack. Instead, there are questions of how many, and what are the preferred and what are the rules for adding or removing, and how do they inter-operate.
And on-prem vs. SaaS?
As a strategic software architect, on-prem software limits architectural choices at the operational level. Each new stack has to be as mature as every pre-existing stack, and that means you keep using the same stuff that someone picked years ago. The challenge of adding a new stack is the underlying reason why on-prem software suffers from periodic rewrititis.
For SaaS, on the other hand, adding new technology stacks is easier. Unlike on-prem, where the entire product suffers if a service is bad, in SaaS, the impact is more constrained. And this gives operational software architects more authority and strategic software architects more freedom. The flexibility software architects have is, why SaaS platforms don’t go through rewrites – although individual services do.
(1) The last great operational tank battle, the Battle of Kursk. Map By Bundesarchiv, Bild 101III-Zschaeckel-206-35 / Zschäckel, Friedrich / CC-BY-SA 3.0, CC BY-SA 3.0 de, https://commons.wikimedia.org/w/index.php?curid=5414021
Leave a Reply