Target Architecture

A target architecture describes where an organization wants its business and technology to be at a point in the future, typically three to five years out. It sits alongside a description of the current state, often called the baseline, and the difference between the two defines the work required. Because the full target is rarely reached in one step, architects usually also describe intermediate stages, known as transition architectures or plateaus, that can each be reached and operated in their own right.

The target architecture turns strategy into something concrete enough to plan and fund. Statements such as "become more data-driven" or "simplify our systems" become specific decisions about which applications will exist, which will be retired, how data will flow and which platforms will be standard. For IT strategy and finance, a well-defined target, with costs attached to each stage, shows what the future state will cost to reach and to run, and whether it is worth pursuing.

Definition of Target Architecture

A target architecture is a model of the desired future state of an organization or part of it, covering some or all of the business, data, application and technology layers of enterprise architecture. It is described using the same views and terms as the baseline so the two can be compared directly.

In TOGAF, target architectures are developed in the business, information systems and technology phases of the Architecture Development Method, and the gaps between baseline and target drive migration planning.

Baseline, Transition and Target States

The baseline architecture describes the current state as it really is, including duplication, workarounds and outdated technology. An honest baseline is essential, since every estimate of effort and cost depends on it.

The target architecture describes the intended end state. It is usually defined at a level of detail that guides decisions without fixing every technical choice in advance.

Transition architectures describe stable intermediate states. Each one should deliver business value and be safe to operate for an extended period, in case later stages are delayed or changed.

Many organizations call these intermediate states plateaus, since each represents a level the organization can stand on before taking the next step.

Gap Analysis

Comparing baseline and target reveals the gaps: capabilities that must be added or improved, applications to build, replace or retire, data to consolidate and technology to adopt or remove.

Each gap becomes a candidate piece of work. Grouping related gaps into work packages and ordering them by dependency produces the enterprise architecture roadmap.

Gap analysis also exposes what will not change, which helps teams avoid unnecessary work on systems that already fit the target.

Importance of Target Architecture in Enterprise Architecture

A target architecture gives projects a shared destination. Without one, each project optimizes for its own goals and the organization's technology drifts in many directions at once.

It makes trade-offs visible. Leaders can see what will be retired, what will be standardized and what new capabilities will be added before committing funds.

It provides a reference for governance. Architecture reviews can ask whether a proposed design moves the organization toward the target or away from it, which is a clearer test than general principles alone.

Pricing the Future State

A target architecture is far more persuasive when each state carries a cost. Comparing the annual run cost of the baseline with the run cost of each transition state and the target shows the savings or added costs over time.

The one-time cost of moving between states, including projects, migration and parallel running, completes the picture. Together they support a business case built on net present value or payback.

Linking architecture models to total cost of ownership data lets organizations compare alternative targets on cost as well as technical merit, before choosing one.

Keeping the Target Realistic

Targets that are too ambitious lose credibility when early stages slip. Targets that are too vague give little guidance.

The target should be reviewed when strategy, technology or costs change significantly. A target set five years ago may assume products or prices that no longer apply.

Each transition state should be justified on its own merits, so that progress is worthwhile even if the full target is never reached. This protects the organization against changes in funding or direction.