The Enterprise Architect

Most businesses run on a stack of dependencies that was assembled by accident. A spreadsheet from year one. A SaaS the previous head of marketing chose. A CRM that was the cheapest option in the trial. A handful of integrations stitched together over time by whoever was available. The cumulative effect is a system that no single person fully understands and that no one can rebuild without taking the business down. The cost of this kind of accidental architecture is not failure — most accidentally-architected businesses run for years. The cost is opportunity: the version of the business that should be running on a deliberate architecture is materially more profitable, more defensible, and more transferable, and it does not exist.<br><br>This pillar is the most direct framing of where engagement with our practice is paid and specific. It is not a content marketing pillar. It describes a category of work — enterprise architecture for operator-scale businesses — that is intentionally narrow, intentionally concrete, and aimed at a specific kind of buyer: the operator who has already crossed enough complexity threshold to know that the accidental version of their stack is becoming expensive, and who does not want to hire a permanent architect to fix it.

What enterprise architecture is, in operator terms

Enterprise architecture, stripped of the consulting-industry framing, is the discipline of designing how a business's information systems support its operations and its growth. It is concerned with three things in particular: what the business owns versus rents, where the data lives, and how the systems talk to each other. The deliverables are not slide decks. The deliverables are decisions that compound over the next decade.

The reason the discipline has a reputation for being abstract is that the consulting tradition has produced enormous quantities of abstract output. The operator-focused version is the opposite — concrete, decision-oriented, delivered as a written architecture document with explicit choices, explicit tradeoffs, and an implementation sequence that can be executed. We write for the operator who is going to either implement it themselves or hand it to a small team that will. The audience is the person making the decisions, not an audience that needs to be sold on the concept.

Who this engagement shape fits

The kinds of business where the engagement is most useful, in our experience:

• Owner-operated businesses between five and fifty headcount where revenue is established but the systems supporting it have not been deliberately architected. The operator suspects the stack is more expensive and more brittle than it should be, and is right.
• Founders preparing for institutional capital where the due-diligence process is going to expose the accidental architecture, and the valuation is going to absorb the discount. A deliberate architecture is the single highest-leverage pre-raise investment we have seen.
• Established practices considering a generational transition where the accidental architecture has become tied to specific people whose departure would take operational knowledge with them. A documented architecture is the only durable mitigation.
• Operators with multiple business lines where the lines have been allowed to develop independent stacks and the cost of non-integration is becoming visible.

The kinds where it does not fit: very early-stage businesses where the dominant constraint is finding product-market fit; operations large enough to need a full-time architect; cases where the operator wants validation rather than honest assessment.

How the engagement runs

The engagement is structured in three phases over four-to-six weeks of elapsed time:

Phase one — current-state review. A documented map of everything the business currently runs: every SaaS, every database, every automation, every integration, every recurring cost, every data flow. The deliverable is a written assessment of what is owned versus rented, where data lives, where it does not flow that should, what the failure modes are, and what the cumulative cost of the current architecture is. This phase alone is frequently the first time anyone has produced a complete system-level view of the business.

Phase two — target architecture. A written architecture document describing the deliberate version of the stack: what is owned, what is rented, where the data lives, how the systems talk to each other, what the automation surface looks like, where AI fits, what the cost structure is, what the failure modes are. The document is not a slide deck. It is a specification an implementing team can build against, with explicit choices and explicit tradeoffs.

Phase three — sequenced implementation plan. The transition from current to target, ordered to minimise disruption to revenue. Where the first quarter of work goes. Where it does not. What the dependencies are. Where outside vendors or hires are needed. What the failure-rollback plan is at each step.

The end of the engagement is a written document that the operator owns. The document is the deliverable. We can implement against it ourselves, introduce a team that can, or hand it over for the operator's existing team — the choice is theirs.

What we will not do

The engagement does not include strategic positioning, marketing, brand, or growth advice. We are explicitly architectural. The reason is honest: the people who do strategic positioning well are not the same people who do architectural work well, and conflating the two produces mediocre output in both directions. Adjacent practitioners we trust on the strategic and marketing dimensions exist; we introduce when relevant.

The engagement also does not include long-term retainer work. The deliverable is a written architecture and a sequenced plan. Implementation, if it happens with us, is a separate engagement on different terms. The discipline of separating the two protects the architectural integrity of the deliverable — a consultant whose retainer depends on producing implementation work has structural pressure to recommend more implementation than the business actually needs.

