There is a category of software that is excellent at solving a real problem — and completely wrong for most of the organisations that try to buy it. Enterprise EA tooling sits firmly in that category.
The platforms in this market are serious products built for serious enterprise problems. They handle large, complex IT landscapes at the scale of global banks, automotive manufacturers, and public sector agencies with hundreds of applications and dozens of stakeholders. They invest in deep metamodel flexibility, enterprise-grade integrations, and governance workflows because their customers genuinely need all of that.
The problem is that a midmarket company with 200-5,000 employees and one IT leader reads the same analyst reports, sits through the same vendor demos, and ends up buying tools designed for a fundamentally different context.
What Enterprise EA Tooling Requires
Implementing a full-scale enterprise EA platform is not a procurement decision — it's a programme. The typical engagement for a large organisation involves several months of metamodel design before any useful data can be entered. Then comes data migration, integration work with existing systems, training, and governance design. A dedicated EA team is assumed. The total cost of ownership — licences, professional services, ongoing maintenance — runs well into six figures annually for an organisation of any size.
For the organisations these platforms are designed to serve, that investment makes sense. When you have several hundred applications, multiple business domains, and an enterprise architecture function with a team of practitioners, you need a purpose-built repository with deep customisation capability.
But when a CIO at a 600-person company buys into this category with the intention of getting a handle on their 80 applications and aligning IT to business strategy, something breaks. The tool is too flexible — it requires significant architectural decisions before you can do anything useful. The implementation complexity exceeds the internal capacity to deliver it. After six months and a significant consulting bill, the repository has partial data, no clear ownership, and declining confidence from the business.
This is the trap.
Why the Mismatch Persists
Part of the problem is how the market is structured. Enterprise EA tooling vendors go to market through analysts, consultants, and procurement channels that naturally reach larger organisations. The category has weak representation for the midmarket use case, so midmarket buyers default to the same vendors and reference points as their enterprise peers.
Another part is aspiration. EA tool selection often happens during a moment of ambition — a new IT leader, a digital transformation initiative, a merger. The desire is to do this properly. "Properly" gets conflated with enterprise-grade tooling, because that's what the analyst reports describe.
The honest reality is that most midmarket organisations need something fundamentally different: faster to deploy, simpler to maintain, and designed for the constraint that there is probably one person — part-time — responsible for keeping it current.
What Midmarket EA Actually Needs
A midmarket EA practice needs a handful of specific capabilities. An application inventory with enough structure to classify and score against strategic criteria. A capability model that connects to business priorities. Enough visualisation to communicate to leadership. And something that can be maintained without a specialist team.
The right answer is not a stripped-down enterprise tool. It's a tool designed from the ground up for this context: opinionated enough to get you started without months of metamodel design, simple enough to maintain without a dedicated function, and priced for the budget reality of a midmarket IT team.
These tools exist. The category is less visible than the enterprise platforms — it doesn't appear prominently in analyst quadrants aimed at large organisations — but the alternatives are there for buyers willing to look past the default reference points.
Making the Right Call
If you are in an organisation with fewer than 5,000 employees, one or two people responsible for EA, and an application landscape under 200 systems, the honest recommendation is to start with what you actually need.
You don't need an enterprise EA platform to answer the questions that matter most: Which applications are strategically important? Where are we duplicating capabilities? What is technically unhealthy and underinvested? What does our vendor landscape look like?
A focused tool — one designed for the midmarket use case — can answer those questions from day one. The overhead of a full enterprise platform will consume the time and energy you need for the actual work.
Choosing the wrong tool is not just a wasted procurement decision. It is an opportunity cost measured in months. Every month spent on implementation is a month not spent understanding your landscape and making better decisions.
Start with what you need now. Complexity can come later — if you ever actually need it.
Atlas is built for exactly this context: midmarket organisations that need real EA capability without the enterprise overhead.
Spekir builds the layer that connects strategy to the IT portfolio. See Atlas →
Related articles
Strategy-to-architecture loops: why themes need initiatives need apps
Most EA tools model architecture or strategy, not the loop. Themes without initiatives are aspirations. Initiatives without applications are theatre. Here is the loop in plain language.
10 min read →
Why the strategy-to-architecture gap costs you speed
When strategy and EA operate as separate disciplines, execution slows down. Three symptoms, one structural fix — and why the bridge matters more than either side alone.
9 min read →
Playing to Win for Enterprise Architects
Roger Martin's strategy cascade applied to EA governance: from winning aspiration to management systems, with capability maps and ADRs as the connective tissue.
10 min read →