Target Architecture

A target architecture describes the intended future state within a defined scope and planning horizon: capabilities, systems, data relationships, responsibilities, principles, and constraints. The current state describes the starting position. Comparing the two identifies gaps; a transition plan sequences the work and intermediate states needed to close them. The U.S. Federal Enterprise Architecture Framework (FEAF) combines these views in an Enterprise Roadmap while keeping their roles distinct.

What it contains

In a fictional insurer, the agreed target could place claims adjudication on one platform, connect it to a shared intake service, and use a customer identity master for a specified product and jurisdiction scope. Other customer attributes can remain owned within their business contexts. The target must explain those responsibilities, interfaces, and boundaries. A change list summarizes the gaps but does not by itself describe the future arrangement. Record significant choices and alternatives in an architecture decision record. Describe the current state and unchanged dependencies far enough to assess the proposed changes, risks, and obligations. The detail needed depends on the decision, not a page limit.

What it is not

A target state, a solution design, and a transition plan answer related questions at different levels of detail.

The enterprise target constrains the solution designs that implement it without prescribing every configuration. A target horizon or effective date identifies the intended state; detailed delivery schedules belong in the roadmap and project plans. For the insurer, development can overlap while operational cutover proceeds from customer identity to intake to adjudication. A long-term destination can be more ambitious than the next transition state, provided the intervening work and learning are feasible. MIT CISR describes stages of architecture development and finds that maturity alone does not establish business value. Choose the target and intermediate investments for the business need rather than treating the highest stage as a universal obligation.

Review the target after strategy or operating-model changes, acquisitions, support changes, or recurring exceptions. Also schedule checks of assumptions and whether the event signals cover the relevant estate. A cluster of exceptions prompts investigation: temporary constraints, transition costs, and missing support may explain it without invalidating the target. Record whether to retain the target, improve support, authorize a scoped departure, or change the design. A reference architecture supports recurring designs, while a decision record preserves the reasons for a choice. Their relationship to the capability map and target is developed in Eighty Diagrams and No Answer.

References

• U.S. Office of Management and Budget, Federal Enterprise Architecture Framework Version 2 (2013), introduction and planning guidance
• Jeanne W. Ross and Anne Quaadgras, Enterprise Architecture Is Not Just for Architects, MIT CISR (2012)