The foundation of a high-functioning EA team is a viewpoint library. Stakeholders must see their concerns addressed by the architecture to properly approve a target. Viewpoint Libraries provide a repeatable, fast path to delivering value. Despite this many consider them bureaucratic overhead.

Pragmatically, concerns are simply subject areas for stakeholders’ preferences. 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 EA practice. Different EA 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 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.

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.

Practitioners 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.

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 are ready to fill out the Viewpoint Library Template.

Viewpoint Library Template

Concern	Stakeholder	View Construction	Information Required
The list of mandatory concerns	The list of mandatory stakeholders	Describe how the view will be constructed. This will include analytic, visualization and modelling techniques. Keep in mind that different stakeholders may have different visualizations.	Describe the information required. This may be discrete information including catalogs and matrices in the EA repository or models that need to be developed.

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 are investing 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 the practitioner is trapped without a stopping point. Rather than working on the primary stakeholders’ concerns and the associated trade-off decisions they work on random issues and pretend to address an infinite number of individuals, teams, or organizations with interests in the outcome masquerading as stakeholders. When this happens, governance of architecture creation and consumption is compromised so badly it is impossible. It is practically impossible to get past the trap of architecture by assertion in prepare a Portfolio Roadmap without a viewpoint library highlighting the core stakeholders and mandatory concerns.

The last stage of developing a viewpoint library is working on “View Construction” and “Information Required.” Most modeling tools and discussions confuse 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.

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 Jack Russell Terriers. In a perfect world, the EA Repository and Content Metamodel 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. Challenge everything. Ruthlessly minimize the analytic load. If every so-called trade-off decision has picked time-to-market over sustainability the practitioners need to start architecting. 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.

Conexiam’s EA Capability Practice’s most sustained area of research is View Construction, or as we call it visualization. We have oriented Navigate towards quantification that supports trade-off and iterative development of informed requirement. This orientation provides a wealth of data we use for analysis and reporting on our deductions & inferences. All are calling out for powerful visualization.

In every Predictable EA Sprint we allocate time to improving the EA Team’s toolkit. In practice, a high fraction of time is iteratively working on the Viewpoint Library, visualization, and information analytics using the EA Repository. Simply assess prior trade-off , and the resulting specifications and controls to refine the concerns driving future trade-off. Ruthless minimization takes time and practice.

Take the time to 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. Your architecture will be aligned to your organizations’ preferences and priorities. If you started from a low-functioning place, you might not recognize yourself. However, you will be following a repeatable, fast path to delivering value.

Next Steps

As a starting point, we suggest the Leader’s Guide. It addresses establishing a high-functioning EA Team aligned to your organization’s required purposes. In addition to freely available self-help materials, like the Leader’s Guide, we provide consulting services and specialized training like our EA Capability Workshop.

Conexiam made a strategic decision to share our experience with the world. We are taking highly re-usable parts of Navigate in publications like this article, the Architecture Graveyard blog series, and formal peer reviewed publications like Digital Transformation: Strategy to Implementation. We look forward to continuing the conversation with you.