Architecture By Implication

AntiPattern Name: Architecture By Implication

[TODO: make this conform better to the AntiPatternTemplate]

[This seems strangely like it was just copied from somewhere. Is that so?]

[I think so. It seems like an excerpt from the AntiPatternsBook. Try googling a long enough excerpt from the text below. ]

This AntiPattern is characterized by the lack of architecture specifications for a system under development. Usually, the architects responsible for the project are experienced with previous system construction, and assume that documentation is unnecessary due to their competence and experience. This overconfidence leads to exacerbated risks in key areas affecting system success. Missing architecture definitions occur in one or more of these areas:

Symptoms and Consequences:

Typical Causes:

Refactored Solution:

The refactored solution entails an organized approach to systems architecture definition. The approach relies on multiple views of the system. Each view models the system from the perspective (viewpoint) of a system stakeholder. The stakeholders may be real or imaginary, individual or aggregate. Each stakeholder is responsible for a high priority set of questions and issues. Each view represents the whole information system and answers these key questions and issues. The views are linked for consistency. A view comprises a set of diagrams, tables, or specifications. Generally a view is a lightweight specification. The purpose of the architecture documentation is to communicate architecture decisions and other issue resolution. The documentation should be easily understandability and inexpensive to maintain.

The steps involved in defining a system architecture using viewpoints are as follows: [Hilliard 96]

Define the architecture goals
What must this architecture achieve? Which stakeholders, real and imaginary, must be satisfied with the design and implementation? What is the vision for the system? Where are we now and where are we going?

Define the questions
What are the specific questions that must be addressed to satisfy the stakeholder issues? Prioritize the questions to support view selection.

Select the views
Each view will represent a blueprint of the system architecture.

Analyze each view
Detail the architecture definition from each viewpoint. Create the system blueprints.

Integrate the blueprints
Verify that the views present a consistent architecture definition.

Trace views to needs
The views should address the known questions and issues. Discover any gaps not addressed by the architecture specifications. Validate the architecture with respect to formal requirements. Prioritize the outstanding issues.

Iterate the blueprints
Refine the views until all questions, issues, and gaps are resolved. Utilize review processes to surface any remaining issues. If there are a significant number of unresolved issues, consider creating additional views.

Evangelize the architecture
Make an explicit effort to communicate the architecture to key stakeholders, particularly the system developers. Create lasting documents (such as a video tutorial) that will provide valuable information throughout the development and maintenance lifecycle.

Validate the implementation
The blueprints should represent as-built design. Determine any deltas between the blueprints and the system implementation. Decide if these differences should result in system modifications of updates to the blueprints. Upgrade the documentation for consistency.

One can refer to this method as the Goal-Question-Architecture (GQA), analogous to the Goal-Question-Metric approach to software metrics. [Kitchham 96]

Variations:

A number of approaches consider the system architecture using viewpoints. Some viewpoints are pre-defined. Most of these approaches are open-ended, in that one can select additional viewpoints as shown above.

The Reference Model for Open Distributed Process (RM-ODP) is a widely utilized standard for distributed architectures. RM-ODP defines 5 standard viewpoints: enterprise, information, computational, engineering, and technology. [ISO 96] A useful set of transparency properties are defined for distributed infrastructure through the engineering viewpoint. The RM-ODP is open-ended, in that, additional viewpoints can be incorporated in the framework.

The Zachman Framework analyzes system architectures from the perspectives of data, function, and network. [Spewak 92] Within each perspective, there are multiple levels of abstraction, corresponding to the planning needs of various groups of stakeholders. Enterprise Architecture Planning, is an approach based upon the Zachman Framework for large scale systems. [Spewak 92] These approaches are not tailored to object-oriented systems development.

The Command, Communication, Control, Computer, Intelligence, Surveillance, and Reconnaissance Architecture Framework (C4ISR-AF) is used to define various command and control system architectures. A version of C4ISR-AF is used for other types of civilian systems. Use of C4ISR-AF has been very beneficial in enabling communications between architects across disparate domains. [Mowbray 97b]

