Essays on Software Architecture

1. Architecture Team Organization - Soviet Style - David Emery, The MITRE Corporation
2. What’s the Difference Between Architecture and Design? - Paul Clements, Software Engineering
Institute
3. Are you a Software Architect yet? - Sathyanarayana Panduranga
4. Architecture Paradox - Dr. Subrahmanyam Allamaraju
5. Software Architecture for Product Families - M. Jazayeri, A. Ran, and F. van der Linden
6. Multi-Paradigm Design for C++ - James O. Coplien
7. James Madison and the Role of the Architect - Dana Bredemeyer, Bredemeyer Consulting
8. The Tao of the Software Architect - Lao-Tsu, revisited by Philippe Kruchten, Rational Software
Canada
9. Characteristics of an Organization with Mature Architecture Practices - Joe Batman, Software
Engineering Institute
10. Lesson Learned About Architecture: Unstructured and Eclectic - Clayton Sprung, Consulting Analyst
BCTEL
11. Origins of Software Architecture Study - Paul Clements, Software Engineering Institute

We welcome short essays about software architecture. If you have one that you would like to post,
send it in.

Architecture Team Organization - Soviet Style

by David Emery

From my observation, one key characteristic of effective software architecture groups is they follow a
"Soviet" organizational model. There must be broad representation by the stakeholder constituencies, but the
actual work is done by a much smaller group. More importantly, the architecture itself is produced and led by
the chief/lead architect, guiding a select group of advisors. So software architecture may be a group activity,
but it is one that depends on the leadership skills of the architect, to develop comprehensive solutions and
lead consensus-building around the chief architect's direction. The effective chief architect must be willing to
impose his will on both his small group of advisors and on the larger constituencies, preferably through
consensus-building, but by fiat and direction when necessary, overruling all of his advisors on occasion. His
inner circle must be willing to debate issues, but when the decision is made, they must support the decision
(or leave the project).

In other words, we have:

 Party Congress - Large group that ratifies decisions presented to them

 Poliburo - Representative group that actually debates and makes the decisions that the Congress
ratifies
 Central Committee - Select small group that writes the decisions for the Politburo to debate
 General Chairman - Person who tells the Central Committee what to write

The bottom line is that effective architecture is not done by committee, but should look that way :-)

What’s the Difference Between Architecture and Design?

