Architectural Governance by Principles

An enterprise architecture is rarely if ever successfully implemented in its entirety in a single project; it is generally implemented incrementally, as a succession of individual business solution projects or coordinated solution programs. How one thinks of architecture critically affects the ability to govern the implementation of these solutions. Modeling is often emphasized as the basis for architecture, but principles provide a more robust foundation that makes it possible to straightforwardly derive solution-level governance from enterprise-level governance.

Architectural Governance

Peter Weill and Jeanne Ross, in their book IT Governance, write “Effective IT governance must address three questions:

• What decisions must be made to ensure effective management and use of IT?
• Who should make these decisions?
• How will these decisions be made and monitored?”

This article explores the last of these questions—how a particular subset of IT decisions can be made and monitored to ensure that IT projects deliver their promised business value.

This subset comprises the decisions made during the architecting and implementation of a solution. If these decisions can be made in a manner driven by the governance criteria, it is far more likely that when they and their consequences are reviewed, they will be found to be consistent with those criteria. This is an example of the principle of “get it right the first time” rather than the repeating cycle of “do something, check it, fix it.”

Enterprise Architecture and Solution Architecture

Solutions are where business/IT alignment mostly occurs, and they form the basis for the actual realization of an enterprise architecture.

It is becoming the conventional wisdom that “EA isn’t just about IT,” that the term “enterprise architecture” should properly be used to mean the architecture of an entire enterprise, not just its IT assets. An enterprise-wide architecture that is implemented primarily in the IT domain is now often referred to as an enterprise IT architecture (EITA) or an enterprise information systems architecture (EISA). While this article is primarily about implementing an EITA or EISA, a solution at a time, its ideas are easily generalized to the enterprise as a whole.

A solution comprises everything necessary to completely solve a business problem. IT solutions are built on shared services provided by software and hardware infrastructure. These shared services facilitate interoperability and when architected from an enterprise-wide perspective address many pervasive attributes (e.g., security, availability, performance, manageability).

Solution Governance

To ensure that an enterprise architecture is implemented as intended, solution architectures must conform to the enterprise architecture, and solution implementations must conform to those solution architectures. The decisions that affect this conformance are the province of solution governance. Ideally, solution governance would be intrinsic rather than extrinsic, i.e., inherent in the development of solutions, rather than confirmed after the fact. How one thinks of architecture can strongly influence whether the way solutions are designed and implemented increases the likelihood of their conformance to solution and enterprise architectures, or requires that this conformance be independently verified.

Model-driven Architecture and Principle-driven Architecture

PRISM (Partnership for Research in Information Systems Management) was a multi-client research service offered by Index Systems and Hammer and Company. In 1986, 50 clients sponsored a PRISM research project on “Dispersion and Interconnection: Approaches to Distributed Systems Architecture.” While the PRISM Final Report on this project (June 1986) remains extraordinarily relevant to the challenge of enterprise architecture, it has largely been forgotten.

The PRISM model of architecture comprised four elements:

• Inventory: “A simple structured listing of architectural elements”; “a snapshot of the current state showing the architectural items in place today and their relationships.”
• Principles: “The organization’s philosophy of information systems and its objectives for technology and its management”; “a statement of the organization’s philosophy of information systems expressed in terms of objectives and goals in each domain area.”
• Models: “Diagrams of the desired architectural state”; “pictures of the desired state, with emphasis on what goes where, and how it is all connected.”
• Standards: Criteria for “selecting and using architectural elements”; “specific rules or guidelines for implementing the models.”

Principles played a central role in the PRISM model:

• “Principles are the most important aspect of architecture and drive all other types.”
• “We have found that principles in all domains have the most far-reaching and significant impact on an organization’s actions, as they form the link between the basic technology values as they are held by the business organization, and technology development and implementation.”
• “Principles are the most stable element of architecture. Thus, they are the key element precisely because, in an atmosphere of change and uncertainty, they represent continuity and relative stability.”
• “Indeed, in many cases (especially when the alternatives are so different from one another as to defy comparison), principles will be the only rational basis for coming to a decision.”
• “Those PRISM sponsors who have started with principles seem to have had greater success than others in completing their architectural activities.”

