3 The Purpose of Enterprise Architecture

A quick perusal of the literature will rapidly highlight that there is no consistent understanding of what an Enterprise Architecture (EA) looks like, or how one uses an EA. Attempts to succinctly define EA speak of fundamental concepts, elements, relationships, and properties of a system. These attempts tend to carry a high level of specialized knowledge and often make little sense to non-specialists. Further, it can be argued that this is the result of many commentators focusing on the architecture they develop, with the implicit assumption that everyone should do the same. Understanding comes from purpose.

EA is a strategic tool that presents an approach to identify and address gaps between aspirations and reality, whatever drives the gaps. It accelerates the ability of an Enterprise to achieve its stated objectives. The tool comes with its method to use, taxonomy to support the directions, and resources needed to benefit from using the tool.

This chapter will address the following questions:

3.1 Why is it Important to Develop an Enterprise Architecture?

An EA is developed for one very simple reason: to guide effective change.

All Enterprises are seeking to improve. Regardless of whether it is a public, private, or social Enterprise, there is a need for deliberate, effective change to improve. Improvement can be shareholder value or agility for a private Enterprise, mandate-based value proposition or efficiency for a public Enterprise, or simply an improvement of mission for a social Enterprise.

Guidance on effective change will take place during the activity to realize the approved EA. During implementation,[5] EA is used by the stakeholders to govern change. The first part of governance is to direct change activity – align the change with the optimal path to realizing the expected value. The second part of governance is to control the change activity – ensuring the change stays on the optimal path.

The scope of the improvement drives everything that is done. A methodology that serves to validate both the objective and the change, ensuring that both are feasible, delivers the desired value, and in a cost-effective manner. An architected approach provides a rigorous planning and change governance methodology.

In its simplest terms, EA must describe the future state and the current state of the Enterprise. The description of the future state enables the right people to understand what must be done to meet the Enterprise’s goals, objective, mission, and vision in the context within which the Enterprise operates. The gap between the Enterprise’s current state and future state highlights what must change. A good EA facilitates effective governance, management, risk management, and exploitation opportunities. A list of gaps makes obvious what must change and the implications of that change: is the proposed project in alignment with what is needed? In alignment with priority? In alignment with the complete set of goals and objectives?

The preceding paragraphs highlight the conceptual scope of EA. This scope often leads to the assumption that EA is only used to answer the big questions. Nothing can be further from the truth. The same concepts, methods, techniques, and frameworks can readily be used to address the end state, preference trade-off, and value realization for big and little questions. The essential difference is not what you do; it is what the documented architecture looks like. The scope of the system varies; the detailed description of elements and properties vary. All of the concepts remain the same.

3.2 What is an Enterprise Architecture?

In short, EA provides the most effective path to realizing an Enterprise’s strategy.[6] A good EA uses a holistic approach to translate strategy into a well-defined execution path, using appropriate analysis, planning, design, and implementation methods.

The purpose of EA is to enable the Enterprise to most effectively achieve the mission, business strategy, and goals through cycles of planning, design, deployment, and delivery of change. An architected approach provides a rigorous planning methodology that validates the business objectives, ensuring that they are feasible, deliver the desired business value, and their achievement is cost-effective.

Achieving this purpose comes from understanding the Enterprise, the context, the scope of change, and the value that will be realized. Using EA facilitates understanding. The Enterprise is described in consistent terms, highlighting fundamental parts and how they interact. Consistent terms enable like-with-like comparison. Potential changes to the fundamental parts are explored regarding the desired end-state and preferences. This understanding and analysis enable trade-off between competing preferences and potential changes that carry different costs and different benefits.

In short, a good EA enables stakeholders to knowingly strike the right balance between any competing set of preferences. It allows individual business units to innovate safely in their pursuit of business value delivery. At the same time, it ensures the needs of the organization for an integrated strategy are met, permitting the closest possible synergy across the extended Enterprise.

3.2.1 Introduction to the EA Landscape

