Enterprise Architecture for Mid-Sized Companies: Start Lean, Show Impact

Summary: Enterprise architecture is widely seen as a large-enterprise discipline — and that perception costs mid-sized companies money. The need is not triggered by headcount but by complexity: 40+ applications, parallel initiatives, an upcoming ERP replacement, growth through acquisitions. What the mid-market needs is not an EA department but three artefacts, a part-time role and a decision path. This article describes how we get to dependable architecture work in about 90 days in Portamus client projects — and what we deliberately leave out.

Key takeaways

• The trigger is complexity, not company size: from roughly 40–50 applications or five parallel initiatives.
• Three artefacts are enough to start: application inventory, target state (18–24 months), roadmap.
• The role is typically a 20–40 % assignment, not a new team.
• Tailor TOGAF rather than execute it fully — the standard is explicitly built for that.
• No tool at the start. A spreadsheet plus Archi carries the first 12–18 months.
• The most common mistake is the documentation start; what works is the decision start.

Why mid-sized companies skip EA

The familiar EA references come from organisations with dedicated architecture departments, repository suites and formal boards. To a company with 400 employees and an IT team of twelve, that looks visibly oversized — and the obvious conclusion is “not our league”.

The architecture decisions get made regardless. They are simply made implicitly: inside projects, under time pressure, without a view of the whole landscape. We see the resulting pattern in almost every mid-market IT landscape analysis:

• Functional duplication — two to four systems with overlapping scope, typically procured by different departments.
• Point-to-point integration — grown interfaces whose failure impact nobody fully understands.
• Invisible end-of-life risk — systems out of vendor support, discovered in an audit rather than in planning.
• Projects without pre-assessment — every procurement restarts the architecture debate from scratch.

None of this reflects a lack of competence. It reflects the lack of an authority.

What the mid-market actually needs

Across our projects one pattern has been constant: three artefacts deliver the overwhelming share of the value.

Everything else — a complete metamodel, a repository, a formal board, comprehensive modelling — is optional in the mid-market and should only follow once these three artefacts are actually maintained.

The 90-day start

This is how we typically sequence the entry:

Days 1–30: transparency. Capture the application inventory (interviews plus analysis of contracts, licences and access data); record owner, cost, support status and systems of record per application. Assess it with the TIME grid from application portfolio management: tolerate, invest, migrate, eliminate.

Days 31–60: direction. Draft a coarse target state per business domain, agreed with department heads. In parallel, formulate five to eight architecture principles — an organisation of this size will not carry more (see EA governance for how to shape them).

Days 61–90: commitment. Derive the roadmap from the gap between as-is and target, prioritised by risk and value. Define the decision path: who reviews project requests, on what cadence, with what written output? In the mid-market a monthly architecture forum with the head of IT and two business representatives is usually enough.

Observation from practice: the turning point is almost always the first meeting in which a procurement request is deferred with reference to the target state. From that moment architecture stops being a document and becomes an authority.

Tailor TOGAF instead of working through it

TOGAF is explicitly adaptable — the ADM is meant to be tailored to size and maturity. For mid-sized companies we typically use:

This selection is not a compromise against the standard; it is the standard used as intended. For a full explanation of what TOGAF is and what the ADM delivers, see What is TOGAF?.

Tooling: deliberately late

The EA tool question arrives early in mid-market projects — and is almost always premature. Our recommendation:

• Phase 1 (0–12 months): a maintained spreadsheet for the application inventory, ArchiMate models in the free tool Archi, documents in the existing filing system.
• Phase 2 (from roughly 12–18 months): consider an EA repository once several people maintain data in parallel, dependencies need automated analysis, or the inventory reaches three digits.

A tool does not create architecture work; it scales existing work. Where no maintenance routine exists yet, the licence just buys another abandoned database.

Proving the value

Management boards do not decide on models; they decide on effect. What holds up:

• Avoided parallel purchases — the inventory shows before procurement that the capability is already licensed.
• Cancelled redundant licences — regularly the first measurable effect in our projects.
• Shorter pre-assessment of project requests, because target state and principles already exist.
• Visible EOL and support risk, before it becomes an incident.
• Lower integration effort once systems of record are settled.

A single-page landscape picture with colour-coded risk lands harder in a board meeting than any complete repository.

Common mistakes

• Starting with documentation. A complete as-is survey before any visible benefit burns attention.
• Copying large-enterprise templates. Role models built for 80 architects do not work with 1.5 people.
• Tool before routine. A licence does not replace maintenance ownership.
• EA without a mandate. Without protected time and executive backing, every project outranks the architecture.
• Too many principles. Five to eight is the realistic ceiling in the mid-market.
• No update trigger. Without coupling to procurement or change, the inventory is stale within months.

Frequently asked questions

Is enterprise architecture worth it for mid-sized companies? Yes, in adapted form: an application inventory, a target state for 18–24 months and one authoritative decision point — achievable with a part-time role.

At what company size do you need enterprise architecture? Complexity is the trigger, not size: more than roughly 40–50 applications, five or more parallel initiatives, a core system replacement, acquisitions or a cloud migration.

Do mid-sized companies need TOGAF? As a toolkit yes, as a full ADM cycle no. Use principles, a shortened Phase A, coarse target states and the roadmap.

Who takes the EA role? Usually an existing person at 20–40 % of their time — head of IT, senior application owner or lead developer. Mandate and protected time matter more than the title.

Which tool do you need? At the start, none that costs money: a spreadsheet plus Archi covers the first 12–18 months.

What does getting started cost? A scoped engagement of a few weeks for inventory, assessment, target state and roadmap; then 20–40 % of one role on an ongoing basis.

What is the most common mistake? Starting with documentation instead of with a pending decision.

How do you demonstrate value to the management board? Through avoided parallel purchases, cancelled redundant licences, shorter pre-assessments and end-of-life risks surfaced early.

Conclusion

Enterprise architecture works in mid-sized companies — but only in tailored form. Three artefacts, a part-time role with a mandate, five to eight principles and a monthly decision slot beat any large-enterprise model that collapses for lack of capacity. Our experience from Portamus projects: the difference between architecture work that sticks and architecture work that fades is not the maturity of the method but whether the architecture was tied to a real, pending decision.

Facing an ERP replacement, a cloud migration or an acquisition — and want the architecture settled first? We get you to an inventory, a target state and a roadmap within weeks. → Explore the Portamus enterprise architecture assessment

Sources

• The Open Group: TOGAF Standard, 10th Edition — Architecture Development Method, Tailoring (2022)
• The Open Group: ArchiMate 3.2 Specification (2022)