Just what is “Architecture”?

[1] are struggling to apply Agile techniques to enterprise-level systems, systems of systems, and the enterprise architecture in general. Dean Leffingwell’s work^[2] provides some guidance, but only to a point. Leffingwell’s work is not flawed, but reflects issues that are the result of deep-seated misconceptions about just what architecture is when discussing software-based systems. Technical architects are often accused of being overly focused on definitions of terms. While this is largely true, it is a response to situations such as this in which definitions are not clear and people talk past one another.

The root of the problem lies in one of the core principles of Agile development, as given in the Agile Manifesto^[3]:

“The best architectures, requirements, and designs emerge from self-organizing teams.”

On the surface, there is nothing wrong with this statement, but things usually go wrong with its implementation. The statement implies that the architecture of a software system is fluid, that it evolves over time and emerges from development, and that the development team has considerable choice in the matter of the architecture. The statement also creates an implication that any up-front architectural work is bad and should be avoided. Both of these implications are the result of misperceptions about just what architecture is, especially when applied to a software-based system.

To understand where these misperceptions originate, one must explore the many definitions of software architecture that have been published in just the last decade. Rozanski and Woods, inSoftware Systems Architecture, ^[4] provide the following definition:

The architecture of a system is the set of fundamental concepts or properties of the system in its environment, embodied in it elements, relationships, and the principles of its design and evolution.

The folks at the Software Engineering Institute, Len Bass, et al, provide this definition from Software Architecture in Practice^[5]:

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

The IEEE, standard 1471-2000 (IEEE, 2000)^[6] (later adopted as ISO/ICE 42010:2011) has this definition:

The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.

In his PhD dissertation, Roy Fielding, the inventor of the Representational State Transfer architecture ^[7] (REST) currently popular among web services developers, provides two definitions, one static and one dynamic:

(Dynamic) A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.
(Static) A software architecture is defined by a configuration of architectural elements–components, connectors, and data–constrained in their relationships in order to achieve a desired set of architectural properties.

Most of these definitions share a common pattern: They define architecture in terms of a structure or organization of components, not in terms of the components themselves. For some reason, this is often lost on users of these definitions, who tend to focus on the set of components, not the structure they form. For example, in (Leffingwell, 2007), Barry Boehm and Richard Turner^[8] are quoted as describing software architecture as, in part:

A collection of software and system components, connectors, and constraints;

In this description, the focus on the components rather than the structure they form is stark. This view seems to pervade the Agile literature and thinking. The set of components is a manifestation of the architecture, not the architecture itself. The component set will indeed evolve as development progresses, while the architecture will likely not vary much if at all. Technology platform decisions map specific products into various components, and these decisions will affect components that lie in the vicinity. This is not architecture, either.

When the Iasa Board of Education first set out to define a curriculum for software architecture, we noted both the striking similarities and the differences among the various definitions. We could not create a curriculum based on this set, so we set out to summarize and combine them. A quick look through the definitions above give some insight into the ensuing debates. Fielding’s definition led us to the notion of a dominant structure as the central theme for architecture. Fielding says that a software system can have more than one architecture, and may have several. He allows for one software architecture while at rest and multiple software architectures when running. This is counterintuitive: How can any structure have more than one architecture at a time? To address this, we went back to our favorite analogy: Building architecture.

No matter what else is true about a building, it has only one overarching architecture. The specifics of that architecture may be up for debate, but in relation to buildings, there is an assumption that one architecture defines the building. If true, we must be able to identify the essential characteristics that determine that overarching architecture. Upon examination, we find that the various components of a building form a dominant structure or pattern that determines the overall architecture. Could this be true of software-based systems as well? Indeed, it is.

After some serious debate, the Iasa team created this definition^[9]:

A software architecture describes the dominant structure formed by the software components of a system and their elements, their functional and non-functional properties, and the connections between them.

The set of components of a software-based system form a structure whose pattern leads to the overarching architecture of the system as a whole. This pattern is formed well before the set of components is final, and well before any technology choices are made. The pattern is usually discovered rather than designed as it tends to be driven by the non-functional characteristics of the problem being solved^[10]. It turns out this pattern is often established during the very first conversations among owners and developers as they address two questions: “So, what are we facing, and how do we start?” Further, once this pattern is established, it is very hard to change.

For example, once the decision is made to use a central data store (be it a database, set of flat files, a noSQL tool, or just a chunk of memory), the basic pattern of the system has been defined. A central data store is the defining feature of the blackboard pattern^[11]. Once anything has been implemented according to this pattern, changing to a micro-kernel or pipes-and-filters pattern is much more difficult than a matter of refactoring.

Most web-based application today follow a similar pattern of a layer of web servers that serve up HTML, a layer of application servers to handle the application logic, and a layer of data servers to serve up data and content. While the details within each of these layers can vary greatly, the basic pattern of layers usually remains intact. Even if the specific layers change, the layers pattern does not. The very name “n-tier” in fact describes a set of layers.

Once we accept that the architecture of a system is the structure formed by the components rather than the actual set of components, many of the issues with applying Agile techniques fall away. What goes into an “architectural runway,” as defined by Leffingwell, becomes clearer as well. These details are the topic for another story.

Bibliography

Bass, L., Clements, P., & Kazman, R. (2003). Software Architecture in Practice, 2ed. Upper Saddle River, NJ, USA: Addison-Wesley.
Boehm, B., & Turner, R. (2004). Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA, USA: Addison-Wesley.
Buschmann, F., Munier, R., Rohnert, H., Sommerlad, P., & Stal, M. (1996). Pattern-Oriented Software Architecture Volume 1: A System of Patterns (Vol. 1). New York, NY, USA: John Wiley & Sons.
Fielding, R. (2000). Architectural Styles and the Design of Network-based Software Architectures (Dissertation). University of California, Irvine, Information and Computer Science. Irvine: University of California, Irvine.
IASA Board of Education. (2008). Software Architecture Course Curriculum. IASA Board of Education. Austin: IASA.
IEEE. (2000). IEEE Std 1471-2000. Piscataway, NJ, USA: IEEE.
Leffingwell, D. (2007). Scaling Software Agility. Upper Saddle River, NJ, USA: Addison-Wesley.
Rozanski, N., & Woods, E. (2011). Software Systems Architecture, 2ed. Upper Saddle River, NJ, USA: Addison-Wesley.
 
Scott A. Whitmire