Enterprise Architecture

Enterprise architecture coordinates architectural work in relation to the organization’s strategy: which capabilities the organization needs, which technologies are approved, where shared services such as identity and data platforms should end up, and how all of that supports the strategy.

The U.S. Federal Enterprise Architecture Framework, version 2, published by the Office of Management and Budget in 2013, describes it as support for planning and decision-making through abstracted views at several levels of scope and detail. Two things in that description are easy to skip. It is about decisions, not documentation. And it works at several levels rather than only the top one.

The framework also separates subject areas — strategy, business, data, applications, infrastructure, and security — which is a useful reminder that enterprise architecture and data architecture are not competing labels. Scope and subject are different axes, so data architecture at enterprise scope and data architecture within one system are both coherent things to mean.

The role produces principles, standards, reference architectures, target states, and approved exceptions. A binding constraint must be met or explicitly changed; a better score elsewhere does not cancel it. Effects on other teams signal a need for coordination, but do not automatically make a decision enterprise-wide. The decision authority should encompass the affected scope and respect delegated authority: two teams may resolve an interface together, a shared platform may need segment-level agreement, and an organization-wide identity policy may need enterprise authority. Solution architecture addresses a particular capability within or across those scopes, rather than occupying a mandatory intermediate tier.

The framework’s idea of line of sight is the counterweight that keeps this honest — work at lower levels of detail should have a visible path to the organization’s outcomes. Read in reverse, it asks enterprise architecture to justify each constraint by the outcome it serves, which is a higher bar than it is the standard. Recording that justification where the people bound by it can read it is what an architecture decision record is for at this scope.

How this level relates to segment and system scope, and which instruments carry constraints downward, is worked through in Architecture Levels and the Scope of a Decision.

References

• OMB, Federal Enterprise Architecture Framework v2 (2013)