by Paul Clements (based on "Documenting Software Architectures: Views and Beyond"

The question of how architecture is different from design has nipped at the heels of the architecture
community for years.

Fortunately, the answer is easy. Architecture is design, but not all design is architecture. That is, many
design decisions are left unbound by the architecture and are happily left to the discretion and good
judgment of downstream designers and implementers. The architecture establishes constraints on
downstream activities, and those activities must produce artifacts—finer-grained designs and code—that are
compliant with the architecture, but architecture does not define an implementation.
You may ask, “What decisions are nonarchitectural? That is, what decisions does the architecture leave
unbound and at the discretion of others?” To answer this question, we return to our preferred definition of
software architecture (from Software Architecture in Practice, 2nd edition): “...the structure or structures of
the system, each of which comprises elements, the externally visible properties of those elements, and the
relationships among them.” Thus, if a property of an architectural element is not visible, or discernible, to any
other architectural element, that element is not architectural. The selection of a data structure, along with the
algorithms to manage and access that data structure, is a typical example. Suppose that the architectural
prescription for the data structure is that it provides programs, invoked from other architectural elements, that
store and retrieve data; whether we choose a linked list, an array, a stack, or any other solution is therefore
immaterial to those other elements, as long as our choice lets us meet the developmental, behavioral, and
quality requirements levied on us.

“But wait,” you protest. “You used the term architectural element: What’s that? Are there nonarchitectural
elements? If so, what’s the difference?”

There may be nonarchitectural elements; their existence is unknown except to those who are outside an
architectural context. For instance, a module may correspond to a work assignment for a development team;
a module created under the doctrine of information hiding encapsulates a changeable aspect about the
system. Modules are hierarchical entities; that is, a complex module, such as a work assignment, can be
decomposed into smaller modules: smaller work assignments. Each module has an interface and an
implementation. The interface to the parent is a subset of the union of the interfaces of the children.

Suppose that you’re in charge of implementing module M and that, as far as the architect has stipulated, M
has no submodules. Perhaps you discover that M’s interface routines could all be implemented quite
straightforwardly if you also designed and implemented a common set of services that they could all use.
You assign a small subteam to design and implement this—this—this what? Well, it’s a work assignment,
and it encapsulates a changeable secret—namely, the algorithms and data structures used by the common
services—so that makes it a module, a submodule of M. Let’s call it M2.

“I get it,” you say. “Because its existence is not known outside of M, M2 is not an architectural module.”

It’s tempting to agree at this point and be done with this, but that’s not quite the right way to look at things. In
some layered architectures, the layers at the top are not allowed to use the layers at the bottom; in essence,
the bottom layers’ services are not known to the top layers. But we would never say that the bottom layers of
an architecture are nonarchitectural. The argument about “unknown outside of” appeals to a relation different
from the one present in a module structure. Modules are related to one another by the contains relation, or
shares a secret with relation. Whether a module’s services are known or unknown by another module is a
property of the uses relation, which is a different kind of animal.

“OK,” you say. “So is module M2 an architectural element or not?”

I would say not, but not because it’s “invisible” to the other modules outside its parent. I’m afraid you’re not
going to like the reason. It’s a nonarchitectural element because the architect said so—that is, he or she
didn’t make it part of the architecture.

“You’re joking,” you say. “That’s a completely arbitrary definition!”

Not really. The reason the architect didn't make it part of the architecture is that its existence or nonexistence
was not material to the overall goals of the architecture. The architect gave you the freedom to structure your
team—implementing M—as you saw fit.

The fact is, no scale or scope or measure or line divides what is architectural and what is not. One person’s
architecture may be another person’s implementation and vice versa. Suppose that M2 turns out to be very
complicated and that the subteam you assign to it begins by giving M2 an internal structure. To the coders of
M2, that structure is an architecture. But to the architecture of the system that includes M, the very existence
of M2, let alone its internal structure, is an implementation detail.

Processes and similar elements can also be nonarchitectural. Suppose that the architect gave you a budget
and the freedom to create up to 12 tasks and that these tasks do not synchronize or interact with any other
tasks outside your work assignment. In that case, we could make the same argument: that these tasks, or
elements, are nonarchitectural.

“All right,” you sigh. “Once more, with clarity?”

Sure. Architecture is design, but not all design is architectural. The architect draws the boundary between
architectural and nonarchitectural design by making those decisions that need to be bound in order for the
system to meet its development, behavioral, and quality goals. (Decreeing what the modules are achieves
modifiability, for example.) All other decisions can be left to downstream designers and implementers.
Decisions are architectural or not, according to context. If structure is important to achieve your system’s
goals, that structure is architectural. But designers of elements, or subsystems, that you assign may have to
introduce structure of their own to meet their goals, in which case such structures are architectural: to them
but not to you.

Architecture is truly in the eye of the beholder, which has implications about its documentation. If your goals
are met by an architecture, document it as such, but expect the possibility that subsequent, finer-grained
design may produce architectural documentation—about a small piece of your system—on its own.

Are you a Software Architect yet?

Contributed by Sathyanarayana Panduranga

Software Design Engineer, Hewlett Packard India, Bangalore, India

Software architecture is the blueprint of a software system. It provides an overview of the composition and
functionality of the given software system. Just like a structural architect, a software architect needs to
analyze the requirements, determine components that should be used to build the system, and support the
project by guiding and solving problems all along the execution cycle. Architecting software is like planning
for war. Past experiences are very useful here. Strategizing gives you an edge. Understanding of the domain
provides you with capability to analyze the requirements and envisioning a solution. Exposure to various
tools and technologies imparts in you the ability to choose among the various solutions available, and
anticipate and solve technical problems.

A person becomes a software architect when she has gained enough breadth and depth in the relevant
domain and technologies, and has the capability to envision a software system before it is developed.

Architects are needed for most of the Software Projects, more as the navigator for a sailing ship. Architects
design the software system, guide the development team in implementing the system, and
anticipate/diagnose problems, find/develop solutions to those problems. These days, most of the
organizations are realizing the importance of software architects, because with an architect you are no longer
shooting in the dark.

Architects need to have good written/spoken communication since they have to convince the people above
and bellow them in the hierarchies about their ideas effectively, strong development and debugging skills,
cross domain and technology proficiency and appreciation, and customer’s point of view can be very useful
for an architect.

Due to the maturity of Software Development practice, there are several predefined solutions available for
certain problems called Patterns. Design and Architecture patterns are a vogue in the Software Development
industry. They are the solutions for a recurring class of problems. Most of the time, they are the best possible
solutions to those problems. Knowledge of patterns in her domain/technology areas is an added advantage
for an architect.

For a person, who is excited by new tools, technologies and domains, who is on the lookout for challenging
problems to solve, who is capable of thought leadership, who equates her success to that of the customer’s,
the role of Software Architect is a natural progression.
Architecture Paradox

Dr. Subrahmanyam Allamaraju

Introduction

A 1996 technical report [1] from the Software Engineering Institute, in its introduction points out that software
architecture is still a relatively immature area from both research and practice perspectives. The same holds
true in 1999 after maturity and emergence of several generic as well as domain-specific architectures.
Today, the area is largely immature not because of lack of research, but lack of its practice. But why is it
difficult to practice software architecture?

In commercial software industry, where products and applications are required to be built over very short
time-frames with tight budgets, the term "architecture," though widely used, is rarely practiced as a concept
or as an integral part of software building. Ironically, it is this specific industry segment that requires more
emphasis on software architecture for at least two reasons: budgetary constraints, and shorter time to
deployment. Both these factors demand protection of investments in information technology. Protection of
investments requires protection of software architecture against changing requirements. In a nutshell, this is
the focus of this article.

While architecture is generally perceived to be crucial for any software development exercise, in practice,
architectures are rarely part of software development life-cycles, when so, rarely complete, and when
complete, rarely protected and adhered to. This is one of the reasons why changes to software are
expensive. Despite this, architectures are sought by concerned parties in almost all software development
projects.

The purpose of this article is to discuss "Architecture Paradox" and bring out the conflicting forces that
influence the architecture over the life-time of software products and applications. This paper also presents
some early ideas on how to build software systems that defy the architecture paradox. Note that this paper
does not attempt to prescribe a process for building software architecture, but indicates the activities the
architect must undertake in designing an architecture, and the rationale behind these.

What is Software Architecture?

This article does not attempt to define or redefine architecture as applicable to software. The focus of this
article is, instead, on the purpose and role of architecture during the software life cycle and beyond, to
identify the factors that affect the architecture, and to finally discuss how to address the conflict between
these factors. Readers interested in what software architecture is, should refer to [1] and [2].

For the purpose of the present discussion, the following definition and explanation (both from [1]) are
relevant.

Architecture: Structure of the components of a program/system, their interrelationships, and principles and
guidelines governing their design and evolution over time.

Software architecture usually refers to some combination of structural views of a system, with each view a
legitimate abstraction of the system with respect to certain criteria, that facilitates a particular type of planning
or usage.

From the above, note the following.

 Software architecture represents the structure of the software. This includes the structural
arrangements of software components, and various static and dynamic interrelationships between
these components.
 Software architecture is expressed using certain views, each of which serves a specific purpose.
Each view is a specific abstraction of the architecture, for a specific purpose.
 Software architecture includes the principles behind design and evolution of the software.

The following are some of the essential characteristics of architecture.

  Software architecture should represent a high-level view of the system revealing the structure, but
hiding all implementation details. Specifically, it should reveal attributes such as responsibilities (of
the constituents of the architecture), distribution, and deployment.
 Architecture should realize all the use case scenarios. While the use case model serves to record
the functional requirements as seen by various actors, the architecture should enable the stake
holders of the software to walk through the scenarios of each use case. This guarantees that the
structure as represented by the architecture meets the functional requirements.
 It should present other systemic views to all the stake holders of the software. Examples are - a
component view for the development team, a network-centric deployment view for the network and
hardware team, and a distribution-centric deployment view for the installation team etc.

However, how does an architecture look like? Some of the common representations of software architecture
are as follows. As discussed below, none of these representations are complete.

 High-level design: A simplistic approach is to represent the architecture as a concise view of a

high-level design of the software. However, design is an implementor's view of the software - a view
that reveals how to arrive at the structure of the software. So a high-level design does not
necessarily represent the architecture of the software.
 Deployment: This is the most common form of representations of architecture. In this view, the
software is described in terms of how it is deployed across various platforms, and how these parts
communicate with each other. Note that deployment view is only one of the possible views of
architecture, and does not necessarily reveal the structure of the software. Also note that during the
life-cycle of a software, the deployment could change with no or minimal changes to the structure of
the software. This is one of the reasons that is driving distributed component based technologies.
 Generic Technology Architectures: In this form, software architecture is represented as a two-tier,
three-tier or a multi-tier system. Note that architectures such as these, distributed (and layered)
architectures such as COM or CORBA, or component based architectures such as MTS or EJB are
generic and do not address the needs of the domain in which the software is to operate and evolve.
However, these technology architectures provide the basis for developing domain specific
application architectures.

As described in [1] and [2], an architecture should at least present the following views of the software (in the
order of the importance).

 Logical or Conceptual View: This view of the software represents various abstractions of the
system and accounts for various use case scenarios. Using this view, one should be able to walk
through these abstractions to realize the use case scenarios. In the case of distributed applications,
some of these abstractions may directly map to distributed components.
 Deployment View: As pointed earlier, this view depicts how various parts of the software are
deployed.

In both the views, it is necessary to depict responsibilities of each of the parts of the architecture, static
and/or dynamic dependencies between them, the nature of communication between the parts, etc. Additional
views such as development views (to show how the application will be developed) and process views (to
reveal threading, concurrency etc.) may also be considered if required.

In general, software architecture is considered ([1], [2]) important as it serves as a means of mutual
communication between the stake holders of the software, allows to capture early design decisions, and lets
the architecture be reused for similar systems in the same domain.

However, these are only consequences of an architecture design. The fundamental requirement for software
architecture is to design a structure for the software considering long-term consequences. As discussed by
Bennett [3], software is considered to be inntrinsically complex because of the fine granularity of
programming language constructs (objects, classes, methods etc). Bennet points out that this makes the
structure "soft." It is during the architecture design phase, that an architect can "harden" the structure of the
software, before implementing the architecture with "soft" language constructs. However, before approaching
the architecture design problem, it is necessary to consider the conflicts that a typical software faces.

Architecture Paradox
To be successful, a software must face two challenges: survival and evolution. These two are conflicting
challenges. A software survives as long as it serves the requirements for which it was built. However, in a
user-world where requirements, operational constraints and technology continue to change, survivability,
though necessary, is not sufficient. The software, in addition, should be evolutionary. A software evolves as
long as it can be adopted to meet changing demands. However, in an attempt to evolve, the software can not
afford to lose its survivability. Both these challenges tend to affect the architecture in opposing directions,
leading to the "architecture paradox."

Figure 1: Architecture Paradox: Survival vs Evolution

Note that, a software's ability to survive and evolve (without loss of the other) depends on its structure as
represented by its architecture.

To explain this architecture paradox, consider a software that meets its current requirements. Such a system
is characterized by an architecture that realizes all use case scenarios and meets other requirements (such
as performance, scalability etc). As requirements and other influencing factors change, the software begins
to lose its survivability, as it can not yet meet the changed conditions. To bring back survivability, the
software should be evolved to meet the changes. However, as Brooks [4] points out, changes made to a
software may increase its entropy. This manifests in increased complexity, as seen by one or more of the
following:

 Increased number of interdependencies between the parts of the software.

 Violation of structure (layers, tiers etc.).
 Violation of design goals.

Despite the above, the software may still be able to meet its changed requirements. However, due to the
increased entropy, further changes to the software trigger a positive feedback mechanism, and increase the
entropy further. Ultimately, the architecture of the software breaks down and further changes become almost
impossible. The software loses its survivability.

Thus, in an attempt to evolve, the software may lose its survivability as shown in Figure 1. This is the
architecture paradox.

An architecture can last longer only if it can defy the architecture paradox. But how to design such an
architecture? What is the role of the architect in doing so? The rest of this paper addresses these questions.

A Solution?

For any system to adopt to changing functions and evolve, its growth (i.e., changes) should be dictated by
certain principles (or values). These principles are not generic, but are meant to meet certain goals. The
system should represent and protect the principles that it is built for.

In the case of software, the principles dictate the design and development. The role of the architect is to
identify the goals, devise the principles, and build the architecture according to these principles. These
principles should be encapsulated in the architecture such that the architecture dictates certain design and
development constraints while leaving scope for changes that follow the principles.

Accordingly, this paper suggests a three-stage approach to design architectures that defy the software
paradox. These are - to identify the of goals of the architecture, to discover the principles based on the goals,
and to design an architecture integrating these principles. The capability of the system to survive and evolve
increases as the focus tends to reach the third stage.

The approach suggested in this paper is based on the presumptions that

 it is possible to anticipate changes to software, and

 it is possible to build software architectures and designs that are resilient to change.

The motivation behind these presumptions is based on the following:

 Most of the application domains are mature enough to predict changes.

 Even in cases where the domains are turbulent, certain technologies and design patters based on
components, and reflection make architectures resilient.

For a discussion on change resilience patterns in software architecture and design, refer to [5].

The following sections discuss the three phases in detail.

Identify the Goals of Architecture

The fundamental goal of the architecture of a software is to realize all its use cases. It should facilitate all use
case scenarios to be implemented in the software. However, this is just one of the contributing factors to
architecture, and does not help in building resilient architectures. Consider the following:

 It is not uncommon to find more than one possible implementations of a use case.
 Not all implementations may have the same impact on the structure of the software.
 This goal does not take into the consideration the anticipated needs or constraints of the software.

Therefore, the first phase in designing an architecture is to formulate a set of goals that the architecture
should meet in order to satisfy the structural requirements of the software.

Note that the goals of the architecture are not the same as the requirements of the software. While the
software requirements focus on the external view of the software, the goals of the architecture capture the
long-term requirements of the structure of the software. The goals of the architecture should be such that as
long as the architecture meets these goals, the software is more likely to evolve and survive changes during
its lifetime.

During this phase, the architect should identify the factors that are likely to affect the structure of the
software. These factors include best-case requirements, long-term organizational focus, reuse
considerations, technology preferences and evolutions, user wish-lists, and other anticipated changes. The
architect should elicit these factors from the various stake holders of the software. Based on these, the
architect should formulate a set of goals that the structure of the software should meet.

Note that the rationale behind this step is to predict and account for the evolutionary changes that are
expected of the software. Although these goals do not directly influence the use cases of the software, these
allow the architect to design an architecture that is more likely to absorb changes without losing the structure.

From Goals to Principles

The second step is to discover the principles that the software architecture should follow in order to meet the
above goals. These principles are meant to dictate the design and development process of the software
during its lifetime.

As pointed out earlier, it is common to find that a use case may be implemented in more than one ways. As
Booch [6] has observed, one of the reasons for inherent complexity of software is the flexibility possible
through such implementations. Not all possible implementations of a use case may cause or affect the
structure of the software in the same way. While some implementations may alter or break the structure of
the software, the others may not. The principles of architecture should guide the designers and developers to
find the right implementation of a use case.
The architecture principles may be expressed as certain rules, DOs and DONTs, and guidelines that the
designers and developers should adhere to. Note that, the process of enforcing these principles is generally
more difficult than discovering the principles. This process requires constant mentoring and policing. This is
because of the human/organizational involvement in enforcing these principles. Any changes to the team
composition may violate these principles as the team may not realize the philosophy and long-term benefits
of these principles.

Integration of Principles and Architecture

The last and the most crucial step is to integrate the architecture principles into the architecture. The purpose
of this phase is to remove the necessity of human factor in ensuring that the implemented software follows
the architecture principles. With the integration of architecture principles with the architecture, the structure of
the software dictates how the software should be changed, what kind of changes are possible, and what kind
of changes are not.

This process typically manifests into certain constraints and certain facilities or services in the architecture.
The constraints control changes that are detrimental to the structure, while the facilities or services provide
for extensions.

But, is it possible to integrate the principles with the architecture? The answer is YES. A architecture
integrated with these principle typically uses multiple layers of abstractions, indirections, reflection etc. The
amount of integration that can be achieved also depends on the chosen programming languages, and the
underlying technology.

Role of the Architect

This section summarizes the activities that the architect should carry out to architectures that defy the
architecture paradox. The following are the activities

1. Based on an analysis of the given requirements, draw the initial architecture.

2. Identify the goals of the architecture.
3. Discover architecture principles that let the architecture meet the above goals.
4. Refine the architecture integrating the above principles.
5. Re-evaluate the architecture for implementing the use cases, and other requirements such as
performance, scalability etc. Check if the constraints posed by the integrated architecture affect any
of the requirements, and refine the architecture accordingly.

Note that this is a creative exercise, and can not be mandated or driven by a process.

Conclusion

This article poses two questions:

 Why should software architectures be protected?

 Why is it difficult to protect software architectures?

It is necessary to protect software architectures, because it is necessary to protect investments in software.

This can be achieved only if the structure of software is resilient to changes, and costs of changes to
software are low. Interested readers may also look into Big Ball of Mud, a very revealing article by Brian
Foote and Joseph Yoder [7] for a list of common patterns software developers follow to create software
systems that are difficult to be changed.

The answer to the second question lies in the conflicts (survival and evolution) that a typical software system
is exposed to. This paper terms this as architecture paradox.

How to build resilient architectures that are not trapped in the architecture paradox? The answer may be
summarized in four points:

1. A software system can defy the architecture paradox, only if the structure of the software can
accommodate changes.
 2. Since anticipated changes are not to be implemented in the software right away, it is necessary to
abstract these as a set of architecture goals.
3. To realize these goals, it is necessary to devise a set of principles.
4. To remove the human factor in enforcing these principles, integrate the principles into the
architecture, such that the architecture poses the necessary constraints to protect itself.

It is necessary to reemphasize that this is a creative activity and can not be driven by any process. Added to
this, the benefits of this exercise may not be immediate.

References

1. Paul Clements and Linda M. Northrop (1996): Software Architecture: An Executive Overview,
Software Engineering Institute, Carnegie Mellon University, Technical Report CMU/SEI-96-TR-003.
2. Len Bass, Paul Clements and Rick Kaxman (1998): Software Architecture in Practice, Addison-
Wesley, Reading, Massachusetts.
3. Douglas W. Bennet (1996): Hard Software: The Essential Tasks, Manning Publications Co,
Greenwich, Connecticut.
4. Brooks F. (1995): The Mythical Man-Month - Essays on Software Engineering (20th Anniversary
Edition), Addison-Wesley, Reading, Massachusetts.
5. Jim Doble (1997): Change Resilience Patterns in Software Architecture and Design, OOPSLA '97
Workshop on Exploring Large System Issues.
6. Grady Booch (1994): Object Oriented Analysis and Design with Applications (2nd Edition), Addison-
Wesley, Reading, Massachusetts.
7. Brian Foote and Joseph Yoder (1997): Big Ball of Mud, Fourth Conference on Pattern Languages of
Programs (PLoP '97/EuroPLoP '97), Monticello, Illinois, http://laputan.org/mud/mud.html.

© Subrahmanyam Allamaraju 1998-2002. All rights reserved.

This document is protected by copyright. No part of this document may be reproduced in any form without
prior written permission from the author. This document is for electronic distribution only and should not be
stored in electronic forms without prior written permission from the author.

All copyrights and trademarks acknowledged.

Software Architecture for Product Families

Excerpts from chapter one taken from the book "Software Architecture for Product Families" by M. Jazayeri,
A. Ran, and F. van der Linden. © 2000 Addison Wesley Longman Inc.
Reprinted by permission of Addison Wesley Longman.

In recent years, many important contributions have been made to the study of software architecture. The
seminal paper by Perry and Wolf (1992) laid the foundation for the study of the subject. The book by Shaw
and Garlan (1996) gives a broad perspective on research contributions aiming at solving difficult problems
faced by software architects. The book by Bass, Clements, and Kazman (1998) offers in-depth coverage of
software architecture in practice, demonstrating how system-level problems are addressed by experienced
software architects working on real projects. Finally, Boehm's work (Boehm et al. 1999) puts architecture in
the perspective of the organizations involved in procurement, development, deployment, and use of
software, thereby making the architecture correspond to business goals and leading to a win-win situation for
all stakeholders.

Here we are concerned primarily with the technical aspects of software architecture unified in a consistent
conceptual framework. Probably the first work that addressed this goal specifically was "The 4+1 View Model
of Architecture" by Philippe Kruchten (1995) of Rational. This work was in informal circulation from the early
1990s and eventually was published by IEEE Software in 1995.

The 4+1 View model offered a simple and understandable way to think about software architecture of
complex systems, by organizing descriptions of software related to different concerns in five categories,
called views. The four main views are
 1. The logical view, which is the object model of the design (when an object-oriented design method is
used)
2. The process view, which captures the concurrency and synchronization aspects of the design
3. The physical view, which describes the mappings of the software onto the hardware and reflects its
distribution aspect
4. The development view, which describes the static organization of the software in its development
environment

Descriptions of software in these four views are illustrated and validated with an additional view that contains
selected use cases and scenarios. Each view shows a specific aspect of the modeled system. Until now this
has been perhaps the most influential approach in terms of popularity in industry. Naturally, the ARES
conceptual framework follows the 4+1 View model in many ways.

Soni, Nord, and Hofmeister (1995) took the subject one step further. After studying a considerable number of
software-intensive systems built by Siemens, they identified four different architectural views used by
designers to describe the software:

1. Conceptual architecture. Major design elements and their relationships

2. Module interconnection architecture. Functional decomposition, interfaces, and layers
3. Execution architecture. The dynamic structure of the system
4. Code architecture. Organization of source code, libraries, and binaries

This work confirmed the need for multiple descriptions of software done from different perspectives and
demonstrated that the specific perspectives may be different from the set included in the "4+1" views. In
addition, Soni, Nord, and Hofmeister called their views architectures, which may be interpreted as a
statement that these are, at least partly, independent models rather than different views on the same thing.
The paper, however, does not suggest this interpretation. It analyzes relationships among these views,
identifies the concerns addressed by each view, and discusses characteristics of development and delivery
environments that influence the designs of the different views. Another important contribution of this work is
in identifying the need to partition the architecture of software into infrastructure (technical architecture) and
application (business architecture)…

Software Architecture: A Tool for Dealing with Complexity

Before exploring the main concepts of software architecture, we wish to state our understanding regarding
the primary need for software architecture-the main reason for its existence-including when it is reasonable
and necessary to address the architecture of software and when we need to consider only software design, if
anything at all.

The general interest in architecture emerged when software built by companies crossed a certain threshold
of complexity. This happened across industries sometime between the mid-1970s and mid-1980s. The
general situation could be characterized as a loss of intellectual control over the software being developed in
industry.

This loss of intellectual control could be recognized from multiple symptoms. A common symptom was
monotonic growth of software almost unrelated to added functionality, usually as a result of fear to touch the
existing code. Engineers were not sure anymore what any particular part of software was doing-that is,
where and how it was used. Any request for change in functionality could be addressed only by adding more
code. A very typical symptom of lost intellectual control was integration failure. Multiple poorly understood
relationships between different components made integration a never-ending process. Correcting one
observed problem inevitably led to the introduction of several new ones. Another common symptom was
performance barriers that could not be significantly affected by the use of faster hardware. More precisely,
nobody seemed to know which hardware component needed to be faster to improve system performance.
One of the most painful symptoms was uncontrollable diversification of software created for different
customers or markets. Even though products differed only in small parts of their functionality, there was often
a wholly separate version and configuration for each market or customer.

Not everybody, however, lost the intellectual control over software development. Projects and products that
retained intellectual control over their software employed a different level of understanding the software-an
understanding that could be called architectural. Therefore, study of what software architecture is promised
to help software developers regain intellectual control over the development of complex software.
We understand software architecture as a conceptual tool for dealing with the complexity of software. There
are several essential sources of software complexity:

 Open-endedness, imprecise specification. It seems impossible in practice to precisely specify the

function of software before the software is built.
 Indirectness, intangibility. We don't directly construct the performing system itself. We create
source code that will go through a variable sequence of nontrivial transformations to produce the
executing system.
 Concurrency of execution. Generally we understand space and spatial relationships better than we
understand time and temporal relationships. In addition, programming technology is very much
geared toward the step-by-step definition of processes. Many systems built in industry, however,
have multiple processors and multiple concurrent threads of execution.
 Concurrency of construction. Another aspect of concurrency is concurrent engineering: We
cannot build software sequentially piece by piece; rather, large teams have to build different
interdependent pieces concurrently.
 Diversification. In industry, we rarely build one-of-a-kind systems. Usually we build product families
or product lines in which each product has different features that need to be provided by a single
implementation with a minimal amount of configuration, customization, and rework.
 Size. When numbers of design elements such as functions and classes are measured in hundreds
of thousands, a different representation of software is required.

Proper architecture of software should reduce the complexity that results from at least one of these factors…

Conceptual Framework for Software Architecture

A conceptual framework for software architecture (CFSA) is the foundation on which software architects
base their design decisions. For an organization to be able to influence and/or assess design decisions
made by software architects, the CFSA needs to be explicitly defined and actively managed… The following
concepts underlie the ARES CFSA.

Scope

In most circumstances an architecture is intended for more than one instance of a system. Characterization
of the class of systems for which the architecture is applicable defines its architectural scope. There is
usually a hierarchy of scopes that play an important role in an application domain, a corporation, a company,
a product division, or some such entity. Software architecture should be created for a specific architectural
scope, consistently extending the architecture of its enclosing scope, providing context for and constraining
the architectures created in its subscopes. Specifying the scope for architecture is an important part of
architecture itself.

Concerns

Software architecture can play an essential (and independent) role in software development only if it
addresses specific architectural concerns related to system life cycle that are not addressed by other
software development functions and activities. These concerns are not necessarily evident from system
requirement documents or any other system descriptions. Identifying and documenting architectural
concerns and their owners, also called stakeholders, is an important part of software architecture.

Requirements

Architectural concerns should be refined into architecturally significant requirements that are specific in
terms of desired system properties and the way in which achieving these properties influences or constrains
the architecture.

Component Domains

Software exists in multiple forms simultaneously. Some of the most common forms are source or object code
components, executable components, and executing components. There are relationships, but no direct
correspondence, among these different kinds of components. Each kind of component forms its own
component domain. In each component domain, software architecture (as an approach to complexity)
addresses different concerns through independent or loosely dependent design decisions within the
component domain. Identifying the component domains relevant in view of architecturally significant
requirements is an essential part of software architecture.

Structure

In each component domain, independent architectural structures may exist. An architectural structure is
created by the partition of software into components in a component domain and their composition into an
integrated whole. Architectural structures should be traceable to concrete system elements, rather than
being mere conceptual abstractions. Different architectural structures may be interdependent, but they are
not different views of the same entity. Architectural structures are an important part of software architecture.

Views

Architectural views are models of architectural structures or other elements of software architecture. Views
are used throughout the architecture life cycle for specific purposes of understanding and analyzing the
different aspects of system development and performance. The major characteristic of a view is its purpose
and utility. Views are not complete descriptions. In fact, views need to omit otherwise important architectural
information in order to be useful for their specific purpose. The major issue with views is consistency with the
system rather than completeness. Architectural views are a necessary part of architecture on the way to
designing architectural structures and different aspects of system design.

Texture

Recurring microstructure of the software components is at least as important as the system structure. We
call recurring microstructure of components texture and consider it an important part of software
architecture.

Concepts

From the perspective that considers software architecture to be an approach to dealing with complexity,
probably the most important decision is the selection of architectural concepts used to think about the
system. The existence of architectural concepts is often taken for granted. As we explain later, however,
architectural concepts are not found in the application domain or in the implementation domain, but need to
be invented in order to simplify the design, construction, and representation of complex software. All other
parts of software architecture more or less directly depend on the invention (selection) of architectural
concepts. We consider inventing architectural concepts to be the most crucial part of software architecture…

What Is Software Architecture?

The first phase of many new projects developing software-intensive products is the design phase of the
system software architecture. Often one of the first steps in this process is building a common understanding
among the project members about what software architecture is. Active research of software architecture
during the 1980s and 1990s has produced a wealth of definitions that attempt to capture the essence of
software architecture by abstraction. Together these concepts yield the following definition:

Software architecture is defined as components, connectors, constraints, and rationale.

Intellectually, this definition is quite satisfactory. However, in the context of developing and describing
software architecture for a product we need a definition that provides answers to very concrete questions:

 How is architecture related to requirements?

 When is architecture sufficiently understood to proceed with the system development?
 Where lies the boundary between architecture and design?
 Does each product, release, or version have a separate architecture, or should there be just one
architecture for all products in a product family, or even in an application domain?

The definition we will give later directly addresses these and similar questions. This definition does not
contradict or replace the understanding of representing architecture as components, connectors, constraints,
and rationale. It simply puts the emphasis on providing concrete guidance in the process of developing and
describing the architecture of software.

First and foremost, architecture is a set of concepts through which we impose order on complexity. The
concepts we use to think about software determine what is omitted from consideration and what is
emphasized, what is grouped and what is separated. Other, more common expressions of architecture are in
most circumstances elaborations done using invented architectural concepts to answer specific questions.

We build software to perform the function specified by functional and quality requirements. Functional
requirements specify what software has to do. Quality requirements state how well it should be done.
Quality requirements qualify the function in terms of desired performance, availability, reliability, usability,
configurability, or integrability of the system. (These are often called "ilities.")

In addition to the explicit functional and quality requirements, well-designed software addresses other
concerns that constitute implicit requirements for change, reusability, or other kinds of evolution,
interoperability with other systems, and so on.

Even though there may be many different requirements specifying different functionality, qualities, or needed
evolution flexibility, only a few representative requirements influence the architecture and thus are
architecturally significant. The need to focus on architecturally significant requirements leads to the following
definition for software architecture:

Software architecture is a set of concepts and design decisions that enable effective satisfaction of
architecturally significant explicit functional and quality requirements and implicit requirements
presented by the problem and the solution domains.

This definition emphasizes several aspects. First, the reason for software architecture is satisfaction of
requirements. Not all requirements are architecturally significant. There are different classes of requirements
that must be understood in order to create an architecture. Implicit requirements come from both problem
and solution domains. Architecture can only enable the satisfaction of requirements; it cannot guarantee their
satisfaction. Finally, this definition does not emphasize structure-related decisions over other kinds of
decisions. The reason is that the relative weight of structure-related decisions in real systems could be
limited.

To limit the responsibilities of the architecture team, we need to answer the question, Where does the
boundary between architecture and design lie? When setting the scope for the tasks of the software
architecture group, we need to exclude from architectural concerns detailed design decisions made at the
component level. Though such decisions may directly influence the capability of the system to satisfy
important requirements, they do not influence the design of other components; thus the cost of revising these
decisions is limited. Such issues belong to component design. Therefore

Software architecture is a set of concepts and design decisions that must be made prior to
concurrent engineering to enable effective satisfaction of architecturally significant explicit functional
and quality requirements and implicit requirements presented by the problem and the solution
domains.

All successful companies nowadays plan product families rather than single products. Therefore, in practice,
software architecture always needs to address product family concerns. Products that perform similar
functions and share parts form a product family. Multiple releases of a single product that include the
enhancement of either functional or quality features and have to be supported during overlapping periods of
time in essence also constitute a product family. The main problem in developing software product families is
how to achieve sharing of effort and parts when developing variant products while providing variation in their
features and capabilities. Software architecture for a product family must specifically address evolution and
diversification of products even if these are not explicitly stated in the requirements.

Some design decisions that affect both the satisfaction of system requirements and concurrent design have
to do with software structure. This is the reason that software architecture is often identified with the structure
of software. However, not all the design decisions that are essential for satisfying system requirements and
enabling concurrent engineering are concerned with the structure. Examples include decisions determining
the texture of software that include the selection of major component models, design patterns and pervasive
design policies as, for example, flow control, load monitoring, execution tracing and logging. In addition, the
selection of implementation languages and platforms, trade-off decisions, and process-related decisions fall
in the category of architectural concerns. Therefore, our working definition states the following:

Software architecture is a set of concepts and design decisions about the structure and texture of
software that must be made prior to concurrent engineering to enable effective satisfaction of
architecturally significant explicit functional and quality requirements and implicit requirements of the
product family, the problem, and the solution domains…

Architecturally Significant Requirements

A common misinterpretation of the connection between solution and problem domains is the belief that
architecture is determined by requirements. Consequently, some projects needlessly wait to specify
requirements completely before starting architectural design – a point that is hard to reach in reality without
having a good understanding of architecture.

In other cases, detailed product requirements exist because of standards, for example, and architectural
design is expected to address product requirements – which is impossible without going into the detail of
product implementation. In reality, only a small fraction of product requirements have any influence on
architecture. Identifying these requirements is the first step in any architectural work.

Identifying Architecturally Significant Requirements

An important question that needs to be answered by a CFSA is how architecturally significant requirements
can be identified. Although the answer to this question is definitely domain-dependent, some general rules
do apply. Here are some suggestions for identifying requirements that qualify as architecturally significant
requirements:

 Requirements that cannot be satisfied by one (or a small set of) system components without
dependence on the rest of the system. These usually include all systemwide properties and quality
requirements.
 Requirements that address properties of different categories of components – for example, how
components are named, or referred to, by other components.
 Requirements that address processes of manipulating multiple components – for example, system
building, configuring, or upgrading.
 Properties of a product or product family that make it unique, competitive, and worth building. These
are the most important architecturally significant requirements.

It is essential to build the product right. It is even more important to build the right product. Boehm describes
a process for identifying the right product as defined by success-critical stakeholders (i.e., those stakeholders
whose agreement and eventual satisfaction is necessary for the success of the product) (Boehm et al. 1999):

1. Identify the success-critical stakeholders.

2. Identify the stakeholders' win conditions (i.e., the circumstances under which the stakeholder will be
satisfied).
3. Identify win-condition conflict issues.
4. Negotiate top-level win-win agreements.
5. Invent options for mutual gain.
6. Explore option trade-offs.
7. Manage expectations.
8. Incorporate win-win agreements into specifications and plans.
9. Repeat steps 1 through 8 until the product is fully developed.
10. Confront and resolve new win-lose and lose-lose risk items.

