Developing an Architecture View
High-functioning enterprise architects use an architecture view to show fitness with stakeholders.
Stakeholders see the enterprise architecture expressed in architecture views. Each view explains the architecture in terms of a concern. Seeing the architecture expressed in architecture views allows stakeholders to trade-off against competing needs.
Pragmatically, concerns are simply subject areas for stakeholders to assess the enterprise architecture. Different stakeholders will have different preferences and priorities. We find that developing a simple matrix highlighting the mandatory stakeholders and concerns form the foundation of a predictable enterprise architecture. Different enterprise architecture purposes will have slightly different necessary stakeholders and concerns.
Good architects will have keyed in on the terms mandatory & EA Purposes. They know that different EA Purposes address different questions and use the resulting decisions differently. An organization using good enterprise architecture to guide every change effort to move the organization closer to a preferred target requires consistent trade-off comparisons. Mandatory stakeholders and concerns directly enable hard trade-offs.
High-functioning EA teams are predictable. They know the key questions that need answering, the information required, and they re-use previous analysis and decision. They deliver. A viewpoint library is the foundation. The approach to building a viewpoint library is straightforward. Not easy, just straightforward.
At the base of a viewpoint library are the concerns that form the basis of trade-off. Consider the classic cost vs. agility trade-off, or another old chestnut, time-to-market vs. sustainability. The set of key trade-off decisions provide the mandatory concerns. In practice, the good architect finds a target that provides time-to-market & sustainability. No sense performing trade-off on everything when good architects can narrow trade-off discussions to where there is a true trade-off against competing preference.
We provide custom enterprise architecture training for developing Architecture Views and Viewpoints.
Developing a Viewpoint Library provides a repeatable, fast path to delivering value. Identify what you need to know to explain the target in terms of normal criteria.
Architecture views have an important role in enterprise architecture governance. Despite this many consider architecture views a bureaucratic overhead and avoid them.
The Leader's Guide Chapter 8 speaks about identifying the criteria your stakeholders normally use. Then optimize your method to use these criteria.
Avoiding artificial trade-off and addressing true trade-off requires capturing the stakeholders’ preferences within a concern. For every stakeholder concern the architect needs to obtain the stakeholders’ preferences. Preferences can be stated regarding priority, minimum requirements, or developed through previous analysis and trade-off.
Enterprise architects used to architecting after critical decisions are made often look for requirements, instead of preferences. In the absence of superior architecture requirements should not be available until after the set of stakeholders perform trade-off. Requirements limit the architects and stakeholders degrees of freedom. They lock down parts of a possible answer and force the architect and stakeholder to work around immovable objects. Worse, most requirements are only badly considered trade-off decisions.
You can find additional stable, enduring practice in the TOGAF Body of Knowledge.
The Personal Enterprise Architecture Kickstart spends several sessions exploring Communicating with Stakeholders, Concerns and Architecture Views.
The 12-week program to be a better architect is free.
Stakeholder questions dive architecture views
Identifying stakeholders has been unnecessarily complicated by terminology definitions. Formal definitions have to be broad enough to include a multitude of edge-cases. After blurring the definition to include all reasonably conceivable stakeholders, the definition provides no means to focus our attention. ISO 420101’s guidance and TOGAF 9.1’s stakeholder management technique are useful. Best practice is to limit the use of the term stakeholders to those whose ‘concerns are considered fundamental to the architecture’, or those ‘with power’.
Once the EA Team has narrowed on a set of mandatory stakeholders and concerns, a viewpoint library can be developed. We know who must be served, and the subjects used to perform trade-off. We know which architecture views we need to prepare.
We are ready to fill out the Viewpoint Library Template.
Speed Development with Viewpoint Library
| What is the Concern? What is one criteria the stakeholder will use to assess the target architecture? | Who is the Stakeholder? | What does the enterprise architect need to know to describe the target architecture in terms of the concern? | How will the View be constructed? |
| Change Impact - What is the impact, or scope, of a change to the architecture? | Senior Leader | Changes to existing initiatives (Work, Outcome & Value). Changes to budget Changes to organization. Changes to operations. Changes to customer engagement. Changes to infrastructure (Facility, Plant & IT) | Tables work very well. You will never be able to identify Change Impact without a Gap. |
In Navigate we have a set of starter viewpoint libraries. These include standard concerns, stakeholders, and the Navigate meta-model entities required to address regular questions. We invest heavily in our viewpoint libraries, and the view construction techniques. We ruthlessly minimize the information demands of the EA Repository. We focus the EA Team on required value. (We also struggle with great visual representations: ABACUS’ 3D bubble/relationship charts only go so far when comparing multiple possible road maps)
Without a viewpoint library, we trap the enterprise architect without a stopping point. Rather than working on the primary stakeholders’ concerns and the associated trade-off decisions, they work on random issues. Low functioning enterprise architects pretend to address an infinite number of individuals, teams, or organizations with interests in the outcome masquerading as stakeholders.
When this happens, we compromise enterprise architecture governance. You never get past the trap of architecture by assertion.
The last stage of developing a viewpoint library is working on “View Construction” and “Information Required.”
Architecture View is not a simplified model
Most modeling tools and discussions confuse architecture views and models. A view addresses the architecture regarding stakeholder and concern. Models simplifications of the real world that show us how components fit together—a description so darned close to what an architecture is that we may as well accept that an architecture is a model. Few mandatory concerns will have a viewpoint that can be constructed using a single model or analytic technique.
Save time with Viewpoint Library
EA Team’s with radically lower information demands are positioned to crisply focus time and energy on expected value and real stakeholders. Without clarity on mandatory stakeholders and concerns, they will spend time chasing distractions, like a Jack Russell Terrier. In a perfect world, the EA Repository and Content Meta-model are tightly aligned. Discrete information needs referencing separate catalogs and matrices, or models that need to be developed in the EA Repository.
This stage requires close work with your EA Leader and EA Repository experts. Consider the questions your EA Team must answer, what information you need to address the mandatory concerns. What architecture view will you use?
Challenge everything. Ruthlessly minimize the analytic load. If every so-called trade-off decision has picked time-to-market over sustainability, the enterprise architects need to architect. Listen to the stakeholders and develop a target that enables time-to-market. Get out of the trap of Knowing Better. Provide analysis to support real trade-off.
We cannot stress enough the iterative nature of this stage. Far too many teams submerge themselves in minutia not required for any EA Purpose, let alone the current EA Purpose. Fun facts and minutia are distractions from the end-goal of supporting decision making and facilitating stakeholders' direct and control change.
Become efficient at developing an architecture view. Develop your Viewpoint Library. Look at your architecturally significant stakeholders, and their concerns. When your analysis and reporting focus on the primary stakeholders’ concerns, you are focused on value. You will align your architecture to your organizations’ preferences and priorities. If you started from a low-functioning place, you might not recognize yourself. However, you will follow a repeatable, fast path to delivering value.
Save work with Architecture Alternatives
Package potential answers together as Architecture Alternatives. Then assess the Alternative against the stakeholder concerns. This will save time.
A classic EA Trap is thinking you have an architecture and architecture views because you have a system diagram.
View are used in all domains. Security Architects will create architecture views related to security and risk concerns.
The Leader's Guide and the Practitioner's Guide provide a sample set of core stakeholders and concerns for architecture to support portfolio.
Conexiam’s EA Capability Practice’s most sustained area of research is Architecture View Construction. We also call it visualization.
Navigate is oriented towards quantification. We aim to support trade-off and iterative decision making.
In every Predictable EA Sprint allocates time to improving the EA Team’s toolkit. A high fraction of time is working on the Architecture Viewpoint Library, and information analytics. Ruthless minimization takes time and practice.