The 4+1 Model View is a viewpoint-based architecture approached supported by software engineering tools, such as Rational Rose. [Kruchen 95] The viewpoints include: logical, use-case, process, implementation, and deployment. GQA is a generalization of the underlying method used in several of these architecture approaches. [Hilliard 96].

Example

A common bad practice is object-oriented modeling without defining the viewpoint. In most modeling approaches, there is a blurring of distinction between the viewpoints. Much of the modeling constructs contain implementation detail, and the default practice is to intermingle implementation and specification constructs.

Three fundamental viewpoints are: Conceptual, Specification, and Implementation. [Cook 1994] The conceptual viewpoint defines the system from the perspective of the user. This is what is typically referred to as an analysis model. The distinction between what is automated and what is not is usually not represented in the model. The model is drawn so that a user can explain and defend it to her peers. The specification viewpoint concerns only interfaces. ISO IDL is one important notation that is strictly limited to defining interface information and excluding implementation specifics. The separation of interfaces from implementations enables the realization of many important object technology benefits, such as: reuse, system extension, variation, substitutability, polymorphism, and distributed object computing. The final viewpoint is implementation, and is best represented by the source code. Complex implementation structures are usefully augmented with object-oriented design models to help current and future developers and maintainers to understand the code.

Related Solutions

The StovepipeAntiPattern differs from this one in scope; it focuses on deficiencies in computational architecture. In particular, it identifies how improper abstraction of subsystem APIs lead to brittle architecture solutions. In contrast, this AntiPattern (Architecture by Implication) involves planning gaps involving multiple architecture viewpoints.

The variations section identifies several related approaches and specializations of this solution: RM-ODP, 4+1 Model View, and C4ISR-AF.

Applicability to Other Viewpoints and Scales

The impact of this AntiPattern on managers is a significant increase in risk. Architecture by Implication defers important decisions until failures occur and it is often too late to recover.

The impact of this AntiPattern on developers is the lack of guidance for system implementation. The developers are given de facto responsibility for key architectural decisions which they may not have the architectural perspective to make. System-wide consequences of interface design decisions should be considered, in particular: system adaptability, consistent interface abstractions, metadata availability, and management of complexity. Another important impact is the deferment of resource allocation. The appropriate tools and technology components that may be essential are not available when needed due to lack of planning.

Background

Dwight Eisenhower said that planning is essential, but plans are inconsequential. Another soldier said that no plans survive first contact with the enemy. The planning culture in modern management owes some credit to Robert McNamara?, founder of the RAND Corporation. In McNamaras? approach, plans are generated for speculative purposes, to investigate the potential benefits and consequences of different courses of action. Given the large number of unknowns in systems development, planning for IT systems must be more pragmatic and iterative.

We once ran across a professional planner who said that 20% of engineers time should be devoted to planning. As we gain experience, our belief in this assertion increases. Productivity and efficiency can be greatly increased if the work is well organized through planning. The unfortunate consequence is that many organizations attempt to formalize too much of the planning. Planning is most effective when it is personally motivated and utilized. Time management experts teach that a key element of stress reduction is planning to balance lifes overall priorities. The form and use of time management systemsbecomes increasingly personalized as the practice matures.

A group of CEOs were formed to answer the question: Where art thou architecture? reflecting the changing nature of systems development integration. The systems integration business has evolved into the reuse of existing legacy components and commercial software, and away from greenfield, custom code development (See Reinvent The Wheel AntiPattern).

Also Known As: Where art thou architecture?, Plans are Inconsequential

Most Frequent Scale: System

Refactored Solution Name: Goal Question Architecture

Refactored Solution Type: Documentation

Root Causes: Pride, Sloth

Unbalanced Forces: Management of Complexity, Change, Risk

Anecdotal Evidence:

We've done systems like this before!

There is no risk, we know what we are doing!

Sources (in order of reference):

CategoryArchitectureAntiPattern

EditText of this page (last edited August 14, 2010) or FindPage with title or text search