This process offers a good framework for defining architecturally significant requirements for the right
product.

Structuring Architecturally Significant Requirements

It is generally accepted that the architecture of software directly affects systemwide properties such as
availability, reliability, and security. Well-structured software also supports requirements for change,
reusability, interoperability with other systems, and so on. If all different requirements were supported by the
same architectural structure, it would be impossible to satisfy them independently. And indeed this is often
the case. For example, requirements concerning performance and reliability interact because software
execution structure affects both kinds of properties.

Often system requirements may be grouped so that requirements in different groups may be addressed by
different and at least partly independent software structures established by partitions of software in different
component domains. Such partitions exist simultaneously and often are independent of each other. Here are
a few examples:

 We address run-time requirements by partitioning software into execution threads of varying priority
(or utility), specifying thread scheduling policies, regulating the use of shared resources, and so on.
 We address change and reuse requirements by partitioning software into modules-substitutable,
unit-testable components having well-defined boundaries, predictable interaction with the
environment, and minimal, well-specified dependencies on other modules.
 We address portability requirements by defining software layers and establishing the conformance of
layers and their interfaces to existing standards.
 We address requirements for independent restart or independent failure modes by partitioning the
software into a set of separately loadable and executable processes.

Architecturally significant requirements must be grouped so that requirements in different groups may be
satisfied independently. Requirements within each group may interact and even conflict. A good rule of
thumb for finding independent requirements is to group them by the time of the software life cycle they
address. Very often requirements that address software development and change can be satisfied almost
independently from requirements that address run-time behavior or software upgrade, for example. We will
discuss this in more detail in connection with different software component domains (see Section 1.7).

