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.
- The 90-day start is a six-step sequence with named effort and duration — the consolidated version sits under “The EA start as a six-step approach” below.
- DACH readers: Germany and Austria are where this exact model was built; the section “Why German and Austrian companies need a different EA shape” covers the procurement, audit and mid-market specifics.
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.
| Artefact | Content | Initial effort | Effect |
|---|---|---|---|
| Application inventory | All productive applications with owner, department, cost, support status, systems of record | 2–4 weeks | Duplication and EOL risk become visible |
| Target state (18–24 months) | Coarse target landscape per business domain, with named replacements and consolidations | 2–3 weeks | Projects gain a shared direction |
| Roadmap | Sequenced initiatives with dependencies and decision points | 1–2 weeks | Investment becomes plannable instead of reactive |
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.
The EA start as a six-step approach (steps, effort, duration)
For readers who want the sequence as a single table — here is the 90-day start above broken into steps, with the effort and duration each takes in our projects for a mid-sized company (100–1,000 employees, 2–12 IT staff):
| Step | What happens, what you get | Effort (external support) | Duration |
|---|---|---|---|
| 1. Anchor to a pending decision | ERP replacement, cloud migration or acquisition defined as the use case; scope of the EA start derives from it | 1 workshop, half a day | Week 1 |
| 2. Application inventory | All productive applications with owner, cost, support status, system of record — from contracts, licences and access data plus interviews | 2–3 weeks | Weeks 1–4 |
| 3. Portfolio assessment (TIME) | Tolerate / Invest / Migrate / Eliminate per application; redundancy and EOL risk become visible | 3–5 days | Weeks 3–5 |
| 4. Target state (18–24 months) | Coarse target landscape per business domain, agreed with department heads and the management board | 2–3 weeks | Weeks 4–7 |
| 5. Principles and roadmap | 5–8 architecture principles; roadmap with risk- and value-prioritised initiatives and decision points | 1–2 weeks | Weeks 6–9 |
| 6. Decision path and maintenance trigger | Monthly architecture forum with a fixed output; inventory update coupled to procurement and change | 1 workshop + setup | Weeks 8–12 |
Total: step 1–5 is the 90-day start; step 6 lands by the end of week 12. Ongoing effort afterwards is 20–40 % of one role — usually the head of IT or a senior application owner. The first measurable effect (a procurement request deferred with reference to the target state) typically appears in month 2–3; licence cancellations in month 3–6.
Why German and Austrian companies need a different EA shape
The EA literature most DACH mid-market companies read comes from Anglo-Saxon practice. Four points of the adoption context are different in Germany and Austria:
- The trigger comes from procurement and audit, not from an architecture department. German and Austrian mid-sized companies are early adopters of ISO/IEC 27001 and increasingly run EU-cybersecurity-related documentation duties. Auditors and procurement ask why a system landscape has no system-of-record map, no EOL view and no dependency map. That external pressure is the most reliable sponsor for the EA start — and it is exactly why an inventory that can be maintained beats a repository.
- The decision path must reach the management board (Geschäftsführung). In companies under 1,000 employees investment and architecture decisions often sit with the same two or three people. A forum that doesn’t reach the management board loses in project reality — which is why step 6 names the management board as a participant. In large enterprises this is a board; in the German and Austrian mid-market it is the owners or the operating partners.
- Tool decisions are data-protection decisions. The model will contain costs, owners and system dependencies — business-critical data. That makes tool selection (hosting, access rights, processor status, EU hosting) a GDPR question, not a budget question. It is one more reason “spreadsheet plus Archi first” is the right order in the DACH mid-market.
- The EA role stays part-time. Unlike the Anglo-Saxon large-enterprise references, the DACH mid-market does not build architecture departments. The 20–40 % role with a management-board mandate is the working model — and it is why the deliberately lean metamodel (five to eight principles, two to three artefacts) has to be the design constraint, not the compromise.
Choosing an EA consulting partner in Germany (DACH)
If you bring in a partner for the start — or want to check whether an existing EA initiative is worth continuing — these are the criteria that separate a usable outcome from a documentation project:
| Criterion | What to check | Why it matters |
|---|---|---|
| Mid-market references | EA starts with 100–1,000 employees, ideally in Germany or the DACH region | The right size is the difference between a forum and a bureaucracy |
| Decision start, not documentation start | Whether the partner anchors the start to a pending decision (ERP, cloud, acquisition) | A documentation start loses management attention before the first benefit |
| Lean metamodel by default | Five to eight principles and 2–3 artefacts as the starting position — not as a scaled-down version of a large-enterprise offering | Maintenance capacity, not scope, is the failure point |
| Embedded decision path | Whether the architecture forum reaches your management board and has a fixed output | A forum without a management-board mandate is advisory, not decisive |
| Tool stance | “Spreadsheet plus Archi first” — repository only on demonstrated need | A licence without a maintenance routine becomes an abandoned database |
| DACH context | Experience with ISO/SOX-driven documentation, GDPR-driven tool decisions, German-language governance | The outcomes have to survive your auditors, not just your IT team |
| Business case | Whether the partner prices the start as a scoped engagement with a measurable effect (avoided parallel purchases, cancelled licences) — not as open-ended consulting | A business case in avoided costs is what keeps the mandate alive in the first year |
Red flag: a partner who opens the conversation with a tool demo or whose reference list is made up of large-enterprise-only engagements.
A typical DACH mid-market start runs 8–12 weeks for the six steps above; the follow-on is the 20–40 % role. Portamus operates from Oberhausen (North Rhine-Westphalia) and delivers EA starts for mid-sized companies across Germany, Austria and the DACH region — as part of its enterprise architecture consulting for mid-sized companies — lean enough that you can run the model yourself afterwards.
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:
| TOGAF element | In the mid-market | Why |
|---|---|---|
| Architecture principles (Preliminary) | Yes, 5–8 of them | Highest effect per unit of effort |
| Phase A – vision | Yes, shortened | Clarify scope and stakeholders |
| Phases B–D – target architecture | Yes, coarse level | Target state per domain, not a detailed model |
| Phases E/F – roadmap | Yes | Where the management value sits |
| Phase G – implementation governance | Lightweight | A forum instead of a board |
| Phase H – change management | Later | Only meaningful once the inventory is maintained |
| Full content framework | No | Effort without an audience |
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.
What does a concrete EA start look like — steps, effort, duration? Six steps: anchor to a pending decision (week 1), application inventory (weeks 1–4), TIME assessment (weeks 3–5), target state for 18–24 months (weeks 4–7), principles and roadmap (weeks 6–9) and decision path with a maintenance trigger (weeks 8–12). Ongoing: 20–40 % of one role. See “The EA start as a six-step approach” for the full table.
Who can set up EA for a mid-sized company in Germany or the DACH region? Check mid-market references (100–1,000 employees), a decision-start stance, a lean metamodel by default and an embedded decision path reaching the management board. Portamus delivers EA starts for mid-sized companies in Germany, Austria and the DACH region — for example via the EA assessment or EA consulting.
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 — the usual entry point into our enterprise architecture consulting in Germany.
Sources
- The Open Group: TOGAF Standard, 10th Edition — Architecture Development Method, Tailoring (2022)
- The Open Group: ArchiMate 3.2 Specification (2022)