Despite this, models have become the focus of most architectural thinking. Indeed for many architects, architecture is almost entirely about modeling. Most architectural models are represented using “box and line” diagrams. It is virtually impossible not to think about such representations as structures, and it is unavoidably tempting to extrapolate that what is being modeled is therefore also a structure. This in turn makes it easy to overlook contextual issues that, just as easily as structural faults, can lead to failure.

Thinking of architecture in structural terms is reinforced by analogies with other architectural disciplines, especially the “blueprint” metaphor. This gives models a seductive appeal in that they look like solutions, specifically like the implementation of a solution. Principles and standards don’t; they are largely solution independent. Because of this, models, usually without any context provided by principles and standards, have taken on a disproportionate role in architectural thinking, even though principles and standards constrain models, rather than vice versa.
To understand why architectural governance should be principle-driven rather than model-driven, let’s look at what models are, and why and how we use them.

Models are a special case of analogies; they are stand-ins for the “real thing.” We build models of something because, as simplifications, they allow us to discover or confirm things about that something with considerably less effort (and hence time and cost) than it would take to build that something in its entirety. The simplifications we make in building a model will depend on exactly what we want to learn or confirm.

To put it a bit more formally, we build a model M of something S to take advantage of the extrapolation principle:

If S is [enough] like M, then if X is true of M, X is also true of S.

In developing a good model, we make considerable effort to understand how S is like M and for what Xs the extrapolation principle is valid. The best models consist almost entirely of Xs for which the extrapolation principle is valid. This is impossible to achieve in practice and is the source of the much quoted aphorism:

“Essentially, all models are wrong, but some are useful.” —George E.P. Box, 1987

Bad models (and most analogies) include many Xs for which the extrapolation principle is not valid. The worst models are those where there is no way to tell the “bad” Xs from the “good” Xs. Because the Xs for a model at any given level of abstraction are chosen specifically to be useful at that level of abstraction, models are often not hierarchically decomposable and, thus unlike principles, cannot be hierarchically derived via inheritance, refinement, and decomposition.

The key to implementing an EITA solution by solution is to use architectural principles to shape and constrain models. This approach also makes it possible to grow an EITA incrementally, while maintaining its coherence and business alignment. Deriving solution principles from EA principles provides significant governance leverage.

Principles

So, if we’re going to use principles as the basis for deriving and governing solutions, where do we get our principles from?

Principles come from values and strategies. They express the choices we prefer to make when we have to make decisions. Principles differ from requirements, as they are more fundamental and broadly applicable, though they are similar in concept. See figure 1.

The most difficult challenge in articulating an enterprise’s principles at the multiple levels of abstraction necessary to implement principle-driven solution development and governance is to express principles that are not meaningless generalities. The most effective way to do so is to ask whether the opposite of a principle would also be a meaningful principle. If no one would ever adopt the opposite of your principle as a principle for their enterprise, you are not expressing a preference, you are expressing a given.

Why, What and How

A particularly effective way of deriving principles from drivers, goals, and higher level principles is to use the relationship triple of (why, what, how). In this context, why, what, and how are relative roles or relationships, unlike the six interrogatives of the Zachman Framework, where they are absolutes.

When dealing with principles, the what to a why, or the how to a what, are often referred to as implications. It is important to understand that implication here is used in the sense of a predicate, what must be the case for something to be true, rather than as a consequence, what will happen if something is true. Similarly, the why of a what, or the what of a how, are often referred to as rationales.

The only case where an implication has the meaning of a consequence is in the relationship between drivers and goals. Drivers are givens that you can only react to; they are not something you choose, you can’t make them be the case, as they are already the case.

Successively applying these roles makes it possible to derive a series of principles rooted in enterprise-level goals and drivers that provides a continuous chain of motivation and justification down to the level of implementation artifacts, without requiring any leaps of faith along the way.

Architectural Principles and Governance

Given such a continuous chain of motivation and justification connecting decisions at the level of solution implementation to the level of enterprise strategy, it becomes possible to ensure that these decisions are made correctly and that this can be demonstrated to be so. This is an extremely powerful capability that is difficult to achieve by focusing on models as the basis for architecture at the enterprise and solution levels.

Source: https://architectureandgovernance.com/content/architectural-governance-principles