The number of architecturally significant requirements in each group should be small, from three to five.
Whenever possible, architecturally significant requirements in each group should be prioritized…

Architectural Structures

A structure of software in a component domain is created by a partition of software into components and
their composition into an integrated whole. For every system it is necessary to determine which structures of
software affect architecturally significant requirements and to group the requirements in such a way that each
group is supported primarily by independent structures that exist in different component domains.

One effective way to identify independent (or partly independent) requirements is by different stages of
software life cycle with which they are concerned. A typical (though somewhat simplified) set of stages when
different structures of software play major roles includes write time, build time, configuration time, upgrade
time, start time, run time, and shutdown time. The most important software structure at write time is the
structure of modules. Thus write time-related requirements, such as feature addition and evolution, porting,
and diversification, are addressed primarily by appropriate module structures that play a major role at write
time.

Similarly, start time-related requirements (such as order, presence, independent operation, and failure
modes) are addressed primarily by appropriate executable structures-the startup or shutdown unit or
component. In addition, of course, run time-related requirements, such as performance or availability, are
addressed by the structures of objects and execution threads-the domain of run-time software components.
Table 1.1 lists some of the most common partitions, along with their requirement and component domains,
and the software life-cycle stages concerned.

Many projects make the mistake of trying to impose a single partition in multiple component domains, such
as equating threads with objects, which are equated with modules, which in turn are equated with files. Such
an approach never succeeds fully, and adjustments eventually must be made, but the damage of the initial
intent is often hard to repair. This invariably leads to problems in development and occasionally in final
products. We have collected several real-life reports of such developments.

In one case, implementation of a complex functional feature was split between two groups. Two functional
clusters were defined, along with the necessary interfaces. Unnecessarily, the modules also ended up in
different processes and had to interact at run time using slower interprocess communication mechanisms.
Another example involved a system that was partitioned into a set of distributed processes. The partition was
motivated by considerations of required parallelism, availability, and fault tolerance. This partition was
subsequently used to allocate additional functionality, which affected resource requirements and timing
characteristics, violating the original design. As a cure, non-real-time functionality was allocated to new
components. However, because the software architecture was identified with its process structure, these
components became independent processes. Consequently, the components had complex interfaces and
performance was compromised.

Our current understanding suggests that designing a software architecture must start with specific
architectural concerns, specify the partition in different component domains, along with a scheme for
integration and coordination of the parts, and explain how this specific partition and the corresponding
integration of the software address the specified architectural concerns. Examples of architectural concerns
may include timeliness, capacity, availability, effective division of work, conformance to standards, use of
existing parts, or controlled propagation of change. To address these concerns, different partitions may exist
in different component domains.

From the point of view of software reuse, architecture that separates concerns pertinent to different
requirement and component domains also results in more reusable components. Therefore it is important to
recognize multiple software existence planes (as described earlier in this chapter), with the associated
component domains and independent partitions of software, and their relations to different requirement
domains.

Architectural Views

Multiple architectural structures should not be confused with architectural views. Architectural structures are
concrete and different from each other. Architectural views are abstractions, and different views may be
different abstractions of the same entity. Take, for example, layers and subsystems-two commonly used
architectural views of software. Subsystems are essentially groupings of modules and are best described by
specifying the modules they contain. Subsystems are commonly vertical sections; that is, they usually
aggregate modules that implement related functions. (We refer to these later as clusters of functionality.)
Layers are horizontal sections that may have different scope within the system. Layers may be confined to a
single subsystem or even a part of the subsystem, or they may extend right across different subsystems.

Layers may be established to address portability requirements by requiring conformance to a set of

interfaces specified by existing standards. A related view that employs layering is used to manage
incremental implementation and functionality delivery. The increment view shows software development
increments that can be used for early system integration. This (usually) layered view of system functionality
may cut across multiple subsystems.

These three cases – (1) subsystems, (2) functional or portability layering, and (3) layers of incremental
development-represent views of module partition. It is important to understand this to avoid conflicts in
description and update through views.

Architectural views play the same role in dealing with architectural information as data views play in
database management systems. We can better understand the value and limitations of architectural views
using the lessons learned about data views in the database community. There are two major issues with
data views: maintenance and update. View maintenance includes processes for ensuring consistency of the
view with the data (and transitively consistency of multiple views). View maintenance may be difficult, but it is
feasible and practical as long as view derivation from the data is not too complex. On the other hand, update
of data through views is attractive but in general does not work.

These conclusions influenced to a significant degree our understanding and use of architectural views in the
ARES project. We understand views as presenting information derived from concrete architectural
structures. Views are defined by the derivation procedures, rather than by the information they present.
Views can be sketched to understand the architectural structures before they are designed. Once
architectural structures exist, views can be changed only after the change is effected in the corresponding
architectural structures. For example, we often need to describe interfaces provided (or required) by a certain
layer or subsystem. Remember that these interfaces are derived as interfaces of the modules included in the
layer or the subsystem.
The term "architectural views" is commonly used to mean a broader category of architectural descriptions
following the well-known work of Philippe Kruchten on the 4+1 View model of software architecture. In the
4+1 model, views denote different areas of concern and categories of descriptions rather than views in the
sense of abstraction of information regarding concrete architectural structures of software.

There are several good reasons to clearly separate concrete software structures that exist in different
component domains from abstract views necessary for managing specific concerns, such as work division,
incremental integration, or portability. Whereas the conceptual architecture and architectural views of
software may need to be built prior to more detailed design, concrete architectural structures are best
described along with detailed design and often after implementation is completed. In addition, the degree of
detail and precision in describing conceptual models, architectural views, and architectural structures is
different. Finally, it is significantly easier to communicate to software developers the importance of concrete
architectural structures than it is to convey abstract conceptual models or architectural views. Understanding
the relationships among conceptual architecture, architectural views, and concrete architectural structures
makes the architecture more accessible to the development team and thus increases the expected lifetime of
the architecture…

Texture of Software

The texture of software is created by recurring (uniform) microstructure of its components. Certain aspects of
software functionality are hard to localize using common programming languages and techniques. Such
functionality cannot be implemented once and then used in different components; rather it must be
implemented multiple times. This fact raises the importance of choices and consistency in the
implementation of such functionality so that it becomes a major part of the software architecture. Decisions
that affect the texture of software have a significant impact on the system, and they are as hard to revise as
decisions regarding the structure. Consistency of the texture is very often a problem because the decisions
appear to be local to component, cluster, or layer design. It is not easy to identify the common concerns
present in the implementation of different components without concentrating on the texture of the software.

Well-designed software has consistent texture. Software components need to observe policies for security,
flow control, overload control, and fault detection and handling; they must rely on infrastructure for
communication, coordination, state maintenance, execution tracing, and so on. To achieve consistency in
component design, the architecture should provide the necessary information. This information can be
provided in the form of aspects, policies, and patterns-each of which we examine in more detail in the
discussion that follows. The texture of software is created by a combination of observed standards; uniformly
applied styles, patterns, and policies; and the use of specific infrastructure, component models, and even
programming languages. Examples of software texture that must be designed and regulated by rules and
standards include uniform component model realization, error reporting, exception identification and
handling, and execution tracing mechanisms…

Final Remarks

Separation of concerns is one of the most basic principles of software design. A good conceptual framework
for software architecture should support the separation of concerns addressed by software components. This
was the main motivation behind the design of the ARES CFSA. The main ideas of our framework are the
following:

 · Architecturally significant requirements should be identified and managed separately from product
