Reconciling architectural viewpoints
A desk is a dangerous place from which to watch the world - John le Carre
Viewpoints provide orientation to "establish the conventions by which a view is created, depicted and analyzed. In this way, [each] view conforms to a viewpoint. [IEEE 1471-2000]" A viewpoint thus defines the syntax and semantics for describing each view within an architecture and determines the associated modeling methods or analysis techniques that can be performed on the collections of these views. This language and the techniques which they enable form the foundation for defining a family of solutions that are relevant to the concerns which stakeholders have expressed.
An architectural description (AD) selects one or more of these viewpoints to describe a particular architecture. The selection of viewpoints made after consideration of the stakeholders to whom the AD is to be addressed and their concerns. Within enterprise architecture efforts, viewpoints serve a key role in expressing and reinforcing an enterprise architecture framework and organizing the unique perspectives of stakeholders. Figure 1 (from using the MODAF framework) provides an example of how such viewpoints are to be woven together across the different perspectives of stakeholders, More information on the MODAF model is here, and the process suggested to develop such viewpoints is here.
An architect's primary responsibility is to shape these viewpoints into a set of coherent views of a future state. This state should be achievable through a series of incremental investments that may then be proposed to the system owner. It is important to recognize that the development of such views will be by their very nature iterative and evolving:
There is no such thing as a finished enterprise architecture. Instead, an enterprise architecture should be seen as a living set of documents that guides the use of technology. It is actually much more analogous to a city plan than to a building blueprint. Using the analogy of a city plan to describe an enterprise architecture was a comparison first made by Armour in 1999 and is particularly relevant for today's highly complex organizations. A city plan addresses different issues than do building blueprints. City plans address issues such as the following:
What type of buildings will be allowed in which zones (for example, business or residential)?
How do buildings connect to the city infrastructure (for example, in terms of plumbing and electrical)?
What impact will buildings have on others of their ilk (for example, on air quality and traffic flow)? Are the buildings built to a standard that will not endanger their inhabitants (for example, are they fire and earthquake resistant)?
Imagine a city that included in its city plan a detailed blueprint for every building that would ever be built in the city. Such a plan would be extremely expensive to create, and, if it was ever completed, would be inflexible and stifling. Which, come to think of it, is not unlike some enterprise architectures I have seen.
Despite this, the representations and associated should never lead the client down a path that is either impractical, risky, or fiscally irresponsible.
The utility of adopting a particular viewpoint is that it helps achieve consistency across different views. This is important since information may be represented in more than one view, and the rules on relationships between these views assure that coherence is achieved. The reference model (or 'meta-model') for MODAF is provided here and depicts how key concepts such as capabilities, functions, and data are to be elaborated over time. The elements necessary for any one of these layers can become quite complex, as indicated by the 17 views of the systems viewpoint in DODAF.
To explore these concepts from another viewpoint, consider the Zachman Framework (Figure 2) which was explicitly directed to Information Systems Architecture at an Enterprise level. In this context, the original model was to be used as a classification schema to represent the kinds of information needed from stakeholders across an enterprise.
Zachman originally explained his IT taxonomy using the building industry as an analogy. In that industry, architectural artifacts are implicitly organized using a two-dimensional grid. One dimension of the grid is the various "players in the game." For a physical building, some of these players are the owner (who is paying for the project), the builder (who is coordinating the overall construction), and a zoning board (who is ensuring that construction follows local building regulations). A building architect prepares different artifacts for each of these players. Every player demands complete information, but what constitutes completeness differs for the various players. The owner is interested in a complete description of the functionality and aesthetics of the building. The builder is interested in a complete description of the materials and construction process. The owner doesn't care about the placement of studs in the walls. The builder doesn't care how the bedroom windows line up with the morning sun.
In his book Simple Architectures for Complex Enterprises, Microsoft's Roger Sessions describes the challenges of shaping such viewpoints across multiple stakeholders:
The environment that these observations are made from is challenging as a result of several different factors:
Incomplete and unreliable information about existing assets and infrastructure
complex dependencies with ongoing and emerging projects
evolving organizational responsibilities and partner / ecosystem interfaces, often within the context of tense relationships
escalating direction and expectations from regulatory authorities
The Zachman graphic above has been used by the Veteran Administration to define their Enterprise Architecture. You can browse the contents to evaluate its utility in optimizing their value stream for delivery of health care through their hospital and provider networks, and across their functional organizations.
The first insight offered by the Zachman taxonomy is that every architectural artifact should live in one and only one cell of their model. There should be no ambiguity about where a particular artifact lives or who is responsible for authorship and assurance. Problems will inevitably arise, such as debates over ownership or unclear delegation of authority. As an organization begins accumulating artifacts in the development of an enterprise architecture, it can use the Zachman grid to clarify the focus of each of these artifacts. For example, artifacts relating to a service-oriented architecture live mostly in the third row (a designer's perspective). These artifacts generally will not be of interest to the business owner, though their ramifications may be.
The second suggestion of the Zachman taxonomy is that an architecture can be considered complete only when every cell in that architecture has an adequate set of accepted artifacts. Each artifact is acceptable when the affected players understand, accept, and will support its definition. Once every cell is populated with appropriate artifacts, there should be sufficient detail to fully describe the system from the perspective of every stakeholder, looking at the system from all of the areas of focus. An organization can use the Zachman grid to assure that appropriate discussions are occurring between all the important stakeholders of an enterprise architecture.
The third suggestion of the Zachman grid is that cells in columns should be related to each other. Consider the data column (leftmost of the Zachman grid). From the business owner's perspective, this data is information about the business. From the database administrator's perspective, this data is rows and columns in the database.
Only a limited number of these cells is evident in the VA’s documentation referenced above.
In The Art and Science of Software Architecture,
Models of enterprise architecture (EA) are rarely used to develop assets used downstream. There are several reasons for this. Downstream assets (such as code, documentation for review, and deployment models) are difficult to derive from models using the current state-of-the-art transformation tools, which are typically targeted at single diagrams. An EA model typically provides information spanning several meta-models, and most transformation tools are applicable to a single source meta-model. Deriving downstream assets from EA models may be more feasible – and demonstrably more useful – with mechanisms for integrating different views (from different meta-models) – the results of which could then be applied to transformation. Another difficulty encountered is dealing with non-functional attributes, such as quality-of-service constraints. While mechanisms like the UML Quality-of-Service (QoS) profile can help to enrich EA models with QoS and dependability characteristics, current generation transformation and integration tools must be made aware of these characteristics during the generation and integration process.
According to RTI, these architectures can be classified based on the level at which they govern their data. Application-centric architectures have little or no coordinated governance. As such, they are tightly coupled, as each application must understand their others, so changes tend to ripple through them. As a result, such architectures must evolve under the tight control of authorities who can orchestrate their evolution effectively. In contrast, data-centric architectures organize interactions across components with stateful data, structure, and performance budgets which are explicit, discoverable, and uniform. In these environments, components must adhere to protocols that enable fault-tolerance, scalability, and separation of concerns. The third classification is a message-centric architecture, which manages the flow of information, but not the state data upon which those communications rely. In these contexts, system integrators have found that integration requires interoperability at three levels:
the byte level, in which system elements exchange unstructured data (such as in application-centric architectures)
the message level, where system elements adopt protocols for their information exchanges (such as in message-centric architectures)
the data level, where messages relate to specific data objects according to the following principles:
structure, changes, and direction of stateful data are well defined (such as through discoverable service contracts)
states are managed by a particular infrastructure service
applications are stateless (as in the state repository pattern)
states are accessed and manipulated through a uniform set of operations
Viewpoints can help pull this information together in a form that can be subjected to analysis so that desired attributes can be verified by independent analysis rather than other verification methods brought to bear late in the game.