• the structure of a system

• the role that is primarily responsible for producing these artifacts (the architect)

• the actions and methods which produce these artifacts (by architecting)

• a set of artifacts which aid in understanding that structure (produced by the architect in architecting)

These artifacts describe the structure of a system of interest, how this structure is expected to evolve, and why this will enhance desirable properties of that system over time. As a body of practices, architecture strives to incorporate learning about such evolution - gained from experience in developing, acquiring, and operating similar systems. These methods also strive to organize this knowledge so that it can be applied to similar problems on other projects.

In his book Beautiful Architecture, Grady Booch describes the common multi-disciplinary threads which weave through this pursuit:

In all disciplines, architecture provides a means for solving a common problem: assuring that a building, or bridge, or composition, or book, or computer, or network, or system has certain properties and behaviors when it has been built. Put another way, the architecture is both a plan for the system so that the result can have the desired properties and a description of the built system. According to the earliest surviving work on the subject, Vitruvius' 'On Architecture,' good building should have Beauty (Venustas), Firmness (Firmitas), and Utility (Utilitas); architecture can be said to be a balance and coordination among these three elements, with no one overpowering the others.

Achieving this balance requires active participation from key stakeholders to define and validate the related artifacts which make up its description. This participation should be grounded in a consensus on the use and maintenance of the associated artifacts throughout the system's lifecycle. Architects are the agents responsible for producing, maintaining, and applying these artifacts, as they evolve into tangible expressions of the system’s essence, often through considerable effort.

Architecture should serve as a guiding light rather than a point of fruitless debate, and cannot be adequately captured by a single, static view. Instead, a set of relationships between key elements of the architecture should be revealed (see figure 1). Each architecture definition begins with a careful elaboration of the key elements of the system’s context, the light blue box. This context frames all subsequent actions taken within this scope.

Architectural viewpoints (green box) are always situated within a top-down framework of the system of interest (darker blue box) and outline the components and interfaces of the subsystems within the cooperating systems of the integrated whole and its external environment. Although development often proceeds from the bottom-up, at the level of subsystems and components, planning for integration is most effectively approached from a top-down perspective. In this way, architectures guide the development and delivery of functionalities of these elements, ensuring that the desired architectural qualities manifest at the system level, even if they may not be directly attributable to any single component.

Architecture is as much an art as it is a science; there's no definitive guide for those tasked with creating and defining excellent architecture. This is the reason most literature on architecture focuses on defining what architecture is and how it can be depicted, rather than providing a step-by-step guide to creating it. Consequently, the optimal path to becoming a skilled architect involves extensive mentorship from other accomplished architects. Such mentorship can instill a consistent viewpoint for observing and assessing which methods are most successful in achieving the desired emergent qualities over time. It also facilitates contemplation on the successful architectural works and patterns employed by peers in the field, with particular attention to those that stand the test of time.

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:

1. the byte level, in which system elements exchange unstructured data (such as in application-centric architectures)

2. the message level, where system elements adopt protocols for their information exchanges (such as in message-centric architectures)

3. the data level, where messages relate to specific data objects according to the following principles:

   1. structure, changes, and direction of stateful data are well defined (such as through discoverable service contracts)

   2. states are managed by a particular infrastructure service

   3. applications are stateless (as in the state repository pattern)

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