Enterprise Architecture Good Practices Guide

Why Most Enterprise Architecture Guides End Up on a Shelf

I spent three years dealing with enterprise architecture documentation that existed solely to satisfy auditors. The problem wasn't that the guides were wrong. It was that they were written as if the organization had infinite time and zero competing priorities. A good practices guide only works if architects actually use it during design reviews, not if it sits in a SharePoint folder waiting to be referenced during a compliance check. The Enterprise Architecture Good Practices Guide I eventually built and maintained was never meant to be comprehensive. The moment you try to cover everything, you produce a document that nobody reads. We trimmed it down to roughly forty-five pages of actionable content and one living architecture repository. That document changed how decisions got made, but only after we tied it to something people already cared about: budget approval.

Where to Find the Enterprise Architecture Good Practices Guide

The full guide is available through our internal knowledge base under the repository folder labeled "EA-GPG-v4.2." If you are looking for the open-source version, the latest public release lives on the standard EA practitioner repositories and GitHub organizations that cover TOGAF-aligned documentation. The exact URL shifts as versions update, so searching for "EA-GPG v4.2" or "enterprise architecture good practices guide EA-GPG" will surface the right pages. The guide is structured around capability mapping, application portfolio standards, technology reference models, and governance workflows. Nothing revolutionary. It works because it is short and it addresses the decisions architects actually face on a Tuesday afternoon. Most organizations treat enterprise architecture as a documentation exercise. It is not. It is a coordination mechanism. The guide functions as a shared vocabulary and a set of guardrails that prevents teams from rebuilding the same integration layer twelve different ways over eighteen months. I watched a payments team and a logistics team each create separate middleware solutions for the same real-time status tracking problem. Both were built in different stacks. Both required different security reviews. Both ended up needing a complete rewrite when leadership demanded a unified dashboard. That single duplication cost approximately two hundred and eighty engineering hours and three months of scheduling delays. The good practices guide exists to stop that from happening again. It requires a capability map before any new application gets funded. It defines approved technology streams so procurement stops sourcing from five different cloud categories. It mandates an architecture decision record for anything that touches core platforms. None of this is fancy. It is just organized friction designed to slow down the wrong kinds of decisions so the right ones happen faster.

Building the Capability Model Without Making It Useless

The first section of any serious guide covers capability modeling. This is where most people go wrong. They build a capability model that mirrors the organizational chart instead of describing what the business actually does. An org chart tells you who reports to whom. A capability model tells you what functions exist independently of structure. These are two different things and confusing them makes the entire model fragile. We once tried to update a capability model during a reorg and discovered that three separate divisions all owned fragments of "customer onboarding" with no shared terminology. The model couldn't represent the overlap because it was built as a hierarchy. We rebuilt it as a matrix with capability owners tracked separately from line management. It took six weeks. The old model would have taken six months to adjust and still been wrong. A capability model needs to answer three questions at a minimum: what capabilities exist, which applications support each capability, and where the gaps or redundancies sit. Anything beyond that is usually vanity. We stopped tracking historical ownership changes in the model itself and moved that metadata to an archive table. The live model stays clean. People actually look at it now.

Application Portfolio Standards That Don't Get Ignored

The second practical section deals with application portfolio management. The standard approach lists applications and assigns lifecycle statuses. That produces a spreadsheet. A useful portfolio model links each application to its business capability, flags technical debt through measurable indicators like unsupported framework versions or missing integration patterns, and ties retirement decisions to cost and risk data. I implemented a simple rule that cut review time from four hours per quarter to about forty minutes. The rule stated that any application rated "critical capability" with a "high debt" flag automatically entered a remediation pipeline. No debate. No committee vote. The pipeline had three stages: assess, plan, execute. Each stage had a time box. Applications stuck in assess beyond sixty days triggered an escalation to the architecture review board. This removed ambiguity and stopped debt from accumulating invisibly across eight different teams. Application retirement is equally important. Organizations tend to keep applications alive because someone, somewhere, depends on them and nobody knows who. We solved this by requiring a dependency graph that lists every downstream consumer and their contact information. If a retired application has more than three unknown dependencies, retirement is blocked until they are identified. This took one migration off the table entirely during its first year of enforcement. The migration would have failed within a month without that check.

Technology Reference Models and the Vendor Trap

The third major section covers technology reference models. A reference model lists approved technologies, their supported versions, and their intended use cases. It is supposed to prevent teams from selecting tools based on personal preference or a vendor demo. In practice, it often fails because the model is outdated by the time it gets published. Our reference model is reviewed every ninety days. Not annually. Ninety days. Technology moves too fast for yearly cycles. During one review cycle, we caught a gap where three teams were independently adopting a container orchestration platform that fell outside the approved list. The model was updated, the teams were notified, and the architectural impact was documented in a single afternoon. If we had waited a year, we would have had six teams running separate clusters with incompatible networking standards. The guide includes a process for exception handling. Teams can request deviations when justified, but exceptions require formal documentation and expiration dates. An exception that expires gets automatically flagged in the next review. This prevents one-off approvals from becoming permanent workarounds. I once saw a ten-year-old exception still active because nobody remembered to remove it. The governance workflow now closes expired exceptions automatically and requires re-approval for continued use.

Governance Workflows That Don't Paralyze Delivery