The TOGAF framework uses a concept of the EA Landscape to refer to the complete set of descriptions for the EA. This Guide distinguishes EA Landscape from EA, because there will not be a single description in a comprehensive EA Landscape. At any point in time, a typical Enterprise will have several architectures described. Some architectures will address very specific needs; others will be more general. Some will address detail; some will provide a big picture. Some will address the same topics in different states (current, target, and transition), or different periods of time. To address this complexity, the TOGAF Standard provides a framework for organizing the EA Landscape. The EA Landscape identifies the boundary of all potential architecture, and associated constraints and guidance.

Many characteristics can be used to organize an EA Landscape. An essential concept to recognize is that any initiative to develop and maintain EA populates part of the EA Landscape. Over time, over multiple actions, the EA Landscape is filled and refreshed. Much of the commentary on iteration in the TOGAF framework is designed to address this point.

Instead of considering iteration regarding re-sequencing and looping the ADM, combine the TOGAF concept of an Architecture Project with the concept of the EA Landscape. Every Architecture Project knowingly develops just enough of the EA Landscape to serve the need at hand. The development is done in the context of prior architecture that guides or constrains the current work. Each Architecture Project will create, refine, and potentially change components in the EA Landscape.

When populated, the EA Landscape contains a description, constraints, or guidance that can be used. Without performing repeated information gathering, analysis, review, and approval, the Practitioner cannot proceed with confidence. Existing decisions, guidance, and constraints inform current architecture development. Best practice limits information gathering and analysis to the minimum necessary to address the question at hand. Effort spent on EA returns the highest value when the EA is used. The EA cannot be used until the architect is “done”. All architecture development must be assessed against Time-To-Market (TTM). Filling in only the required parts of the EA Landscape, and following the constraints and guidance already in place, speeds TTM.

Four common independent characteristics frame the EA Landscape:

Figure 1: Characteristics of the EA Landscape

The essential point is to recognize that EA Landscape contents are only developed when needed. Once approved, it constrains all further EA development and use of the EA. For a broader discussion of time, sequence, and business cycle, see Section 5.3.[7]

The dimensions of the EA Landscape help us think about the EA. Keep in mind that, in most cases, it is easy to build a simplification that is not valid. Architecture Projects are not neat cubes similar to what is shown in Figure 2. A real representation would look more like a sea urchin – a consolidated center but with spikes going in all directions.

Figure 2: EA Landscape with an Architecture Project

Looking at Figure 2, the essential point is that the Architecture Project covers a specific portion of the EA Landscape – the portion defined regarding breadth, planning horizon, and detail. Prior work may already exist within the scope. The example does not cover the least or the most detailed layers, nor all time periods nor subjects. Rather the example addresses a specific portion of the landscape. The example Architecture Project will populate, or refresh, a portion of the EA Landscape. Because there is higher-level work, all work in the Architecture Project will be subject to the superior architecture. The example stops at a level of detail so the Practitioner will need to constrain the level of detail. Lastly, the example is within the total planning horizon of the Enterprise and will be constrained by what can and must be done within the planning horizon.

Complicating our lives, the superior architecture may exist either as an unrealized target, unrealized transition, or a realized current state. It must always be kept in mind that where there is not an explicit change in superior architecture, the current state probably remains valid. Lastly, this Architecture Project is a subset of the potential breadth of the scope of the EA Landscape. TTM is a key feature of useful architecture; Practitioners must stick to the scope (breadth, time, detail) of what they have been asked. Work outside the scope may be interesting, potentially even needed in the future, but is not within the scope of this architecture initiative.

The energy and efficacy of an EA team is diluted when it tries to be in every conversation by trying to do too much. The construct of a TOGAF Request for Architecture Work as the entry to Phase A exists to bound the current Architecture Project. The Request for Architecture Work tells the EA team that, within the context of the existing EA Landscape, its Enterprise is looking for a Target Architecture addressing a specific set of subjects at a necessary level of detail that can be accomplished within a particular planning horizon. A substantive output of the Architecture Project is to populate, replace, or reaffirm the contents of the EA Landscape. When stakeholders accept the target, all further EA work, change planning, and change execution are governed by the approved architecture.

