Papers and Books

Architecture Paradox - Solutions

Subbu Allamaraju

Introduction

The first part of this paper identifies that a software system faces two challenges: survival and evolution, which lead to the architecture paradox. It also identifies that, a software's ability to survive and evolve (without loss of the other) depends on its structure as represented by its architecture.

In this paper, the author presents some of his 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 stages the architect must undertake in designing an architecture, and the rationale behind these.

Rationale

The rationale behind the solution is as follows.

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 [1].

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 [2] 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. Particularly, technologies (such as Enterprise JavaBeans) that allow component-level reflection between components help achieving certain amount of integration of principles.

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

How to build resilient architectures that are not trapped in the architecture paradox? This is the focus of this paper. 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 are not immediate.

References

  1. Jim Doble (1997): Change Resilience Patterns in Software Architecture and Design, OOPSLA '97 Workshop on Exploring Large System Issues, http://www.ccsi.com/~brr/doble.html.

  2. Grady Booch (1994): Object Oriented Analysis and Design with Applications (2nd Edition), Addison-Wesley, Reading, Massachusetts.

© Subbu Allamaraju 1998, 1999. All rights reserved.

All copyrights and trademarks acknowledged.