What is Software Architecture?

While the science associated with Software Architecture is an emerging discipline in the software industry, there is little debate about the nature of its importance. The following quote from the Software Engineering Institute (SEI) makes the case loud and clear (http://www.sei.cmu.edu/architecture/index.html):

1. Software architecture forms the backbone for any successful software-intensive system.


2. An architecture is the primary carrier of a software system's quality attributes such as performance or reliability.


3. The right architecture - correctly designed to meet its quality attribute requirements, clearly documented, and conscientiously evaluated - is the linchpin for software project success.


4. The wrong one is a recipe for guaranteed disaster.

What is Software Architecture?

But what exactly is meant by "Architecture" in the software field? The concept has been around for a couple of decades at this point, and absent a formal definition, I think we can rally around the central themes embodied in the following "authoritative" sources:

IEEE

“Architecture is 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.” [IEEE 1471]

IEEE Computer Society, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems: IEEE Std 1472000. 2000.

Grady Booch, Philip Krutchen, Kurt Bittner, and Rich Reitman

Software Architecture encompasses the set of significant decisions about the organization of a software system:

• Selection of the structural elements and their interfaces, by which a system is composed
• Behavior as specified in collaborations among those elements
• Composition of these structural and behavioral elements into larger subsystems
• Architectural style that guides this organization

G. Booch, P. Krutchen, K. Bittner and R. Reitman. The Rational Unified Process — AnIntroduction. 1999. Definition derived from Mary Shaw’s definition presented in 1995 at theFirst International Workshop on Architectures for Software Systems.

Len Bass (SEI)

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

Bass, Len; Clements, Paul; & Kazman, Rick. Software Architecture in Practice, Second Edition. Boston, MA: Addison-Wesley, 2003.

Studying each of these definitions, we see several themes echoed repeatedely. The architecture of a software-intensive system consists of three cooperative elements: 1) The Structure - a static dimension illustrating the partitioning of responsibilities among subsystems, 2) The Behavior - a dynamic dimension representing the relationships and interactions among those structures, and 3) The Style - the principles and guidelines that motivated the structure - and should continue to do so.

What Does Architecture Consist Of?

Let's take a very high-level look at each of these elements and consider a very simple example. For additional insight, I'd encourage digging into one or more of the many excellent publications on the topic. I've listed a few of my favorites at the end of this post.

The Structure

The structural elements of the architecture capture the static set of subsystems/components that make up the system as well as the responsibilities of these subsytems and their organization into larger subsystems. An important consideration in this dimension is the dependencies between components and on other/external systems. The organization of the architecture at this level and from this perspective is also important from the standpoint of coordinating work effort and planning a project. It is frequently the case that a project team is organized around this structure - different teams responsible for delivery of different subsystems. This consistency between product architecture and "project team architecture" provides considerable value in planning and managing a development effort.
The diagram above captures at a grossly high level part of the static dimension of a theoretical e-commerce application that accepts credit cards. Capturing and articulating the architecture from this point of view helps to establish the context of the system and provide a frame of reference for decision making.

The Behavior

The behavioral dimension represents the ways in which the subsystems or components interact to fulfill the system requirements. A diagram such as the following represents the "messages" flowing between the components of the same hypothetical e-commerce system referenced above.

In this scenario, we can follow the system in operation as the Shopping Cart collects credit card data from the Consumer and uses the Customer Management System to get additional information from the consumers profile. With that data, a payment instruction is dispatched to the Card Gateway that leverages the Third Party Processor to execute the payment. After the payment transaction is complete, the Shopping Cart records the payment information in the Payment Management System.

The Style

Overall, the style dimension captures the principles and patterns that motivated the structure and behavior of the architecture. In some ways, the style is analogous to that of architectural style in building architecture (e.g., Roman, Gothic, Victorian, etc). This includes concepts such as architectural patterns, technical principles such as rpc and idempotency mechanisms, and values such as simplicity of design.

The style dimension effectively sets forth a vocabulary and a collection of guidelines and constraints - boundaries, if you will - that encourage effective decision making and clarify communication about the architecture. It's essential this dimension be explicity represented, as future evolution of the product depends on understanding the factors that influenced the existing architecture.

How is Architecture Communicated?

There are many ways to capture these key dimensions. The "4+1 Views" promoted by the Rational Unified Process and Phillipe Krutchen (http://www.win.tue.nl/~mchaudro/sa2004/Kruchten4+1.pdf) is a common approach. More on that another day.

It's important to note that in whatever way the architecture is conceived and communicated, it is the responsibility of the architect (What is A Software Architect) or a team of architects to drive the towards conclusion, constantly navigating the murky waters, balancing the many competing stakeholder needs, and rallying the team around the "right" decisions. The future of the product depends on successful accomplishment of this mission.

In an influencial work a decade ago, Mary Shaw and David Garlan put it as follows, and I think many of us can attest to the truth of this statement:

"The software architecture you marry in haste will be there for you to repent at liesure."

Let's do what we can to get it right :-)

Suggested Reading

1. Kruchten, Phillipe B., The 4+1 View Model of Architecture, IEEE Software, vol. 12, no. 6, November 1995


2. Bass, Len; Clements, Paul; & Kazman, Rick. Software Architecture in Practice, Second Edition. Boston, MA: Addison-Wesley, 2003. (Software Architecture in Practice, Second Edition)


3. Clements, Paul; Bachmann, Felix; Bass, Len; Garlan, David; Ivers, James;; Little, Reed; Nord, Robert; Stafford, Judith. Documenting Software Architectures: Views and Beyond. Boston, MA: Addison-Wesley, 2002. (Documenting Software Architectures: Views and Beyond)


4. Fowler, Martin. Patterns of Enterprise Application Architecture. Boston, MA: Addison-Wesley, 2002. (Patterns of Enterprise Application Architecture)


5. Shaw, Mary; Garlan, David. Software Architecture; Perspectives on an Emerging Discipline. New Jersey: Prentice-Hall, 1996. (Software Architecture: Perspectives on an Emerging Discipline)