3.2.2 Introduction to Purpose

A purpose-based EA Capability model identifies four purposes that typically frame the planning horizon, depth and breadth of an Architecture Project, and the contents of the EA Repository. The purpose-based EA Capability model used in this Guide was introduced in the World-Class Enterprise Architecture White Paper (see Referenced Documents) and refined in the TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (see Referenced Documents).

Figure 3: Purposes of Enterprise Architecture

Typically, there are four broad purposes of an EA Capability:

Architecture for different purposes typically creates different contents in the EA Landscape with a different mix of characteristics. Table 1 summarizes the typical characteristics. Table 1 is developed to represent a scenario, where a strategist uses the same concepts, methods, techniques, and frameworks to develop EA to develop a roadmap that supports the direction of an Enterprise. The strategist’s Architecture Project will drill down from strategy to creating a portfolio that realizes the future state by supporting solution delivery. This table presents how the strategist or the architecture Practitioner’s work addresses the four dimensions of the EA Landscape.

Table 1: Purpose and EA Landscape Characterization

Purpose

Breadth

Level of Detail

Time

Recency

Architecture to Support Strategy

No pattern.

Some Strategy will have a broad impact while other Strategy will cover a narrow subject.

Not very detailed.

May contain point constraints that are very detailed when the value is dependent upon tight control.

Typically, more guidance than constraint.

Typically, looking ahead for a 3 to 10-year period when Target.

Current Architecture to Support Strategy tends to have a short timeframe of validity.

Typically, the need to update and keeping current this architecture is highly variable.

Architecture to Support Portfolio

Will cover single subjects (the Portfolio).

Typically, not very detailed.

May contain discrete constraints that are very detailed when the value is dependent upon tight control.

Typically, valid for 2 to 5-year period when Target.

Current Architecture to Support Portfolio should be considered past its best-before date. A portfolio without a view to the future is pointless.

Typically, the need to update and keeping current this architecture is highly variable.

Architecture to Support Project

Narrow breadth, typically discrete Projects within a Portfolio.

Typically detailed.

Will contain detailed constraints, that may not be fully supported by detailed architecture descriptions.

Typically, more constraint than guidance is developed.

Typically, valid as a target for <2 years.

Will have very long-lived timeframes as current (post realization).

Typically, will be retained in the EA Landscape for an extended period after transition from Target to Current.[8]

In the absence of an Architecture Project, the architecture and associated constraints and guidance will continue indefinitely.

Architecture to Support Solution Delivery

Typically, very narrow breadth.

Most detailed EA.

Will contain the most detailed constraint.

Typically, only constraints will be developed, as guidance will be carried forward from superior architecture.

Typically, valid as a target for <2 years.

Will have very long-lived timeframes as current (post realization).

Typically, will be retained in the EA Landscape for an extended period after transition from Target to Current.

In the absence of an Architecture Project, the architecture and associated constraints and guidance will continue indefinitely.

3.2.3 What an Enterprise Architecture Looks Like

EA exists to guide and constrain change planning and work to perform the change. The scope of work embedded in a Request for Architecture Work should identify the applicable characteristics of the EA Landscape. Over time, through multiple Architecture Projects, the EA Landscape is populated. This still does not tell us what actually gets written down, nor exactly what is produced.

In short, a Practitioner will need to document three things:

  1. Models, in the EA Landscape
  2. Views derived from the EA Landscape
  3. Other useful things

In short, the architecture is the set of models, the components, and their relationships that comprise the scope of the EA Landscape under consideration. These models consistently describe the current and Target Architecture. In a theoretical world, a single unified model is produced. Typically, a set of models is produced. These discrete models will either have a jury-rigged linkage or rely on the expertise of those using the models to leap between them. Models can vary in formality, some strictly conforming to a semantically constrained structure, while others are quite flexible.

