Architecture Mechanisms



Len Bass

Rick Kazman

Mark H. Klein

This library item is related to the following area(s) of work:

Software Architecture

This article was originally published in News at SEI on: March 1, 2001

Architecture mechanisms—ensembles consisting of a small number of component and connector types—allow designers to explore and document relationships between software architectural styles and quality attributes. This enables designers to identify choices they must make in the pursuit of quality attribute goals. Study of these mechanisms can also help set a foundation for further software architecture design and analysis.


Over the past 30 years, a number of researchers and practitioners have examined how systems affect software quality attributes. However, no one has systematically and completely documented the relationship between software architecture and quality attributes.

The lack of documentation stems from several causes:

  • The lack of a precise definition for many quality attributes inhibits the exploration process. While attributes such as reliability, availability and performance have been studied for years and have generally accepted definitions, other attributes, such as modifiability, security, and usability, do not have generally accepted definitions.
  • Attributes are not discrete or isolated. For example, availability is an attribute in its own right. However, it is also a subset of security (because it can be affected by denial-of-service attacks) and usability (because users require maximum uptime). Is portability a subset of modifiability or an attribute in its own right? Both relationships exist in quality attribute taxonomies.
  • Attribute analysis does not lend itself to standardization. There are hundreds of patterns at different levels of granularity, with different relationships among them. As a result, it is difficult to decide which situations or patterns to analyze for what quality, much less to categorize and store that information for reuse.
  • Analysis techniques are specific to a particular attribute. Therefore, it is difficult to understand how the various attribute-specific analyses interact.

Notwithstanding the difficulties, systematically codifying the relationship between architecture and quality attributes has several obvious benefits, including:

  • a greatly enhanced design process—for both generation and analysis
  • during design generation, a designer could reuse existing analyses and determine tradeoffs explicitly rather than on an ad hoc basis. Experienced designers do this intuitively but even they would benefit from codified experience. For example, during analysis, designers could recognize a codified structure and immediately know its impact on quality attributes.
  • a method for manually or dynamically reconfiguring architectures to provide specified levels of a quality attribute. Understanding the impact of quality attributes on architectural mechanisms will enable designers to replace one set of mechanisms for another when necessary.
  • the potential for third-party certification of components and component frameworks. Once the relationship between architecture and quality attributes is codified, it is possible to construct a testing protocol that will enable third-party certification.

For all these reasons, the idea of documenting the relationship between architecture and quality attributes is a worthy goal.

A universally accepted premise of the software architecture community is that architecture determines attributes. This raises several questions:

  • Is this premise true and why do we believe that quality attribute behavior and architecture are so intrinsically related?
  • Can we pinpoint key architectural decisions that affect specific quality attributes?
  • Can we understand how architectural decisions serve as focal points for tradeoffs between several quality attributes?

The concept of an architecture mechanism allows us to address these questions. An architecture mechanism is an ensemble consisting of a small number of component and connector types. It significantly affects quality attribute behavior and has sufficient content for analysis.

For example, encapsulation is a mechanism for achieving modifiability. Replication is a mechanism for achieving reliability. We contend that these architectural mechanisms are design primitives. They allow designers to explore and document the relationship between software architectural styles and quality attributes. At this point, we believe that there are fewer than 10 mechanism types per quality attribute.

By codifying mechanisms, designers can also identify the choices necessary for achieving quality attribute goals. This, in turn, will set a foundation for further software architecture design and analysis. In fact, this work was motivated by the need for such foundations for use in the Architecture Tradeoff Analysis Method (ATAM) and the Attribute-Driven Design (ADD) method (see Architecture Based Design Method).

Of course, there are many challenges. One challenge is identifying the correct collection of mechanisms at the proper level of abstraction. Another is understanding how to combine mechanisms into styles and styles into systems, while combining the analyses associated with each.

Architecture Mechanisms