Pricing and scope discipline

The engagement is fixed-fee, with the fee a function of the scale of the operation and the complexity of the existing stack. We quote on a written scope. We do not bill hourly. We do not bill by deliverable count. The structure is deliberate — fixed-fee aligns the incentives. The operator wants the best architectural answer; we want the answer to be tractable to deliver in the agreed time. Hourly billing creates pressure in the opposite direction.

The fee is real, in the order of a small senior hire's monthly salary rather than a side-of-desk consulting rate. The reason is that the work it replaces is twelve to twenty-four months of accumulated architectural drift, and the savings it produces — both in operating cost and in opportunity-cost of the right architecture being available sooner — are an order of magnitude larger than the fee. We will not engage at lower fee levels because the work cannot be done well at lower fee levels.

What good architectural work feels like

The signal of good work, from the operator's side, is a sense that the business has become legible. They can describe the stack to a new hire in under an hour. They know what every piece costs. They know what would happen if any specific component disappeared overnight. They can answer the diligence questions an institutional buyer would ask without calling anyone for help. The accidental complexity has resolved into deliberate complexity, where the parts that are still complex are complex for reasons the operator can articulate.

The signal from our side is similar: a written document we are willing to stand behind, that another architect would read and consider thorough, with explicit choices made on explicit grounds, no hand-waving on the parts that matter, no padding on the parts that don't. The aesthetic of architectural work, properly done, is restraint. Most of the document is plain prose with a small number of diagrams. None of it is impressive for its own sake.

Adjacent specialisms we draw on

The pillar pages on sovereign infrastructure, AI systems, and the cognitive domicile are not separate practices from this one. They are the specific architectural patterns we apply within the broader engagement. An operator commissioning architectural work who wants a sovereignty-first stack will see the patterns from the sovereign infrastructure pillar in the target architecture. An operator with an AI initiative will see the AI systems patterns. An operator whose business has a meaningful physical footprint will see the cognitive domicile patterns transferred to the operational infrastructure of the business itself.

The pillars are not separate products. They are the lenses through which the architectural work is delivered. The deliverable is one document, covering whichever of the lenses the business actually needs.

How to know if it is the right time

Three diagnostic questions:

1. Could you produce a complete inventory of every system the business runs in under an hour? If no, the work is overdue.
2. If your most senior operations person left tomorrow, would the business still know how to operate? If no, the work is overdue.
3. If you had to take the business through institutional due diligence next quarter, do you know what the valuation discount from the current architecture would be? If no, the work is overdue.

If any of the three answers is no and you have crossed enough scale that the architecture has become expensive to ignore, the engagement is appropriate. If all three answers are yes, the engagement is unnecessary, and we will say so on the discovery call.

What the document looks like at the end

The deliverable is typically forty-to-eighty pages of written architecture, structured against a consistent template across engagements, organised so the operator can read the whole thing in one sitting and so an implementing team can read any individual section in isolation. The structure looks like this in most cases:

• Executive summary. One page. The current state in two paragraphs, the target state in two paragraphs, the implementation summary in two paragraphs. Written so a board member can take the decision from this page alone if necessary.
• Current-state inventory. The full map. Every SaaS, every database, every automation, every integration, every recurring cost. Diagram-anchored. Footnoted. Cross-referenced.
• Failure-mode analysis. What happens when each component breaks. Which breakages are silent. Which breakages cascade. Which components have no rollback.
• Target architecture. The deliberate version. Component-level decisions, with explicit rationale, explicit alternatives considered, and explicit tradeoffs accepted.
• Cost analysis. Current monthly run-rate, target monthly run-rate, one-time transition cost, payback period.
• Sequenced implementation plan. Quarter by quarter, ordered to minimise revenue disruption, with dependencies, decision gates, and rollback plans at each step.
• Open questions. The decisions we deliberately did not make on the operator's behalf, with our recommendations and the reasoning. These are typically commercial choices, vendor preferences, or hiring decisions that should remain with the operator.

The document is the deliverable, and the document is what we stand behind. The implementation work that may follow is a separate engagement; the document is independently complete and useful even if no further engagement happens.

Related pillars