The primary purpose of the models is to facilitate the architect to understand the system being examined. Understand how it works today, understand how it can be most effectively changed to reach the aspirations of the stakeholders, and understand the implications and impacts of the change.

A secondary purpose is re-use. It is simply inefficient to re-describe the Enterprise. The efficiency of consistency is balanced against the extra energy to describe more than is needed, and to train those who describe and read the descriptions on formal modeling. The size, geographic distribution, and purpose of the EA team will dramatically impact the level of consistency and formality required.[9] Formal models are substantially more re-usable than informal models. Formal models are substantially easier to extend across work teams. The penalty is that formal models require semantic precision. For example, regardless of the structure of an application in the real world, it must be represented in a model conforming to the formal definition. This representation is possible with a good model definition.

Architecture Projects may have unique aspects. Practitioners usually lose the ability to address Architecture Project-specific considerations in a standard representation. The reverse is also true; flexible definitions that directly support one analysis will not be shared nor communicated with others in the EA team. Often the unique aspects will not even be remembered by the author. Practitioners must trade off between re-use and optimal fit, and should ensure that they are optimizing for the entire EA team rather than personal preference.

Every model that is produced and maintained has a price in effort. When effort exceeds value, the price will be paid by hindering an Enterprise’s ability to perform the effective change. Unnecessary models and analysis steal from guiding effective change. Every approach to modeling is designed to shed light on one or more aspects of the Enterprise. Typically, narrow, special-purpose models facilitate detailed analysis while broad models facilitate inclusive analysis. All approaches to modeling – formal/informal and broad/narrow – are trade-offs.

All EA Landscapes that support a broad range of purposes will be comprised of a set of models. This set could be contiguous or discrete, targeted for analysis or communication. A core unified model can provide a common bridge between discrete models. The more specific a model, the more important it is to an analysis. The more important a model to analysis, the more important is the need and clarity of linkage across models. Careful thought is needed to understand the long-term need for cross-linkage. Most analyses are performed repeatedly over a period of time for different purposes. Like informal models, jury-rigged or expertise-based linkage is a short-term answer that prohibits effective re-use.

Models are very useful for the architect. They form consistent representations of the parts of the world that must be understood and analyzed. Shorthand communication and consistent analysis reduce the TTM.[10] However, because models are partial representations of the whole, typically described with a limited language that requires experience to read, and often subject to constraints designed to show relationships, models tend to be ineffective to communicate usefully. Consider a balance sheet; it is a great model to outline part of an organization’s financial position. It requires skill to read and is silent on the success, margin, or lifecycle of new products. Do not rush to deliver the models sooner than necessary.

Models are poor general communication tools. Good models are carefully constrained to exactly tell part of a story. They will carefully control the components available and the available relationships. They will enforce some attributes. They carefully render a complex environment into something that represents the world in terms it can be understood, optimized, and compared. They tend to require specialist knowledge, and often carefully constrain common terms in a way casual consumers do not align with.[11]

The best communication comes down to views, and “other useful things”. Views have a specialized role in communicating the architecture and are discussed in Section 3.3.1. The phrase “other useful things” is purposefully open-ended. For example, it is normal to find that a high fraction of useful communication is highlighting the value of the target state, acknowledgment of the scope of anticipated change, or clarifying the date value is expected. Most of the effective communication about an architecture will be “other useful things”.

3.3 How to Use an Enterprise Architecture?

An EA is developed for one very simple reason: to guide effective change. Practitioners use models to provide a consistent analysis of complex systems. Models provide efficient long-term representation that enables like-with-like comparison – comparison of what is, what was, and what might be. The comparison that facilitates trade-off between potential changes that carry different costs and different benefits. Models provide understanding to people who understand the language, structure, and limitations of a model.

Guiding effective change is driven by who is using the architecture. Three broad communities use the EA: stakeholders, decision-makers, and implementers. Each of these communities uses the architecture differently.