requirements. They should be grouped in a way that allows independent satisfaction of requirements
in different groups.
 · Conceptual architecture is a model of key concepts rather than a blueprint for software
construction.
 · Software is not a single entity. It exists simultaneously in multiple planes, each having its own
component domain. Partitions in different component domains should be established independently,
each addressing a different group of architecturally significant requirements.
 · Multiple intermediate functionality layers need to be established between the application domain
function specified by requirements and the functionality provided by hardware. In the write plane,
software components should not span multiple functionality layers.
 · Within each functionality layer, multiple functionality clusters can be defined to form natural
boundaries within which components are identified, developed, and maintained.
  · Consistency of software texture is achieved by defining in the architecture the common aspects
that need to be addressed in the design of all components. For each aspect, the architecture needs
to specify systemwide policies and patterns of component microstructure that address typical
concerns and problems associated with this aspect of component design.
 · Software architects should identify and define the set of architectural scopes relevant for the
specific system. Architectural decisions and descriptions should be allocated to a well-defined
architectural scope. Each software component should belong to a specific architectural scope that
determines the scope of its intended reusability and the scope of allowed dependencies.

(end)

Multi-Paradigm Design for C++

James O. Coplien, Multi-Paradigm Design for C++, page 6. © 1997 AT&T.

Reproduced by permission of Addison Wesley Longman. All rights reserved.

Architecture is the primary output of design. It is the articulation of the things of interest in the system and the
relationships between those things. “Things” may be objects, tuples, processes, and other individually
comprehensible chunks that figure prominently in the designer’s vocabulary and toolbox. For example, in a
finite-state machine (FSM), these “things” include states, transitions, transition actions, messages, and the
machines themselves. The context-free word “thing” is preferable to “abstraction” because the pieces may
not be abstract at all, but rather concrete and complete. Such “things” may be logical architectural artifacts
that lack physical continuity in the source or in memory: An example of this is a process, which comprises
procedures scattered all over a program.

We usually associate the informal term structure with architecture. System structure emerges from the
building blocks we put into it and how we put them together. Both the selection of the blocks and their
arrangement follow the desiderata and constraints of the problem statement. The architecture helps us
understand that the design process addresses the problem. Multi-paradigm design helps us choose building
blocks well-suited to the available solution structures and guides the synthesis of those blocks into a
complete system.

An architecture usually corresponds to a domain, an area of interest for which a system is being built. A
domain may be hierarchical, which means that architectural models may also be hierarchical.

James Madison and the Role of the Architect

Dana Bredemeyer, Bredemeyer Consulting

Email: [email protected]
Copyright 2000 by Dana Bredemeyer

James Madison is called the father of the United States Constitution. It is also appropriate to call him the
architect of the Constitution. He was the chief architect in the effort that defined the architecture of the federal
government of the United States: the roles and responsibilities of it's branches, the relationships between
them, and the principles and mechanisms guiding their implementation, operation and evolution.

The constitution, in just a few pages, defined a stable and flexible system. It has lasted over 200 years and
been the model for numerous other constitutions, and it has been changed 27 times.

Madison was guided by a set of values expressed in the preamble to the Constitution:

"We the people of the United States, in order to form a more perfect union, provide for the common
defense, promote the general welfare, and secure the blessings of liberty to ourselves and our
posterity, …"
These values were not new, but his vision to realize them was new. From his thorough study of
governmental forms throughout history, Madison saw clearly that a governmental structure that would resist
the tendencies toward tyranny demanded a structure and mechanisms to keep power distributed. Tyranny
was the likely result of unchecked, concentrated power. To define a governmental structure that supported
the values expressed in the preamble, and particularly to ensure against tyranny, he articulated two central
principles, the separation of powers, and checks and balances. Distribute power, and keep it distributed.

Separation of powers led to the creation of distinct governmental branches with specific responsibilities
assigned to them alone. Checks and balances led to the creation of interaction mechanisms to keep power
from becoming concentrated in any of the separate branches. The president can veto legislation. The
legislature must advise and consent to certain presidential appointments. The courts can declare legislation
unconstitutional.

Success depended on much more than understanding governmental structure. Madison needed to change
minds. The architect leads from an overall vision. Madison had such a vision entering the Constitutional
Convention in 1786, already articulated in the Virginia Plan, which formed the basis of the Convention's
deliberations.

On the value of liberty they all agreed. But Madison's plan to achieve it was radical, replacing the weak
confederation of independent states with a strong union led by a powerful national government with powers
to tax, raise an army, and veto acts of states. His challenge was to associate a shared set of values with a
specific proposal for a national government that embodied them, and to do that strongly and vividly enough
to overcome deep resistance. The separation of powers was not popular among the American states after
the revolution. Legislatures in most states had all the power, leading to abuses of power similar to Colonial
rule under the British. Additionally the states were generally not supportive of a strong central government.
Madison was moving people from a state-centric to nation-centric view. In the larger and more complex
union of states, liberty needed to be designed in at the national level, and this required the states to become
less independent, more interdependent.

Approval at the Constitutional Convention was just the beginning. The constitution still needed to be ratified
by the states. Working with John Jay and Alexander Hamilton, Madison wrote the Federalist Papers, 85
arguments in favor of the Constitution, published individually in newspapers over the next three years. Anti-
Federalists mounted a strong campaign against ratification, and the Bill of Rights was added in response to
some of their concerns. Finally only Rhode Island held out, and ratified only when the other twelve states
threatened a trade war.

Madison had established and shared a clear vision. He understood the problems of governmental structure,
and he took responsibility for the problem from vision through implementation. He provided strong motivation
and rationale for the approach he proposed, and he argued persuasively, persistently and passionately until
the constitution was fully ratified. His work has survived and guided a nation for two centuries, virtually
unchanged.

Acknowledgments

Bill Crandall, of the Product Generation Solutions consulting group in Hewlett-Packard originated the idea of
using James Madison and the creation of the U.S. Constitution as a metaphor in our software architecture
workshops. Since then, I have done a fair amount of reading about Madison and the Constitution, and the
metaphor has grown in richness as my understanding and models of software architecture and the role of the
architect have matured. Thanks Bill!

Thanks also to Rand Barbano and others in the HP Product Generation Solutions group (previously called
the Software Initiative) for teaching me the value of stories as a medium for instruction. We tell this story, and
many others, in the software architecture workshops. Like all good stories, they bear hearing again and
again, for there are always new interpretations and relevancy's to find.

References

Crandall, Bill, "James Madison, Architect," Fusion Newsletter, May 1997.

Rakove, Jack N., Original Meanings, Alfred A. Knoph, 1996.
Rakove, Jack N., James Madison and the Creation of the American Republic, 1990.
The Tao of the Software Architect

Lao-Tsu, revisited by Philippe Kruchten

Philippe Kruchten
Director, Process Development
Rational Software Canada
Tel: (604) 269-3204
fax: (604) 263-5350
E-Mail: [email protected]
www.rational.com

650 West 41st Avenue Suite 638

Vancouver, B.C., V5Z 2M9
Canada

This is a very liberal reading of Lao-Tsu's Tao Te Ching for the use of software architects, based on various
French and English translations. The number refers to the original tablets.

The architect observes the world but trusts his inner vision. He allows things to come and go. His heart is
open as the sky. (12)
The architect doesn't talk, he acts. When this is done, the team says, "Amazing: we did it, all by ourselves!"
(17)
When the architect leads, the team is hardly aware that he exists. Next best is a leader that is loved. Next,
one who is feared. The worst one who is despised. (17)

A good traveler has no fixed plans and is not intent upon arriving. A good artist lets his intuition lead him
wherever it wants. A good scientist has freed himself of concepts and keeps his mind open to what is. Thus
the architect is available to everybody and doesn't reject anyone. He is ready to use all situations and does
not waste anything. This is called embodying the light. (27)

If you want to shrink something, you must first allow it to expand. If you want to get rid of something, you
must first allow it to flourish. If you want to take something, you must first allow it to be given. This is called
the subtle perception of the way things are. The soft overcomes the hard. The slow overcomes the fast. Let
your workings remain a mystery. Just show people the results. (36)

When the process is lost, there is good practice. When good practice is lost, there are rules. When rules are
lost, there is ritual. Ritual is the beginning of chaos.*(38)

The architect concerns himself with the depth and not the surface, with the fruit and not the flower. (38)

The architect allows things to happen. He shapes events as they come. He steps out of the ways and let the
design speak for itself. (45)

The architect gives himself up to whatever the moment brings. He knows that he is going to leave, and he
has nothing left to hold on to: no illusions, no resistance in his mind. He holds nothing back from the project,
therefore is ready for departure†, as a man is ready for sleep after a good day's work. (50)

The great way is easy, yet programmers prefer the side paths. Be aware when things are out of balance.
Remain centered within the design. (53)

The architect's power is like this. He let all things come and go effortlessly, without desire. He never expect
results; thus he is never disappointed. He is never disappointed, thus his spirit never grows old. (55)

Those who know don't talk. Those who talk don't know. (56)
Alternate:
Those who do not have a clue are still debating about the process. Those who know, just do it. (56)

The architect is content to serve as an example and not to impose his will. He is pointed, but doesn't pierce.
Straightforward, but supple. Radiant, but easy on the eyes. (58)

If you want to be a great leader, stop trying to control. Let go of fixed plans and concepts and the team will
govern itself. The more prohibitions you have, the less disciplined the team will be. The more coercion you
exert, the less secure the team will be. The more external help you call, the less self-reliant the team will be.
(57)

-----------------------------------------

* Sounds a bit like the SEI CMM! Jim Archer said: "First you pay for results, Then you pay for effort, Finally
you pay for attendance."

† Especially when he's only a Rational consultant.

Characteristics of an Organization with Mature Architecture Practices

Joe Batman
Software Engineering Institute

1. Introduction

When looking at an organization and its products to determine the role that architecture plays in that
organization it is necessary to examine both the products, to assess how architecture contributed to
their development, as well as process and organizational factors. As systems become larger and
more complicated architecture assumes a more important role than has traditionally been the case.
Exactly how organizations make use of architecture is an important indicator of their success in
developing complex systems that meet requirements in a cost efficient manner. A product line, with
its heavy reliance on reuse of common assets, is very dependent upon establishing an effective
architecture as the foundation for the products and their management. Architecture, as we are using
it here, serves the role of a building plan for a system or set of systems. It is a specification
describing how the system is structured and how the parts of a system coordinate their activities. It
is, in large part, a set of design decisions made by senior designers, or architects, that address
important system-wide issues. It is the set of decisions that the architect has made to guarantee that
the system elaborated from the architecture will successfully satisfy those important issues
regardless of how low level design decisions unfold, providing the architectural specification is
complied with. Effective use of architecture as a means to reduce and manage system complexity
appears to depend rather heavily on the use of prescriptive architectures, that is, architectures that
serve as specifications for system development and constrain developers with regard to certain
important system issues. Many traditional system architectures are what is sometimes termed
descriptive architectures, that is, the architectural documentation (if available) describes the structure
of a system at some point in time as it is understood by the document writers. Usually, this describes
the system as document writers think it is built. However, descriptive architectures do not serve
effectively as blueprints for system development. Many systems, in fact, have no architectural
documentation although they certainly have architectures, the nature of which may or may not be
known. We consider these to be descriptive by default. Descriptive architectures are really the result
of the collective actions and design decisions of all of the developers (including design decisions
made during integration necessitated by discovery of defects) and are an emergent property of the
system. They are not used as a plan for constructing the system that guides and constrains
developers in making their design decisions.

Prescriptive architectures are so important because they directly attack the problem of how to insure
that system concepts are created that are effective in reducing complexity and abstracting system
characteristics so that human designers can retain intellectual control of the artifact they are
creating. This intellectual control relies on the ability to understand the gestalt of a system by having
 a manageably small number of simple models that embody widely used patterns of structure and
