Viewpoints - Understanding Our Stakeholders

In my previous reflection, the notion of viewpoints was raised to make sure we mark that these are mechanisms which help us remember why we do what we do, as advocates of EA.

Viewpoints represent each group of stakeholders' interest on the architectures, i.e.  A particular viewpoint takes a focused slice through any or all of the 4 layers of the future state (Business, Information, Application, Technology) to make sure that IT initiatives are taking care of their concerns. 

I think Schekkerman provides one of the clearest explanations for views and viewpoints. Using ANSI/IEEE Std 1471- 2000, he shared the definitions from the standard, and I, in turn, share it here, and provide it verbatim:

A system is a collection of components organized to accomplish a specific function or set of functions.

The architecture of a system is the system's fundamental organization, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. An architecture description is a collection of artefacts that document an architecture.

Stakeholders are people who have key roles in, or concerns about, the system: for example, as users, developers, or managers. Different stakeholders with different roles in the system will have different concerns. Stakeholders can be individuals, teams, or organizations (or classes thereof).

Concerns are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system. Concerns may pertain to any aspect of the system’s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability.

A view is a representation of a whole system from the perspective of a related set of concerns. In capturing or representing the design of a system architecture, the architect will typically create one or more architecture models, possibly using different tools. A view will comprise selected parts of one or more models, chosen so as to demonstrate to a particular stakeholder or group of stakeholders that their  concerns are being adequately addressed in the design of the system  architecture.

A viewpoint defines the perspective from which a view is taken. More specifically, a viewpoint defines: how to construct and use a view (by means of an appropriate schema or template); the information that should appear in the view; the modeling techniques for expressing and analyzing the information; and a rationale for these choices (e.g., by describing the purpose and intended audience of the view).

Every view has an associated viewpoint that describes it, at least implicitly. ANSI/IEEE Std 1471-2000 encourages architects to define viewpoints explicitly. Making this distinction between the content and schema of a view may seem at first to be an unnecessary overhead, but it provides a mechanism for reusing viewpoints across different architectures.

--------------------------------------------------------------------------------------------------------
In his paper, Schekkerman continues to expand on these notions with his concept of extended viewpoints and viewpoint themes, which helps us understand that we can continue to define viewpoints as long as these help define stakeholder's concerns --  so we can make them happy with the EA which we create for the organization. His paper discusses economic, legal, ethical, and discretionary viewpoints as examples of viewpoint extensions.

From these discussions,  I think  we can simply say that a view is the object (say architecture) in front of us. In turn,  we can perhaps say that a viewpoint is a deliberate focus on specific things about the view which concerns us  - the vantage point or perspective that determines what we selectively see about the object.

This discussion can perhaps be assisted with an analogy -- again the car.  The following provides a singular notion of the car view (in this case, the total architecture). Using our definitions, we can think that different viewpoints project a specific "slice" that is significant to each different group of eyes (stakeholder group).

The brake system

The Cooling system

The Electrical system

The Transmission system

In conclusion,  we return to why viewpoints are important. These are the abstractions which allow us to stay clearly connected to the stakeholders who ultimately, our enterprise architecture needs to satisfy.

Springman's HBR article mentions research which shows that organizations who place stakeholders’ interests ahead of profits generate greater workforce engagement -- and thus deliver the superior financial results that they have made a secondary goal. This is indeed, counter-intuitive, but appears to hold true.

He argues for a strategy to engage stakeholders:  First, identify the stakeholder groups and their concerns. Next, create a value proposition for each stakeholder group.  This value creation for each stakeholder group needs to be balanced by what the business will gain in return -- the value it will extract from the relationship. The next step is to track the costs and benefits associated with each value proposition, including the investment necessary to complete the initiatives required to fill the capability gaps you’ve identified. And finally, determine a set of key performance indicators. These should track how effectively the business is creating value for each stakeholder group and how well you’re capturing value in return. 

"Defining the value created for and from each stakeholder group adds perspective, ensuring that you look at your business from all angles. And by focusing on value creation for all your different stakeholders, you will be a creating a business that is more sustainable -- in all senses of the word."

Helpful References:

Schekkerman, J. (2006 January ).  Extended Enterprise Architecture Viewpoints Support Guide.  White Paper. Institute For Enterprise Architecture Developments.  Retrieved from http://www.enterprise-architecture.info/Images/E2AF/Extended%20Enterprise%20Architecture%20ViewPoints%20Support%20Guide%20v18.pdf

Springman, J. (2011 July). Implementing a Stakeholder Strategy. Web Article. Harvard Business Review.  Retrieved from https://hbr.org/2011/07/implementing-a-stakeholder-str

The Open Group. (n.d.). Developing Architecture View. Online Documentation.  The Open Group. Some of the material is from The Command and Control System Target Architecture (C2STA), which was developed by the Electronic Systems Center (ESC) of the US Air Force between 1997 and 2000. Retrieved from http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap31.html

Steen, M.W.A,  Akehurst, D.H., ter Doest, H.W.L.,  Lankhorst, M.M. (2004). Supporting Viewpoint-Oriented Enterprise Architecture. Research Paper. Proceedings of the 8th IEEE Intl Enterprise Distributed Object Computing Conf (EDOC 2004), 1541-7719/04. Retrieved from PSU Library Online.