When starting to talk about communication, the problem of terminology is the first obstacle faced. “Stakeholder” is a useful term, and multiple frameworks and methods use the term. Be aware of when you are carrying implied meaning from one framework, or approach, to another. This Guide follows ISO/IEC/IEEE 42010:2011 guidance on stakeholders which focuses the attention on those whose concerns are fundamental to the architecture, or architecturally significant.[12] Facilitating effective communication requires us to make a distinction between other communities who are interested in the architecture. A stakeholder holds approval rights on the target and the implementation; an implementer requires guidance and constraint; and a decision-maker holds execution rights on change. Practitioners are advised to develop views that address a stakeholder’s concerns. Success of an architecture rests on the clarity and focus of the views produced. Its sole purpose is to communicate that the Target Architecture best satisfies the complex set of requirements the Enterprise has. Practitioners are best served when they preserve the distinction between stakeholders with approval rights and those needing most recent data points to create appropriate views of the concerns addressed by the EA. Without clarity on distinct roles, Practitioners complicate governance of the EA and the change projects.

3.3.1 Communicating with Stakeholders (Concern and View)

This Guide provides practical advice to a Practitioner on using the TOGAF framework. Stakeholders’ concerns and views are one area where the theoretical constructs embedded in the TOGAF Standard are correct, but not directly translatable to use. The TOGAF Standard takes a formal modeling approach to understanding stakeholder, concern, and view; this has led some to interpret that all representations of architecture are views prepared for any conceivable interest. That interpretation is correct, just not helpful,[13] considering usefulness and TTM. This Guide will emphasize the point “do just enough to support key decisions at this moment”. Getting more data and providing more detail may sound appealing. The only thing an architect does not have is time. Do the right things to the best level of detail to market the architecture, and make people use the architecture. If there is time, pursue creating the rest of the views and elaboration if and when necessary.

Further, stakeholders, views, and concerns are often explained in terms of a single architecture. Consider what an EA Landscape will actually contain: Multiple discrete architectures. Separated by purpose, detail, breadth, time, and recency. And then there is architecture states: current, transition(s), and target. An architect’s first obligation is ensuring the architecture addresses the preferences of the Enterprise. When the Practitioner preserves the stakeholder’s concern, the view to communicate with the stakeholder, and how the architecture will address their concern, something useful to govern against in addressing this obligation naturally emerges.

From a practical perspective, consider:

The TOGAF concept of an Architecture Project provides context for both the development of new architecture and the change to realize it. By practically constraining the use of stakeholders to those with approval rights Practitioners enable governance, and more importantly governance in context.

This Guide constrains the concerns to a topic and addresses the stakeholder’s power, interest, and requirements against this topic. This approach surfaces topic-based decision rights and provides the ability to perform a trade-off between competing requirements. The chapters discussing a walk through the ADM for different purposes will expand on the use of concerns. Pragmatically, most requirements will cluster in six to nine topic areas that are derived from the Enterprise’s strategy. In fact, most concerns are consistent from one Architecture Project to another – they cluster around the central challenges the Enterprise is trying to address, such as agility, efficiency, IT complexity, or customer journey.

A consistent set of core concerns aligned to Enterprise priority facilitates focus on priority. Every Architecture Project brings to the fore Enterprise priorities and is in a position to demonstrate how this initiative is addressing the priority. Further, Practitioners are in a position to confirm consistency of requirement within a concern, and by stakeholder. Confirming consistency, or the lack, enhances the Practitioner’s ability to discern the set of preferences the Enterprise is chasing.

Table 2 provides an extended TOGAF Stakeholder Map including concern and requirement. Missing requirements within a concern can either be a gap in information gathering or a demonstration the stakeholder is saying “this does not matter”. Knowing requirement or lack of preference in relationship to power and interest directly facilitates trade-off. The trade-off is performed within a concern and between the concerns.

Table 2: Sample Stakeholder Map

Concern 1

Concern 2

