You're advising a mid-sized company that has never had formal enterprise architecture and is now scaling fast through acquisitions. How would you decide whether to adopt an EA framework at all, which one, and how much of it to actually implement?

## Diagnose first, name a framework second Deciding whether/which framework to adopt should start by diagnosing the org's actual governance maturity and the specific pain that the absence of EA discipline is causing, rather than starting from 'which framework is most respected.' Maturity assessment means asking concrete questions: 1. does anyone currently own a cross-org application inventory; 2. do project teams check for existing capability before building new systems; 3. is there a governance body with actual authority to block or redirect a project, or is architecture purely advisory; 4. how much of the organization's growth is organic versus acquired - acquisitions bring in entirely separate, undocumented architectures overnight, a very different maturity problem than organic sprawl. ## The minimum viable starting set Once the diagnosis is done, the next step is picking the minimum viable set of practices that addresses the specific pain. For an acquisition-heavy scaler, that's usually: - a **lightweight capability taxonomy**; - plus a **due-diligence checklist** requiring every acquired company's applications and data stores be inventoried against it within a fixed window post-close; - plus **one governance decision point** - a review before any acquired system is either kept as system-of-record or scheduled for retirement. This is deliberately much smaller than adopting a full process-driven framework's entire engagement method and content metamodel from day one. ## Why this rather than the whole framework Why this approach rather than adopting a full framework wholesale: organizational capacity to absorb process is itself a scarce resource, and a maturity mismatch is one of the most common reasons EA initiatives fail. An organization with no prior architecture culture that suddenly imposes formal governance boards, mandatory artifact types, and a multi-step engagement method on every project will generate resistance disproportionate to the value delivered in year one, because the teams doing the work haven't yet experienced the pain the process prevents, so the process reads as pure friction. Starting minimal and expanding only once the lightweight version demonstrably prevents a real incident - it catches a duplicate system before it's built, or surfaces a data-ownership conflict during an acquisition before it causes a compliance problem - builds the organizational trust and habit that a heavier framework needs to succeed later. This mirrors a broader principle: **governance process should be pulled in by demonstrated pain, not pushed in by framework advocacy.** ## The trade-offs Trade-offs: - **Starting lightweight risks under-investing** - a truly minimal approach might miss structural risks that only a fuller framework's discipline would have caught, and there's a real cost to migrating from a homegrown lightweight approach to a fuller framework later, since terminology and artifact structures built ad hoc rarely map cleanly onto a framework's formal metamodel, creating a costly retrofit. - **Going heavy from the start risks the opposite failure** - process imposed before the organization has the muscle to use it, producing compliance theater, low-quality artifacts populated just to satisfy a checklist, and architect burnout maintaining documentation nobody reads. The judgment call - how minimal is minimal enough, how fast to expand - is inherently context-dependent: a company scaling through acquisition at a breakneck pace has less runway to grow into a framework organically than one growing slowly, because each new acquisition is a fresh injection of undocumented architecture that the lightweight process must absorb immediately or lose track of forever. ## Failure modes at either extreme Failure modes: the most common failure in this scenario is skipping architecture governance entirely because 'we're too small/fast for a framework,' which works until the company has absorbed five or six acquisitions and discovers it has, say, four different customer-identity systems with no clear system of record, discovered only when a data breach or compliance audit forces the question - at which point the retrofit cost (reconciling identity across four systems under time pressure) dwarfs what a lightweight due-diligence checklist would have cost per acquisition. The opposite failure - a newly hired chief architect imposing a full heavyweight framework immediately - shows up as: - delivery teams routing around governance boards; - missed project deadlines blamed on 'architecture review'; - the framework being quietly abandoned within 12-18 months when a leadership change happens, discrediting EA as a discipline at that company for years afterward. ## A staged adoption that stuck Concrete scenario: a private-equity-backed software company doing roll-up acquisitions of five smaller companies a year adopted, as its entire EA practice initially: - a **one-page capability taxonomy**; - a **mandatory 30-day post-acquisition inventory requirement** feeding a shared spreadsheet-turned-lightweight-repository. Only after two years, once that habit was well established and had already flagged three cases of duplicate billing systems before they became entrenched, did the company formalize a governance board and adopt a subset of a heavier framework's content metamodel to standardize the inventory format - by which point the organization already had the habit and trust needed for the heavier process to stick rather than being resisted.