Architecture mechanisms directly contribute to quality attributes. Examples of architecture mechanisms are data routers, caching, and fixed-priority scheduling. These mechanisms help achieve specific quality attribute goals as defined by general scenarios:

  • Data routers protect producers from additions and changes by consumers, and vice versa, by limiting the knowledge that producers and consumers have of each other. This affects or contributes to modifiability.
  • Caching reduces response time by providing a copy of the data close to the function that needs it. This contributes to performance.
  • Fixed-priority scheduling allows the interleaving of multiple tasks to control response time. This contributes to performance.

Each mechanism is implemented by a small number of components and connector types. Each is targeted at one or more quality attributes and uses a single strategy for achieving these attributes. For example, the data router uses indirection to achieve modifiability. Caching uses replication to achieve performance. Fixed-priority scheduling uses preemptive scheduling to achieve performance.

In essence, architecture mechanisms are the design primitives for achieving quality attribute behavior in a system.An architecture mechanism may be an existing pattern or style. The goal of our work is to identify the specific design primitives that elicit quality attributes, and to then analyze those primitives from the point of view of multiple quality attributes.

For example, a client–server is an architecture mechanism. It supports modifiability by enabling additional clients (up to a point). However, it can also support performance by bringing computation closer to the user.

As you can see, we can easily extend the list of mechanisms and general scenarios to address a wide range of situations. If we introduce a new general scenario, we may need to introduce new mechanisms that contribute to it. Alternatively, we may discover new mechanisms for dealing with existing general scenarios. In either case, we can describe the new mechanism without affecting any other mechanism. This allows us to introduce new design primitives into our analysis incrementally.

Levels of Abstraction for Mechanisms

Mechanisms exist in a hierarchy of abstraction levels. For example, separation is a mechanism that divides two coherent entities. This represents a high level of abstraction. A more concrete mechanism, at a lower level of abstraction, would specify entities, such as separating data from function, function from function, or data from data. Increasing detail also increases the precision of our analysis. However, for purposes of establishing design primitives, our goal is to determine the highest level of abstraction that still supports some useful analysis.

What qualifies as an analysis? Earlier we stated that an architecture mechanism helps achieve quality attribute goals. There must be a reason why the mechanism supports those goals. Articulating the reason becomes the basis for our analysis. If we cannot state why a particular collection of component and connector types supports a quality attribute goal, then the collection does not qualify as a mechanism.

Choosing the correct level of granularity addresses the proliferation of architectural design patterns, and overcomes the third problem preventing the relationship between structure and quality attributes from being codified.

Desired Attribute and Side Effects

Earlier we stated that mechanisms have two consequences: they help particular general scenarios achieve quality attributes and they can influence other general scenarios as a side effect. Given two consequences, we need two types of analysis. The first analysis will explain how the architecture mechanism helped the intended general scenario achieve its result. The second analysis describes how to refine the general scenario in light of the information provided by the mechanism. This analysis reveals side effects the mechanism has on the other general scenarios. By referring to a mechanism that directly affects that attribute, we can perform a more detailed analysis of the side effect.

Let’s use encapsulation again as our example. We will analyze the modifiability general scenarios that reflect changes in function, environment, or platform. Our analysis states that as long as changes occur inside the encapsulated function (that is, as long as they are hidden by an interface), the effect of these changes will be limited. If the expected changes cross the encapsulation boundary, the effect of the changes is not limited.

The analysis/refinement for the performance general scenarios asks whether encapsulation significantly affects resource usage of the encapsulated component.

The analysis/refinement for the reliability/availability general scenarios asks whether encapsulation significantly affects the probability of failure of the encapsulated component. A more detailed description of the performance or reliability analyses would be found in appropriate performance or reliability mechanism writeups.

Figure 1 shows the relationship between mechanisms and general scenarios. If mechanisms are across the top, and general scenarios are down the left side, then each cell has one of three possibilities.

  1. The mechanism contributes to this general scenario
  2. the mechanism has no affect on the general scenario
  3. the mechanism introduces side effects—questions to be answered by other mechanisms


Mechanism 1


Mechanism N

General Scenario 1


Side effect

Does not apply

Side effect


Does not apply






Side effect


Side effect






General Scenario N

Side effect





Figure 1: Relationship Between Mechanisms and General Scenarios