Power

Interest

Requirement

Power

Interest

Requirement

Stakeholder 1

High

Low

Low

High

Stakeholder 2

High

High

Low

Low

Stakeholder N

Low

High

High

Low

Views address a stakeholder’s concern about a specific architecture. In a perfect world Practitioners are able to use a single model directly. This is a mythical happy place. It will never be possible for a key issue such as agility or cost.

A view simply addresses a stakeholder's concern about an architecture. Often it is a potential architecture, and the view serves to help the stakeholder’s potential target and associated change. This allows a stakeholder to put things in context and have confidence about the target and the change.

When stakeholders understand the architecture, the change, and the trade-offs, implementation governance is possible. Fail, and expect continuing issues as point answers highlighting one potential benefit without any compensating trade-off emerge throughout the planning and execution cycle.

When establishing the EA Capability, it is likely common classes of stakeholder were identified. If this was done essential concerns were likely identified.[14] These concerns represent the questions that the EA Capability is expected to answer, and may be considered mandatory. Successful high-functioning EA teams will maintain a library of viewpoints (see Appendix C) designed to address the questions they are expected to have answers for. Each viewpoint should identify the concern, the stakeholder(s), how the view should be constructed, and the information required to address the question.

Viewpoints are specialized communication to stakeholders that explicitly address a concern. Keep in mind that any associated requirements may not be satisfied by the architecture. The view is not a demonstration that the stakeholder should be happy; rather it is a demonstration of how the architecture addresses the concern.

3.3.2 Communicating with Implementers (Gap, Specification, and Control)

Implementers are typically poorly served. It is common to see implementers handed with a set of diagrams that represent the architecture. From these diagrams the implementers are expected to figure out the gaps they should fill, the architecture specifications they must conform to, and the controls they must implement. Implementers are better served when they are explicitly provided context, gap, architecture specification, and control.

The TOGAF Standard identifies a very useful concept for communication with anyone implementing the Architecture Contract. An Architecture Contract identifies the responsibility of the implementation team to the Target Architecture’s stakeholders. The most critical items to an implementer are:

The essential component is to fulfill the purpose of the TOGAF Architecture Contract: link the Implementation Project to the target in terms of context, work required, and conformance test. Most critically, stop setting the implementers up by expecting them to work out what is expected and how the project’s design and implementation will be assessed.

John Carver’s policy governance approach[15] is one of the best for a Practitioner to follow. There are two imperative practices in Carver to follow. First, specifications should be exclusionary, highlighting what is prohibited, rather than mandating what is permitted. Second, specification compliance should be assessed through a reasonable interpretation test by a reasonable person.

Drafting specifications as exclusionary reduces the requirement for omniscience during architecture development and provides the maximum opportunity for creativity during implementation, whether the creativity comes from innovative thinking by the design team, new technology, new third-party services, or new processes. Understanding what is prohibited, assumes everything else is allowed. The key concept is if the architecture does not constrain a choice, or prohibit a choice, the choice is allowed.

Given that creativity is encouraged, Practitioners cannot expect that an implementation team can read minds and implement in the same way as envisioned. This forces the compliance assessment to be a test of reasonable interpretation. The best practice is always to link a specification to a requirement.[16] This allows the design, or implementation, to be assessed against a requirement/specification pair. The specification is in the context of what motivated the specification. Following this practice, every specification exists to deliver something, and the implementation can be value tested.

When Practitioners serve the implementation team well, the stakeholders are supported. Practitioners provide the big picture to guide projects implicitly to value production, and requirement/specification pairs to guide the projects explicitly to value. In both cases, the value being produced is directly traceable.

3.3.3 Communicating with Decision-Makers (Other Useful Things)

The last community who must be communicated to are decision-makers. Typically, decision-makers will have a strong overlap with stakeholders. This distinction is necessary to ensure that the stakeholder/concern/view construct is restricted to the approval of the target. The ability to have crisp governance of the target and approval is too important to blur the line and include other communications.