coordination throughout the system. These patterns are selected on the basis of domain
characteristics, system goals, and engineering judgment on those issues that are deemed critical to
system success. An example of the effective use of architecture is in planning military operations. It
would be impossible for human commanders to reason effectively about a task force they were to
command if the units involved did not have prescribed archetypal organizational structures with
capabilities and limitations prescribed by tables of organization and equipment, standardized
training, and uniform doctrine and policy. If each unit had a unique internal structure, different
equipment, unique command structures, different communications methods, etc., it would be
impossible for a commander to plan their use with any assurance that the plan was feasible for any
but the smallest organizations. At some point the uniqueness of each of the units overwhelms the
ability of a human to understand or deal with the collective behavior of the task force. Although units
vary because of individual soldier's capabilities, unit strength, and equipment readiness they vary
within certain prescribed and well-understood limits.

If we are investigating the feasibility of creating systems with high levels of reuse or establishing a
product line then how an organization deals with the issue of architecture is of signal importance.
Two areas of particular interest are: the current state of architectures in use or development that can
be a basis for constructing a product line and the sophistication or maturity of the organizations that
will be developing product line assets. In the following section we will discuss the sort of things we
expect to see in promising architectures and the organizations that are capable of creating them.

2. Issues of Interest for Architectures

Characteristics of an Effective Architecture

The first area to be investigated is the architecture or architectures that vendors have already fielded
in existing products or are developing for imminent release in products. These architectures may
fulfill the requirements for a product line or may be a basis for defining such an architecture.
Additionally, the existing products or components are potential candidates for inclusion in any
subsequent product line. We look, in particular for the following characteristics:

o Use of the architecture as a prescriptive plan for construction of the system. Effective use of
architecture is indicated by the creation of a plan, addressing critical system-wide issues, for
structuring the resulting system and then developing the system in compliance with that
plan. Thus, most effective architectures are defined prior to detailed development and
constrain detailed design. They carry the decisions made by the architect and disseminate
those decisions to developers.
o There must be clear identification of structural patterns and coordination patterns that
abstract important characteristics of the application domain. The architects must clearly
identify a small number of key patterns of structure that are sufficient for implementation of
the system. These structural patterns are templates for the organization of the system and
elaboration of its components. They must be clear and understandable with minimal
complexity and the number of patterns must be relatively modest. Each pattern, to be
effective, must leverage a substantial portion of the system's organizational structure. They
serve to reduce the variability of design across a system while clearly identifying the
anticipated locations for variation. The reduction of variability minimizes the complexity of the
system allowing more effective reasoning about the system as a whole based on the
understanding of the characteristics of a small number of repeating patterns. They also
facilitate the standardization of infrastructure services and common utilities and provide a
consistent context for components that increases component reusability. The notion of
leveraging system understanding from the characteristics and properties of a small number
of archetypes applies equally to coordination of activities in the system. These coordination
patterns or protocols characterize the interactions that are permitted between components of
the system and, again, allow designers to leverage understanding of how the system's
components dynamically interact by understanding of the properties and behaviors of a
small number of coordination protocols. Each interface in the system is mechanized with one
or more of these coordination protocols. The architecture usually embodies these
 coordination patterns in infrastructure capabilities that are made available for use by the
various system components.
o Architectures must provide identification of partitions within the system. A primary division is
that between system infrastructure and the applications. The architecture must clearly
identify the existence of a system infrastructure, defined in detail by the architecture
specification, and the existence of the system applications, parts that implement the mission
specific functionality of the system. Infrastructure is ubiquitous and provides capabilities to
all applications uniformly. The architecture specification identifies the details of infrastructure
design and characteristics, including the interfaces used by applications. This gives an
unambiguous picture of what system capabilities are provided as common services to the
application developers and allows them to focus on application related details and not be
diverted by functionality required to integrate their components into the system. Further
partitions are identified within the infrastructure to organize the system wide capabilities and
allow efficient allocation of requirements related to common services and overall integration
of the system. Applications partitions are also identified along with the allocation of functional
requirements to them. This represents the first mechanism for validating the coverage of
system requirements. Application partitions provide placeholders for mission specific
functionality defined by the application developers.
o Partitions are a way of ordering a system in its decomposition. There are a great many ways
of organizing solutions to a design problem but partitions are not arbitrary. We generally
expect tighter cohesion and coupling among components within the same partition than
between components across partition boundaries. Partition boundaries are often a location
where architectural constraints govern the interaction of components. Tighter cohesion
between the functions allocated to a partition allows for components within a partition that
are more tightly focused on a specific set of application capabilities and helps reduce the
number of interfaces required within partitions and between partitions. Partitions do not
necessarily reflect the physical model of the system or structure of compilation units.
o An architecture must identify interfaces between the target system and external systems and
major and critical interfaces within the target system itself. Architectural views should be
provided that illustrate the interfaces and identify those infrastructure capabilities (and the
coordination patterns they implement) used to mechanize each interface. Architectural views
for a reference architecture will identify the external and component level interfaces by
specific details where known and by abstractions where they are determined by target
system elaboration. Target architectures will provide specific details of interface content.
o The architectural specification should fully characterize interface mechanisms so that
infrastructure developers will know what to build and application developers will know what
capabilities are available and how to use them.
o The architectural specification should identify common services and utilities, other than
interface mechanisms, that the infrastructure will provide. The specification should describe
how they are used, what their intent is, what assumptions are incorporated in their design,
and the details of their interface. The architecture should identify system states and modes
and describe what each component is expected to provide to support those states and
modes and what general behaviors they can expect from the system in each state and
mode.
o The development environment in support of the architecture should provide structural types
used for component construction. Structural types are a realization of structural patterns
identified during architectural design and embody the coordination protocols supported by
the infrastructure. They identify locations where developers must provide functionality and
where development tools or templates provide default capabilities. Each component of the
system is an instance of a structural type defined by the architecture. The environment may
provide special tooling, component templates, or instruction guides for developers to use in
instantiating these types.
o The architectural design must provide an effective information protection strategy to
encapsulate components, infrastructure, and external interfaces. This protection strategy
supports a decoupling of components from the implementation details of other components
and external systems. Within the constraints of performance requirements this is one of the
most important properties enforced by an architecture. It ensures conceptual integrity by
managing proliferation of complexity and allows abstraction of stereotypical behaviors. It is a
major contributor to the ability of the architecture to provide intellectual control over the
system. It insures against side effects and hidden interfaces. An effective information
protection strategy has a major impact on the integrability and maintainability of the system
as well as on its reliability. We look for protection from the specific details of system
 components such as operating systems, file management systems, database management
systems, hardware devices, inter-process communications facilities, and user interfaces.
o Architectures should isolate system components from the environment in which they operate
as far as is feasible. Application components should not be tasked with dealing with
contention for system resources, determining communications routing, or maintaining a
model of the location of other system components, except where unavoidable.
o The architecture should provide an explicit description of the assumptions built into the
architecture including those required by the infrastructure. It should further provide a
detailing of the assumptions that components make that effect the interfaces in which they
participate. Knowledge of the assumptions used in constructing system components is
invaluable in being able to integrate the system in a timely and cost effective manner and in
maintaining the system over its lifetime.
o The architecture should support the incremental addition of system capability. The
infrastructure should support incremental development allowing new functionality to be
added without requiring changes to existing functionality or without requiring extensive retest
of previously integrated components. Incremental development facilitates integration,
parallel development of system components, and testing of components as black boxes.
This reduces the need to retest components when changes are made to implementations or
when common components are incorporated into other products.
o The architecture should provide instructions and guidelines for detailed decomposition and
lower level partitioning by developers during detailed design. These should be based upon a
comprehensive approach to systematize the analysis of the system and documentation of
the design. These instructions reflect choices about particular analysis and design
paradigms and, frequently, reflect capabilities of the development support environment. It
allows for compatible methods of analysis and design across the system that enable
modeling of the system and parameterization of component costs (technical as well as
financial).
o Architectures should foster the creation of the simplest solution to a system problem that is
consistent with performance requirements, functional requirements, and system qualities.
Elegant but complex solutions make for interesting academic papers but often result in
systems that are difficult to comprehend and are brittle under change.
o In general, an architecture should strive through its standards for uniformity across a single
class of problem. Systems are more robust and more predictable when a uniform solution is
applied across the system instead of using a collection of unique point solutions for what is
essentially the same problem.
o Adaptation instructions and implementation guidelines for the architecture should provide a
clear identification of what decisions or kinds of decisions are left to the discretion of
designers and what decisions are conveyed by structural types. Adaptation instructions and
implementation guidelines identify where application designers must provide functionality to
satisfy allocated requirements. They also identify where implementers may use discretion in
providing unique or non-standard components or component implementations and interface
mechanizations. They further identify what infrastructure capabilities must be used by
components and what behavior and service those capabilities provide components.
o Exceptions to any architecture are probably inevitable, especially over an extended lifetime,
and in particular where a reference architecture is instantiated for multiple target systems
(products). There must be specific processes defined for how exceptions are requested and
adjudicated including where the authority lies to grant exceptions. The processes must
ensure that exceptions are granted only for compelling reasons since they are a source of
complexity that can compromise conceptual integrity and intellectual control. They can also
foster the spawning of multiple baselines offering relatively low payback and limited
additional capability in the face of high maintenance costs. The processes must, however,
be reasonable and efficient.
o The architecture must anticipate the necessity for exceptions and provide mechanisms to
accommodate them with a minimal degradation of system qualities. The architecture must
be designed for change, and must acknowledge the need for variation. Where applicable, It
must anticipate the use of legacy components or components from other vendors (e.g.,
COTS) with foreign architectures in a way that preserves the conceptual integrity of the
system.
o The architecture must clearly derive from a set of driving architectural requirements that are
adjudged by the architects and other stakeholders to be of sufficient importance to the
system and its qualities that specific architectural mechanisms are required to insure their
coverage. These requirements must be a manageably small set or the resulting architecture
 will be unwieldy and brittle. There is a fine balance between controlling development and
over-controlling development and quashing innovation or forcing application developers to
implement inefficient, overly complex, or fragile components. The architecture and its
infrastructure should be the minimum required to guarantee satisfaction of the driving
requirements. Requirements not critical to the system overall should be allocated to
application components or utilities, as appropriate. Driving requirements should succinctly
establish the need for each capability and capabilities not supported by driving requirements
should be omitted.
o The architecture must provide adequate documentation so all users can understand how to
employ it and how it structures the system and its behaviors. There must be a sufficient
number of static views and dynamic views. It should include a high level description
sufficient to impart the abstractions provided by the architecture. It also should include
sufficient details for understanding how infrastructure services and utilities operate, what
specific capabilities they provide to components, the intent of the developers with regards to
their use, and how they are to be used. Documentation should include adaptation guidelines
for instructing architects and systems engineers how to adapt the architecture to products
and how to instantiate target architectures from the reference architecture, where applicable.
Guidelines for implementation must also be provided for component developers including a
complete description of structural types and their use in creating components. Those
guidelines must also discuss the coordination protocols that govern how the components
communicate and synchronize so developers understand how to integrate multiple
components. If architects anticipate the reuse of the architecture on multiple products they
should provide information for systems designers on how to analyze their problem within the
framework of the architecture and guidelines for evaluating the suitability of the architecture
for their purposes.

Reusing or Exporting Architecture

In a sense a good architecture is always reused. Its common services and utilities are accessed by
all system components and those components instantiate the structural patterns of the architecture.
The components also communicate and synchronize their activities via the coordination protocols
defined. Those things that make an architecture an effective and efficient structure for a single
system also contribute effectively to the reusability of the architecture and components constructed
in compliance with it. We can, however, identify certain factors that have a strong impact on
reusability.

If an architect is developing a design for a product line and, therefore, anticipates that the
architecture will be used on multiple products there is additional motivation to address those factors
contributing most to reuse. In many cases this drives the architect to create an adaptable structure, a
reference architecture, that is specifically intended to be instantiated in multiple target systems. This
is an effective way of providing a consistent level of abstraction across multiple products while
allowing a desirable level of variability and the capability to adapt these abstractions to individual
products with unique requirements. The resulting reference architecture will probably abstract the
domain characteristics and system requirements to a higher level than for a singleton system and
will, usually, anticipate a greater degree of variability than expected for the single system.

