Papers and Books

Architecture Paradox

Subbu 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. A sequel to this paper also presents some of the author's early ideas on how to defy this paradox and develop long-lasting and evolutionary self-supporting architectures.

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."

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

Architecture Paradox: Survival vs Evolution
Figure 1: Architecture Paradox: Survival vs Evolution

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? A sequel to this article will attempt to answer these questions.

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 [5] 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. A sequel to this article will address an approach to solve this paradox.

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. 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.

© Subbu Allamaraju 1998, 1999. All rights reserved.

All copyrights and trademarks acknowledged.