Like communicating with implementers, communication to decision-makers often falls into the category of “other useful things”. An architecture roadmap or the strategic architecture are empirical in nature. They are supported by conversations around “motivation statements”, demonstrating how the scope of change aligns to goals including why each step is essential, the foundational nature of some of the Implementation Projects, employment of an appropriate compliance report for decision support, etc. Such conversations fall under “other useful things”. It may not be possible to create appropriate models to support these communications.

Decision-maker communication will typically be aligned with:

Communication about timing is typically drawn from either the Roadmap, the Implementation & Migration Plan, or from Phase G. Timing speaks to when can the decision-maker expects activity to start, change something, complete something, or start to obtain value.

Trade-off decisions between stakeholders need to be communicated to others in the Enterprise. They are usually not involved in the trade-off. Communication about trade-off decisions is typically educational, serving to explain the trade-off decision. Critical conversations on trade-off by prior architecture and superior architecture will be held during Phase F, G, and H, informing decision-makers.

Status conversations are about the Architecture Project. The most important status conversations are about closing on an Architecture Vision in Phase A, resolving complex trade-off in Phases B, C, and D, and value, effort, and dependency conclusions regarding the Roadmap’s work packages in Phase E. The status of value realization conversations will occur in Phase H. Depending upon the status of value, further conversations about architecture change requests, or initiating a new Architecture Project may occur.

Decision-makers have a deep interest in the budget. During Phase F’s planning exercises some of the most complex trade-off decisions are made. Conversations with stakeholders during architecture and roadmap development revolve around value, effort, and risk. In Phase F spend is brought to the fore. Further, during Phase G budget control and availability will impact all Implementation Projects.

Best practice has decisions on non-compliance being made by stakeholders. They need to approve the recommendation to enforce the target, grant relief, or change the architecture. Communication about compliance is very similar to trade-off conversations. Also, when relief is granted, further conversations about scheduling a roadmap or implementation plan update should also occur.

Some of the most critical conversations with decision-makers are about confidence. The confidence they should have in the Roadmap and Implementation & Migration Plan, completing the change, and realizing the value. All architecture is an approximation; no Practitioner can underestimate the importance of confidence.

3.4 Conclusion

In order to guide effective change, Practitioners have to understand complex systems and analyze the possible ways to improve the complex system against a set of usually contradictory preferences. In order to understand and analyze a complex system, good Practitioners will represent the system in a set of models. These models are the architecture – a description of the system in terms of components and their relationships. Over time, through multiple Architecture Projects, the EA Landscape is populated.

Using an architecture requires translation of the models to a form that is useful to non-specialists. Practitioners should not expect stakeholders, implementers, decision-makers, or anyone else to understand the models’ specialized language, structure, and limitations.

Practitioners need to communicate with three broad communities: stakeholders, decision-makers, and implementers. Each of these communities uses the architecture differently.

Stakeholders are presented with views that address their concerns. This enables stakeholders to understand the architecture, engage in trade-off decisions, and finally approve the Target Architecture.

Implementers need to understand their project. First, where their project fits within the roadmap, and its role in producing value. Second, what work packages and gaps they are responsible for, as well as associated gaps they are not responsible for. Third, how conformance will be assessed.

Decision-makers’ communication often falls into the category of “other useful things”, where Practitioners communicate timing of change and value, prior decisions, status, budget, and confidence. All Practitioners need to keep in mind that informal communication, outside the scope of models, architectures, views, roadmaps, specification, or compliance recommendations, are the most important communication that will be undertaken.

An effectively communicated architecture is one that provides confidence. The importance of confidence cannot be underestimated. Confidence that the architecture and associated roadmap of change is the guidance the Enterprise should follow. With confidence, an Enterprise’s leadership will use the EA to direct and govern effective change.

return to top of page

Copyright © 2022 The Open Group, All Rights Reserved.
TOGAF® is a registered trademark of The Open Group
<<< Previous Home Next >>>