How to Architect a Software System?

What is a Software Architecture?

There is no shortage of definitions of software architecture. There are even websites that maintain collections of definitions.

Perry and Wolf, 1992

Architecture is a set of architectural (or, if you will, design) elements that have a particular form. Perry and Wolf distinguish between processing elements, data elements, and connecting elements, and this taxonomy by and large persists through most other definitions and approaches. 

Boehm et al., 1995

A software system architecture comprises

• A collection of software and system components, connections, and constraints.
• A collection of system stakeholders' need statements.
• A rationale which demonstrates that the components, connections, and constraints define a system that, if implemented, would satisfy the collection of system stakeholders' need statements.

Clements et al., 1997

 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. 

IEEE 1471, 2000

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.

Philippe Kruchten, 2003

An architecture is the set of significant decisions about the organization of a software system, the selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these elements into progressively larger subsystems, and the architectural style that guides this organization -- these elements and their interfaces, their collaborations, and their composition.

Len Bass et al., 2003

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.

UML 1.5, 2003

Architecture is the organizational structure and associated behavior of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems.

James McGovern et al., 2004

The software architecture of a system or a collection of systems consists of all the important design decisions about the software structures and the interactions between those structures that comprise the systems. The design decisions support a desired set of qualities that the system should support to be successful. The design decisions provide a conceptual basis for system development, support, and maintenance.

 

Common Elements of All Definitions

Although the definitions are somewhat different, if you read carefully, you can see a large degree of commonality among these definitions, they are listed as follows:

• Architecture defines major components;
• Architecture defines component relationships (structures) and interactions;
• Architecture omits content information about components that does not pertain to their interactions;
• Behavior of components is a part of architecture insofar as it can be discerned from the point of view of another component;
• Every system has an architecture (even a system composed of one component);
• Architecture defines the reationale behind the components and the structure;
• Architecture definitions do not define what a component is;
• Architecture  is not a single structure - no single structure is the architecture.

 

The Definition I Like Most

The definition I like most is from IBM Rational. Based on extensive research, IBM Rational has established a definition of software architecture as follows.

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 elments;
• Composition of these structural and behavioral elements into larger subsystems;
• Architectural style that guides this organization.

The Thing That Software Architecture is NOT

The following lists are some misconceptions about software architecture:

• Architecture and design are the same thing
• Architecture and insfrastructure are the same thing
• Architecture is just structure
• Architecture is flat and one blueprint is enough
• Architecture cannot be measured or validated
• Architecture is Art or Science

Misconception: Architecture and design are the same thing

Architecture is design, but is not all of the design. Architecture is about making decisions on how the system will be built, it stops at the major abstractions, the major elements - the elements that are structurally important, but also those that have a more lasting impact on the performance, reliability, cost, and adaptability of the system. In constrast, design involves a lot more in order to take the design to implementation.

In a word, architecture is the fundamental, architecturally-significant aspects of the design.

Misconception: Architecture and infrastructure are the same thing

The infrastructure is an integral and important part of the architecture: It is the foundation. Choices of platform, operating systems, middleware, database, and so on, are major architectural choices.

Architecture must include the application architecture plus the infrastructure architecture.

Misconception: Architecture is just structure

Architecture is more than just the structural organization of design elements, it also includes the description of how these elements collaborate, as well as why things are the way they are (the rationale).

The architecture must describer how the architecture fits into the current business context and must address how it can be developed within the current development context.

Misconception: Architecture is flat and one blueprint is enough

Architecture is a complex beast; it is many things to many different stakeholders. Using a single blueprint to represent architecture results in an unintelligible semantic mess. Like building architects who have floor
plans, elevations, electrical cabling diagrams, and so on, we need multiple blueprints to address different concerns, and to express the separate but interdependent structures that exist in an architecture.

Misconception: Architecture cannot be measured or validated

Architecture is not just a whiteboard exercise that results in a few interconnected boxes and is then labeled a high-level design. The development of the architecture involves design, implmentation, testing, etc. There are
many aspects you can validate by inspection, systematic analysis, simulation, or modelization.

Misconception: Architecture is Art or Science

If there is a spectrum between art (creative) and science (prescriptive), architecture is somewhere in-between.

The architecture problem space is quite large. One of the reasons that architecture cannot yet be considered a science is that there are no good guidelines on how to traverse the solution space, "prune it", and then apply the selected solutions.

Architecture is becoming an engineering discipline (it is steadily moving toward the science end of the spectrum). Nevertheless, it is not a strict science because if you put two architect in seperate rooms, give them just the requirements, each will (most probably) come up with a different architecture. However, if you constrain them with a set of architectural patterns, their results will be more similar.