Among those factors that are particularly important for reuse of an architecture are:

o Insuring that the requirements process covers the entire domain. The elicitation process that
generates the driving architectural requirements must be comprehensive and cover all
potential application areas and products that are envisioned for the architecture. This does
not imply implementation of a single architecture that satisfies the entire domain but must
provide sufficient flexibility in the design to allow support of all anticipated uses.
o The architecture should be compact, that is, it must be minimalist. Since it is anticipated that
it will be required to adapt to a greater number of intended uses it must have sufficient
flexibility to do so without compromising conceptual integrity or invalidating use (reuse) of
important common assets. An expected approach is the inclusion of patterns common to the
 broad domain and the identification of the need to support variability by anticipating inclusion
of additional patterns suitable to support a single product or subset of the application
domain. This allows, in effect, for extension of system infrastructure to better meet
requirements of a subset of the domain.
o The architecture needs good abstractions that clearly isolate variations among products. The
architecture's design must anticipate the variations between different intended uses or
products along several different axes. Variation can be anticipated in different component
implementations or algorithmic variations within components. Variation can also be
anticipated in different mixes of components as well as differing decompositions of
application partitions. Specific features must be included in the architecture to support this
variability in an orderly and well understood way.
o Architects must anticipate the maintenance of a reference architecture. An architecture that
is reused for multiple purposes or systems as a reference architecture instantiated anew in
each product must recognize the necessity of changing in response to the needs of the
target systems. The nature of these systems and their requirements are likely to change as
markets and operating environments evolve. For the architecture to be viable it must be
capable of supporting this evolution. Architects and managers must provide orderly
mechanisms to propose, evaluate, implement, and manage changes to the reference model.
o Plan for testability and minimizing retest. The architecture must provide the structural
properties and qualities that allow efficient testing in an incremental fashion. It should allow
dual white box / black box testing to facilitate parallel development, ease integration, and
prevent costly retest of components when changes are made to systems. This is particularly
important to avoid schedule and cost impacts associated with retesting of common reusable
assets.
o The architecture must be well documented. The documentation must be clear and
unambiguous and include pertinent material for each audience that will use it.
Documentation is notoriously difficult for software developers. In part this is because so
many systems are built with unmanageable variability and are overly complex for what they
do. Architecture itself addresses some of these issues but documentation is crucial and
becomes increasingly important if an architecture is to be exported across department
boundaries, to additional sites, or to other corporations. The people charged with managing
this manner of reuse cannot rely on a common culture and shared understanding of asset
properties, assumptions, and lessons learned in using the architecture and associated
common assets. The documentation must explicitly identify all anticipated variation and
provide details as to what assumptions impact the variability locations and how the
architects and common asset implementers intended variation to occur.
o There must be a workable plan for sustaining the architecture across the community or
communities using the architecture and over its lifespan, or the lifespan of the associated
product line. There are a number of strategies for sustaining an architecture and common
assets. The choice is influenced by how the ownership is managed, how components are
developed and maintained, how products are created, and what organizations are involved.
A key element for success is creation of a sustainment plan that lays out exactly how the
architecture will be controlled, how components are certified for compliance, or how systems
are evaluated for compliance. Support contractors may be required to handle change
requests, perform compliance tests, etc. A good concept of operations that plans the
creation, implementation, testing, sustainment, and retirement of an architecture or product
line is essential.

Characteristics of Organizations Using Architecture-centric Design Approaches

There are additional factors to consider when determining where a particular community is with
respect to architectural practices. The quality and characteristics of existing architectures are
important considerations but we also look for the institutionalization of practices that support effective
use of architecture. Our interest is in determining whether an organization or community is capable
of producing good architectures on a routine basis and not simply because of the fortuitous
conjunction of conditions. Adjusting an organization's structure, development processes, and
management practices to the structure of its products can have important benefits that result in
greater organizational efficiencies. Areas of interest include:
o Architectures should be created within a defined process atmosphere that imposes
standards for activities such as: configuration management, naming conventions, coding
style, review of designs, review of test plans and procedures, etc.
o The incorporation of architecture design and evaluation into development processes and
plans. This includes a recognition of the use of architecture as a set of high level design
decisions effecting the subsequent elaboration of the system in a prescriptive way. Evidence
of this should appear as processes that contain architectural design activities early in the
design process and include specific reviews and milestones for architectural design. There
should also be some form of architectural evaluation targeted to evaluate the suitability of an
architecture for its intended purpose. Corporate and project process plans should specifically
identify a phase of architecture design occurring early in the design process. This should
include an early requirements elicitation activity intended to derive driving architectural
requirements when a new architecture is required or to evaluate existing architectures for
suitability for the intended product, including any adaptations that may be required. There
should be provisions in plans to allow the proposal and development of adaptations to
existing architectures. Design processes should specify that architectural conformance be
assessed as an integral part of design reviews.
o Management of the development process should reflect the central role of architecture
specification. Organizations adapted to using architecture-centric design should reflect this
fact in their management policies and practices. Program plans and schedules should reflect
the use or architecture as an organizing factor during development, integration, test, and
sustainment. The work breakdown structure should reflect the use of architecture and the
structuring of the system imposed by the architecture.

At a corporate level one expects to see policies, processes, and investment that support the
creation and maintenance of sets of common reusable assets. This is particularly important
for product lines and reflects a realization that the standardization enforced by architecture
and the control of variation that results are enabling factors for effective reuse. There should
be definition of how the need for a common asset is identified, how it is created, how it is
funded, how it is configuration managed, and how information about the existence of and
properties of common assets is disseminated among developers. Specific attention should
be placed on maintaining the common baseline and adjudicating when departures from the
baseline or creation of another baseline are justified. There should be formal procedures for
configuration managing sets of common assets and the architectures associated with them
(architectures are themselves reusable, common assets). Architectures must be adaptable
and flexible but their evolution must be controlled. Since architectures exert so much
leverage on products created with them any compromise to their integrity can have serious
consequences. A key element often overlooked is the need for specific and comprehensive
requirements elicitation for architecture. It is fairly important to get these driving
requirements correct since they impact the entire system or product line. It is easy to
overlook requirements and, thereby, allow excess variability in systems or to specify too
much and end up with an unworkable structure that forces systems to be inefficient.
Corporate policies and plans should make provision for this elicitation and outline a process
for validating the results.

A second element frequently overlooked in process plans is adequate provision of a process

for sustaining the architecture. This involves a method for stakeholders to propose changes
and mechanisms to manage the change process including the analysis, implementation,
testing, and configuration management. There should be clear identification of where the
authority for changes lies. The fact that an organization may be doing the above is not in
itself sufficient to indicate maturity. Grass roots efforts resulting in informal incorporation of
architecture-centric and product line practices are often successful in the short run but
depend on the personalities involved and the degree of communications prevalent.
However, only institutionalized process can ensure that the architecture or product line
capability lives beyond specific individuals to become. Indicators of this corporate
commitment include visibility to architecture at the highest levels of management, the
commitment of corporate resources to creating and maintaining sets of common assets, and
the championing of architecture by one or more individuals at high levels of management.
Evidence of this commitment should be visible vertically from upper management, through
middle management, and down to the developers.
 o Quality assurance organizations should be integrated into the process of architecture design
and evaluation. Their inspections should directly address architecture requirements
elicitation, architecture design, and architecture compliance. Quality assurance
organizations also need to support the sustainment activities including the evolution of the
architecture.
o An architect or architects should be assigned to each project. Corporations and managers
recognize the important role of architecture by appointing people with specific
responsibilities for creating and managing architecture. These architects may be appointed
at the project level or may be shared over multiple projects but each project recognizes the
role and its responsibilities.
o There should be a training program for developers and other stakeholders to educate them
on the role of architecture in the development process as well as the use of specific
architectures in development of architecturally compliant product components. Training
should also cover the process matters related to development that are impacted by
architecture. It is a good sign if specific programs to grow good architects are in place to
foster their development from within organizations.
o Related to both training and the championing of architecture is the need to address the
cultural issues associated with architecture-centric development. Traditional development
approaches tend to either ignore architecture in favor of immediate detailed design or
produce an initial view of architecture that developers are either not required to adhere, that
provides insufficient constraint on developers, or that is not enforced. The actual system
architecture becomes an emergent property of the system. Architecture-centric design
where architecture is used as a prescriptive plan for constructing the system represents a
paradigm shift for many developers and organizations. A lot of attention must be paid to
helping developers and managers to successfully make this paradigm shift. The importance
of this should not be underestimated because it is not always an easy shift to make and it is
easy to use a terminology that sounds architecture-centric but is, in fact, simply the old way
of doing business.

Lesson Learned About Architecture: Unstructured and Eclectic

Clayton Sprung
Consulting Analyst BCTEL
Vancouver, British Columbia,
CANADA
[email protected]

1. What do architectures and great order of things have in common?

o They breed true until trouble strikes; then they mutate.
o Then new patterns continuously emerge and if they're viable and stick they often grow
exponentially.
2. What do architecture and world peace have in common?
o Both are noble and worthwhile but elusive, where purity is a fantasy.
o Therefore, it's ongoing and iterative and someone must lead the political process.
3. What can architects learn from the United Nations?
o It's a game of influence, not power, and the trick is to lead from behind, walk softly, and carry
a big stick.
o Beware of the sin of hubris: It's always easier to see minor imperfections in someone else's
ideas rather than the major inadequacies in one’s own.
4. What do architecture and government have in common?
o They both steer better than they row.
5. What do architecture and knowledge management have in common?
o One of the primary principles is relevance before completeness.
6. What do architecture and the judicial system have in common?
o The Jury (designers/implementors) tend to think of what outcome is appropriate for this
situation.
o When the law (the architecture) fails to reflect what is right and just, they tend not to apply it.
o The Judge (architect) tends to think of what outcome is appropriate for the long term of the
system (judicial).
 o The spirit of the law is more important than the letter of the law.
7. What do architecture and alliances have in common?
o Cash cements commitment.
8. What can architects learn from before?
o Legacy systems have one big advantage: They work. Ours were architected, designed, and
implemented 5 years before the PC was born and are the backbone and workhorses of our
business today. The fact that they are still relevant is a sheer miracle and an amazing
achievement but weren't not by accident.
o Oh, how I yearn for the good old days, a simpler time with fewer choices, bigger benefits and
long cycles!
9. What can architects hope for beyond?
o Not unlike the PSTN we all know and love, the true genius of this great role model
architecture is it passes the test of time and has been exploited by others in ways
unforeseen by the original master designers.
10. What do architecture and nature have in common?
o The more adaptable a species is, the less efficient it is.
o People require less precision than a software solution.
o You can't escape the gene pool.
o A critical success factor is biodiversity. IBM was right: Think but for god’s sake don't all think
alike.
11. What do architecture and poker have in common?
o To win you must adapt your strategy from tight to loose based on the situation you
encounter.
o It's the game from hell: You can't win, you can't even break even, and you can't get out of
the game.
o You’re in hell, want heaven, but live on earth, and that’s all you can afford.
12. What do the weather and architectures have in common?
o A safe prediction is that they will both eventually change.
13. What do architects and downhill racers have in common?
o To win, you must first be able to see in your mind’s eye the whole race from start to finish.
Without this mental model, it's hard to make the right and necessary course adjustments
when obstacles are encountered.
o When it comes to the race, get out of the gate quickly, stop for nothing, and go like hell.
14. What do architecture, infrastructure, and war have in common?
o All the value comes near the end.
15. What do infrastructure and money have in common?
o Once you get a little, you immediately want a lot more.
16. What do architecture and strategic planning have in common?
o They both tend to be black holes that suck in everything around them and never spit
anything out.
17. What can architects learn from financial analysis?
o Success is being able to identify the significant stuff.
18. What can architects learn from business people?
o The bull---- walks when the money talks.
o Compassion is found directly underneath the wallet.
19. What can architects learn from medicine?
o When it comes to triage, maximize survival by bypassing the dying, comforting the injured,
and getting directly to work saving those who can truly benefit from your help.
20. What can architecture learn from “Origins of the Species”?
o All complex systems are evolutions of simpler ones.
o Form and function evolve in parallel over multiple interactions.
o The first generation is rudimentary, getting the basics right and then evolving with
subsequent generations to become increasingly specialized and more robust.
o It's not the strongest of the species that survive, nor the most intelligent, but the ones most
responsive to change.
21. What do good wine and great systems have in common?
o Age and maturity are extremely critical.
22. What can architects learn from “creation”?
o God created the earth in seven days because there was no installed base.
o The truth is, the best road to the future doesn't start from here but here's what we got.
23. What can architects learn from Frank Lloyd Wright?
 o Elegant, architecturally inspired, and functional homes with leaky roofs.