When describing the analyses to be performed, we group the general scenarios into attribute headings. Thus, in the mechanism template there are sections entitled modifiability, reliability/availability, performance, security, and usability. One or more of these is the attribute that the mechanism is intended to address. These are listed beside the attributes that are side effects of the mechanism.

Mechanisms and ABASs

Attribute-Based Architectural Styles (ABASs) associate classes of architectures with attribute-specific analysis. Architectural mechanisms are quality attribute design primitives. Therefore, we should be able to discuss ABASs in terms of architecture mechanisms. Consider the following examples.

  • The publish/subscribe modifiability ABAS consists of the router and registration mechanisms.
  • The tri-modular redundancy (TMR) reliability ABAS consists of the (functional) redundancy and (majority) voting mechanisms.
  • The SimplexTM reliability ABAS consists of the (analytic) redundancy and (rule-based) voting mechanisms.

While we intend to explore the relationship between ABASs and mechanisms in the future, we can make several observations right now. Both mechanisms and ABASs are attribute-specific design building blocks containing architectural as well as analysis information.

However, ABASs are "bigger" and more concrete than mechanisms. In the above examples, ABASs comprise more than one mechanism. Yet the type of redundancy and voting mechanisms used by TMR are different from those used by Simplex. Mechanisms, by comparison, are intended to be design primitives and should be indivisible.

The Future of Mechanisms

The work on mechanisms at the Software Engineering Institute (SEI) is a natural outgrowth of previous work on the Architecture Tradeoff Analysis Method and ABASs. We will, over the next few months, be publishing a technical note and eventually a larger report describing a large set of architecture mechanisms and detailing their uses.

We are looking for reviewers, contributors, and users from the industrial and governmental architecture community to aid us in the process of creating and validating a useful and used collection of mechanisms.

About the Authors

Len Bass is a senior member of the technical staff at the Software Engineering Institute of Carnegie Mellon University (CMU). He has written or edited six books and numerous papers in a wide variety of areas of computer science including software engineering, human-computer interaction, databases, operating systems, and theory of computation. His most recent book Software Architecture in Practice (co-authored with Paul Clements and Rick Kazman) received the Software Development Magazine's Productivity Award. He was the primary author of the Serpent User Interface Management System, which was widely cited for its innovativeness and influence. He organized a group that defined a user-interface software reference model that is an industry standard, and headed a group that developed a software architecture for flight training simulators that has been adopted as a standard by the U.S. Air Force. He also headed a group that developed a technique for evaluating software architectures for modifiability. He is currently working on techniques for the analysis of software architectures, and techniques for the development of software architectures for product lines of systems. He is working to understand how to achieve usability through software architecture and has recently been involved in several applications involving mobile computers including wearables and automotive computers. He is the representative of the ACM to the International Federation of Information Processing technical committee on Software: Theory and Practice. Before joining CMU in 1986, he was professor and chair of the Computer Science Department at the University of Rhode Island. He received his Ph.D. in computer science in 1970 from Purdue University.

<Mark Klein is a senior member of the technical staff at the SEI, where he is a technical lead in the Architecture Tradeoff Analysis Initiative. He has more than 20 years of experience in research and technology transition on various facets of software engineering and real-time systems. Klein’s most recent work focuses on the analysis of software architectures. His work in real-time systems involved the development of rate monotonic analysis (RMA), the extension of the theoretical basis for RMA, and its application to realistic systems. He has co-authored many papers and is a co-author of the RMA Handbook, titled A Practitioner’s Handbook for Real-Time Analysis: Guide to Rate Monotonic Analysis for Real-time Systems.

Rick Kazman is a senior member of the technical staff at the SEI, where he is a technical lead in the Architecture Tradeoff Analysis Initiative. He is also an adjunct professor at the Universities of Waterloo and Toronto. His primary research interests within software engineering are software architecture, design tools, and software visualization. He is the author of more than 50 papers and co-author of several books, including a book recently published by Addison-Wesley titled Software Architecture in Practice. Kazman received a BA and MMath from the University of Waterloo, an MA from York University, and a PhD from Carnegie Mellon University.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.