Architecture Paradox

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.