24. What can architects learn from Leonardo?
o A recognition of and appreciation for the interconnectedness of all things and phenomena:
Systems Thinking.
25. What can architects learn from sailors?
o All important journeys into the unknown require frequent star fixes.
26. What can architects learn from Sun Tzu?
o It's easy to take over from those who don't plan ahead.
o Those who are able to adapt to changes in the enemy and achieve victory are considered
supreme.
27. What can architects learn from law?
o The spirit of the law is more important than the letter of the law.
28. What can architects learn from the marketplace?
o It's a war of maneuverability, not position.
29. What can architects learn from Grady Booch?
o “There has to be a recognition that the days of discreet applications development projects
are rapidly coming to an end... Because software is so critical to business success, it now
has to evolve more or less continuously. To keep the business up and running software
development organizations can't afford to throw things away and start from scratch, they
need to make incremental improvements all the time. This, in turn, implies that a strong
architectural vision is important in order to maintain the conceptual integrity of the whole
system. An incremental and interactive software life cycle, together with strong architecture,
are consistent factors in successful software development organizations worldwide.”
30. What can architects learn from John Kenneth Galbraith?
o When the facts change, I change my mind. What do you do?
31. What can architects learn from the Chinese leadership?
o They are reluctant to become dependent on foreign devils for critical technologies. Are we
as wise?
32. What can architects learn from farmers?
o You reap what you sow and it’s a poor farmer who doesn't keep the weeds down and the
pests and varmints out.
33. What can architects learn from marketing?
o Problem/Solution selling works best. Alas, it's much easier to sell weed killer than
prevention.
34. What do OPEC and IT have in common?
o They're both long on promise but come up short on delivery.
o For OPEC it’s too much too soon for too little, for IT it’s not enough not soon enough for too
much.
o So, be from Missouri: Seeing is believing, more risk management and less faith.
35. What can architecture learn from Marshall McLuhan?
o First we shape our tools (architectures), then they (architectures) shape us.
o If the medium is the message then the IT infrastructure is the enabler.
o Systems are always defined in terms of available solutions where technology, tools, and
talent always pace the solution.
36. What can architecture learn from “the enlightenment”?
o The quest for “the great unifying theory” is a noble undertaking but a fool’s errand, for today
we just don't know enough.
37. What can architects learn from neuroscience?
o Not unlike our minds, our systems may dream. Current theory speculates that as we rest, we
first reduce external stimuli and then sift through the events of the day. Some we forget;
others we file for future recall.
o There is a monitoring center but no master control. There are cooperating independent area
that function while keeping other areas apprised and adjusting to their surroundings. That's
"Sensors, Stimulus, and Situation" where all critical life support functions are autonomous
and replicated.
38. What can architects learn from the telephone system?
o It's a perfect role model architecture for the network computing infrastructure where every
device in this system of systems has a common means of connecting to the network.
o On the other hand, the network is a very complex system that is professionally managed and
modernized by skilled technicians. The success of this model is the result of strict adherence
to open standards.
39. What can architects learn from the military?
o When the critical success factor is communications and understanding then use a short
chain of command. When the critical success factor is reaction time then understand the
doctrine.
40. What can architects learn from weapon systems?
o They both need a quick time to target, maximum kill ratio, minimal collateral damage, and
must never fail in the heat of battle.
41. What can architects learn from social systems?
o In highly politicized situations, the ’how’ can be more important than the ’what’.
42. What can object (component) architects learn from wealth?
o For money it's "accumulate then manage", for solutions it's "function then form", for
integration it's "access then leverage".
o Once you've slain the first dragon, the next devil appears. This is the nature order of things:
Can you say "ORBs"?
o Order separation of concerns followed by a high order state of affairs.
43. What do software development and car racing have in common?
o Your pole position (starting point) is a great indicator of final outcome.
o The type and condition of the track (infrastructure) dictates lap times.
o For pit stops, time to resolution (back on track) is the difference between finishing with
money or not. A stitch in time save nine.
44. What do architecture and life have in common?
o They both come with few guarantees.
45. What do architecture and music have in common?
o Pace and tempo are important.
46. What do architecture and standards have in common?
o The proof of the pudding is product, not prose. The great ones are found in practice, not in
books,
o For better or worse, the vagaries of the marketplace will always be the ultimate arbitrator.
47. What do solution sets and books have in common?
o The contents are important, not the size.
o How well does the solution address the problem? If it doesn't, the productivity is zero.
48. What do solution sets and people have in common?
o 1. The better they collaborate, the better the outcome.
o 2. They're all born to die. We all want to get to heaven but nobody wants to die.
49. What do systems and cars have in common?
o All good things must come to an end. Cars, systems, or technology, what’s the difference?
o When the monthly service costs are about the same as the new amortized replacement cost,
it's time to act.
o The old just ain't cutting it anymore, it's spending half its life in the shop and it works, but not
well, and tends to break down at the most inconvenient and critical times.
o Procrastination is all about wishful thinking, so know when to make the move.
o What about twenty year cost of ownership? Two choices: A new car every three years or
buy two and driven them into the ground. Option one costs ten times more than the two car
plan.
50. What do all economic, business and IT models (architecture) have in common?
o The systems structure is defined by key scarcity and abundance.
o The shift from scarcity to plenty is often the harbinger of new value propositions.
51. What do technology and bananas have in common?
o They come in colors, meaning shelf life. Some are green, yellow, brown, then black and if
you ignore them long enough they just go bad.
o Any given bunch of bananas has a natural order of colors. As time passes the color will
change and it's got a lot to do with shelf life.
52. What do sharks and architecture have in common?
o If they stop moving forward, you're dead.
53. What do IT and Telecom networks have in common?
o About 50% of the cost is just running the thing and dealing with growth.
54. What to dogs and servers have in common?
o When they're three years old they're having a mid life crisis.
55. What’s the The Golden Rule of Systems?
o Build something simple that models the real world and keep it that way.
56. What can architects learn from industrial engineering (Tailor)?
 o The biggest savings come from things you don't do.
o As it is with work design, so it is with system design: Poor aggregation and partitioning will
increase complexity which adversely affects the value proposition.
57. What can architects learn from Parato's?
o 20% of the application delivers 80% of the business value.
o 20% of the features and function of an application deliver 80% of the business value.
o All systems have an architecture, it's either implicit or explicit.

Origins of Software Architecture Study

Paul Clements
Software Engineering Institute

Brooks: The conceptual structure

In programming, the term architecture was first used to mean a description of a computer system that
applied equally to more than one actual system. In 1969, Fred Brooks and Ken Iverson called architecture
the "conceptual structure of a computer...as seen by the programmer". A few years later, Brooks (crediting
Gerald Blaauw for the term) defined architecture as "the complete and detailed specification of the user
interface. For a computer, this is the programming manual. For a compiler, it is the language manual... For
the entire system it is the union of the manuals the user must consult to do his entire job." A careful
distinction was drawn between architecture and implementation. Quoting Blaauw, Brooks writes, "Where
architecture tells what happens, implementation tells how it is made to happen." This distinction survives
today, and in the era of object-oriented programming it thrives.

Although the term architecture is still used today in some communities to refer to the user view of a system, it
isn't what is meant by software architecture, which refers to the structure of the system quite hidden from the
user. However, the notion of architecture as a common description of a class of systems -- i.e., an
abstraction, where all the instantiations are said to exhibit the architecture -- endures, and is at the heart of
the concept.

Dijkstra and Parnas: Structure matters

The study of software architecture is in large part a study of software structure that began in 1968 when
Edsger Dijkstra pointed out that it pays to be concerned with how software is partitioned and structured, as
opposed to simply programming so as to produce a correct result. Dijkstra was writing about an operating
system, and first put forth the notion of a layered structure, in which programs were grouped into layers, and
programs in one layer could only communicate with programs in adjoining layers. Dijkstra pointed out the
elegant conceptual integrity exhibited by such an organization, with the resulting gains in development and
maintenance ease.

David Parnas pressed this line of observation with his contributions concerning information-hiding modules
(1972), software structures (1974), and program families (1975).

A program family is a set of programs (not all of which necessarily have been or will ever be constructed) for
which it is profitable or useful to consider as a group. This avoids ambiguous concepts such as "similar
functionality" that sometimes arise when describing domains. For example, software engineering
environments and video games are not usually considered to be in the same domain, although they might be
considered members of the same program family in a discussion about tools that help build graphical user
interfaces, which both happen to use.

A program family can be enumerated in principle by specifying the decision tree that was or would be
traversed in order to arrive at each member of the family. The leaves of the tree represent fielded, executing
systems. The concept supports the notion of deriving a new member of the family from an extant one. The
procedure is to backtrack up the decision tree until a node (decision point) historically common to both is
reached, and then to proceed downward along the new path to derive the desired member. The concept also
supports the notion of deriving several members of the family from a common decision point, thus making
clear how each set of members resemble and differ from each other.
The point of the decision tree representation is to make clear the advantage of late binding and of prudently
ordering -- and recording -- one's design decisions. Early design decisions should be ones that will most
likely remain constant across members of the program family that one may reasonably expect to produce. In
the context of this discussion, an early design decision is the adoption of a particular architecture, as defined
below. Late decisions (near the leaves) in a prudently-structured decision tree should represent trivially-
changeable decisions, such as the values of compile-time or even load-time constants.

The significance of the program family concept to software architecture is that software architecture
embodies those decisions at or near the top of Parnas' program family decision tree.

All of the work in the field of software architecture may be seen as evolving towards a paradigm of software
development based on principles of architecture, and for exactly the same reasons given by Dijkstra and
Parnas: Structure is important, and getting the structure right carries benefits.

Meanwhile, back in the real world, maturing domains

In tandem with these important academic treatments of program and system structure came a long series of
practical experiences working with systems in several highly populated domains. Consider compilers.
Throughout the 1970's and 1980's, compiler design evolved from a series of distinct efforts, each one
innovative and unprecedented, into one with standard, codified pieces and interactions. Today, textbooks
about how to build a compiler abound, and the domain has matured to the point where no one today would
think for a moment of building a compiler from scratch, without re-using and exploiting the codified
experience of the hundreds of prior examples.

What exactly is re-used and exploited? Those decisions that are common to all compilers. Compiler writers
can talk meaningfully with each other about lexical scanners, parsers, syntax trees, attribute grammars,
target code generators, optimizers, and call graphs without even though the languages being compiled may
look nothing at all alike. So, for instance, two compilers may have completely different parsers; one may be
meticulously hand-written, the other may be automatically generated by a tool such as YACC. One may work
for LALR(1) grammars; the other may only accept finite state machine grammars. But what is common is that
both compilers have a component called a parser, which performs a function in both that (when viewed
under a simple abstraction) is exactly the same.

Many other domains now exist that, through practice and repetition and sharing among the many early
members of the family, now exhibit common structure, interconnection strategies, allocation of functionality to
components, component interfaces, and an overall justifying rationale. The study of software architecture can
be viewed as an ex post facto effort to provide a structured storehouse for this type of reusable family-wide
design information. Work in software architecture can be seen as attempting to codify the commonality
among members of a program family, so that the high-level design decisions inherent in each member of a
program family need not be re-invented, re-validated, and re-described.