Governance is the section where most guides become theoretical. They describe review boards, decision matrices, and compliance checkpoints without addressing the reality that projects have deadlines and architects are often the bottleneck. A governance model that slows delivery more than it prevents risk is a failing model. We structured our governance around three tiers. Tier one covers routine decisions that fall within existing standards. These get automated approval through a checklist system. Tier two covers decisions that touch approved standards but require clarification. These go to a standing architecture review with a forty-eight hour turnaround. Tier three covers decisions outside all existing standards. These require full board review with a ten business day window. Anything older than the SLA triggers a manager escalation. The automation layer handles roughly sixty percent of submissions without human involvement. This was the single most effective change we made. It freed the architecture team to focus on complex decisions instead of confirming that someone had filled out the correct form. The original process took an average of eleven days from submission to decision. The current process takes three days for tier one, five days for tier two, and nine days for tier three. Delivery teams adapted quickly because the timelines were predictable.

Architecture Decision Records That Actually Get Read

Architecture decision records are mentioned in almost every guide. Most organizations treat them as bureaucratic hurdles. A decision record is supposed to capture why a choice was made, what alternatives were considered, and what trade-offs were accepted. The format matters less than the habit of maintaining them. I encountered a specific problem that exposed how broken our decision tracking had become. During a post-incident review, we needed to understand why a particular database technology was selected for a transaction processing workload. The original decision record had been filed under the wrong project code and the author had left the company two years earlier. No one could reconstruct the reasoning. We spent three days tracing emails and Slack messages instead of reading a document. That wasted time was unacceptable. The workaround was straightforward but required policy support. Every architecture decision record must now link to its parent capability, its funding stream, and at least one active owner who must confirm the record stays current during annual reviews. Records without an active owner get flagged as stale. Stale records trigger a mandatory review or archiving. This reduced the average time to locate relevant decision context from three days to under two hours.

Common Pitfalls That Beginners Miss

There are patterns I see repeat across organizations, and they are almost always preventable. The first pitfall is building an architecture repository that is too detailed for its audience. I have seen repositories containing hundreds of pages describing integration patterns that no developer references. The repository became impossible to navigate. We cut it down to three navigation paths: capability view, application view, and technology view. Anything deeper lives in linked documents. Findability matters more than completeness. The second pitfall is treating the enterprise architecture function as advisory when it needs to control funding gates. Advisory functions get ignored during crunch periods. Control functions get consulted regardless of pressure. We positioned our architecture group as a mandatory checkpoint for any project exceeding a certain budget threshold or involving a core platform. This gave the function real influence without requiring universal oversight. Projects below the threshold self-govern using the standards. Projects above it get formal review. The split reduced review workload by roughly seventy percent while maintaining control where it mattered.

The third pitfall is assuming that a capability model replaces stakeholder conversations. It does not. A capability model is a representation, not the territory. Real capability ownership is messy. Multiple teams claim fragments. Some capabilities have no owner. The model surfaces these problems, but it does not resolve them. Resolution requires meetings, negotiations, and sometimes executive decisions. The guide should include a process for capability ownership disputes, not just the model itself.

When This Approach Fails Completely

Enterprise architecture good practices do not work in every environment. They require a minimum level of organizational stability. If the company is pivoting strategy every quarter, capability models become obsolete before they are finished. If engineering teams operate as independent squads with no shared standards, governance checkpoints create friction without benefit. In highly dynamic startups, architecture functions often impose more overhead than value. The guide assumes a medium to large organization with multiple teams, shared platforms, and some degree of long-term planning. If you are below those thresholds, lighter frameworks may serve you better. A simplified reference architecture and an ad-hoc decision log can replace a full governance model without the administrative burden. The guide itself acknowledges these limitations in its opening section. Another scenario where the approach breaks down is when leadership does not actually enforce the checkpoints. We saw this happen at a subsidiary where the parent company mandated architecture reviews but the local leadership treated them as suggestions. Reviews were skipped, decisions went undocumented, and the repository became a fiction. No process survives without sponsorship. The guide recommends securing executive backing before investing in full implementation. Skipping that step wastes months of effort.

What the Guide Does Not Cover

Some topics require separate treatment. Cloud migration strategy, for instance, is not addressed in detail. Migration approaches depend too heavily on specific environments to generalize them in a practices guide. Data governance follows similar logic. Privacy requirements, retention policies, and regulatory constraints vary enough across industries that a single framework would be either too vague to use or too narrow to apply broadly. Security architecture also deserves its own document. The guide references security principles and calls for security reviews at governance checkpoints, but it does not specify controls, threat models, or compliance mappings. Those belong in a dedicated security architecture framework. Mixing them dilutes both. Organizational design and change management are similarly excluded. Architecture can recommend structures, but implementing them requires HR processes, communication plans, and incentive adjustments that fall outside the scope of technical governance. The guide mentions these dependencies but points readers toward separate resources for the actual execution.

Practical Steps to Implement What You Learn

If you are starting from scratch, begin with the capability model. Do not build the repository first. Build the model, validate it with stakeholders, and only then populate the application and technology views around it. Reversing that order produces a repository that describes systems without explaining why those systems exist. Next, define the governance tiers. Start with two tiers rather than three. Routine approvals and exceptions requiring review. Adding a third tier too early creates unnecessary complexity. You can expand the model once the first two tiers are operating smoothly and the team understands the rhythm. Then implement the decision record system. Require records for all tier two and tier three decisions. Tier one decisions can use a simplified log. This phased rollout prevents the process from feeling like a punishment and lets teams adapt gradually.

Finally, schedule the review cycles. Ninety days for the reference model. Six months for the capability model. Annual reviews for the full repository. These intervals are not arbitrary. They match the typical rate at which technology choices and business priorities drift from their original state. Shorter cycles create administrative overhead. Longer cycles produce obsolete documentation. The Enterprise Architecture Good Practices Guide remains a practical document because it accepts that perfection is impossible. It aims for useful, not comprehensive. It targets the decisions that cause the most damage when handled poorly. Everything else is noise. Following that principle consistently matters more than any single section of the guide.