Someone asks you the hardest part about Enterprise Architecture, what do you tell them? Do you jump into a previous situation and take the opportunity to relive some mild PTSD? Before we answer this let’s talk about some scenarios…
The “Technical Debt” Junction
A runaway project (the trolley) is barrelling toward five core product teams. Their velocity is slowing to a crawl because they are trapped on an aging, monolithic infrastructure that is increasingly prone to outages.
You stand at the lever. If you pull it, you divert the project toward a comprehensive cloud-native refactoring exercise. However.
- The Sacrifice: You completely de-prioritize the “Golden Feature”, the one request the CEO promised to the board for Q4. If that feature isn’t delivered, the company’s valuation might drop, but the five teams gain a scalable, modern foundation.
- The Dilemma: Do you sacrifice long-term engineering health (the 5 teams) for immediate market valuation (the 1 feature)?
The “Vendor Lock-in” Loop
The trolley is headed toward a Proprietary Ecosystem (e.g., going “All-in” on a single cloud provider’s native services). This allows your developers to build at lightning speed because everything is pre-integrated.
You stand at the lever. If you pull it, you switch the tracks to a Cloud-Agnostic / Multi-Cloud strategy using Kubernetes and open-source abstractions.
- The Sacrifice: You avoid Vendor Lock-in (saving your future self from massive price hikes), but you immediately “crush” your Time-to-Market. Your developers now must manage complex abstractions and “plumbing” instead of shipping features, potentially letting a competitor beat you to market.
- The Dilemma: Is the theoretical risk of future dependency worse than the certain risk of current inefficiency?
Why these matter in Enterprise Architecture.
In classic ethics, the trolley problem tests Utilitarianism, a moral theory that judges actions by their consequences, advocating for choices that produce the greatest overall happiness and minimise suffering for the greatest number of people. vs. Deontology, an ethical theory focused on duties and rules, asserting that the morality of an action lies in the action itself and the intention behind it, not its outcome. Sounds like an Enterprise Architects job description…
In Enterprise Architecture, the trolley problem really presents as following:
- Agility vs. Stability: How much friction can the organization endure?
- Short-term Gains vs. Total Cost of Ownership (TCO): Are we borrowing from the future to pay for today?
- Governance vs. Autonomy: Who gets to decide which “track” we are on?
However, what this is really called is Architectural Dilemmas. And these dilemmas are the hardest part of being an Enterprise Architect as there is rarely a “correct” answer, only a series of trade-offs requiring negotiations and more than just a C4 diagram and well-trodden ADM theory.
So, it’s really like getting the trolley at Tesco with the wonky wheel, by the time you’ve found the compromise you’re already in the store, it’s raining outside, you’re committed now so with determination the trolley will probably only end up slightly off the track and this creates a compromise that works.
Real-world EA is about navigating a slightly broken system and finding a “compromise that works” rather than achieving theoretical perfection. The communication of the dilemmas and gaining buy in from stakeholders tied to their respective tracks is the difference.