Software Architecture and Related Concerns

What is Software Architecture?

Software architecture is the set of decisions the software architect makes.

"What decisions does the software architect make?"

The architecturally significant ones.

"What is architecturally significant?"

The architect decides!

"A tautology!" you protest.

Ah, think about it, I counter.

Software architecture is commonly defined in terms of structural elements and relationships (see Definitions of Software Architecture). Structural elements are identified and assigned responsibilities that client elements interact with through "contracted" interfaces.
In creating architectures, we address

• system decomposition into structural elements, architectural components, subsystems, sub-assemblies, parts or "chunks" (Ulrich and Eppinger, 2004), paying attention to development productivity, and flexibility or extensibility requirements associated with accommodating future functionality at a reasonable cost of change. A good decomposition satisfies the principle of loose coupling between the pieces, facilitated by clean interfaces, simplifying the problem by dividing it into reasonably independent pieces that can be tackled separately.
• Once broken down into pieces, we need to ask:
  - Do we have all the necessary pieces? The structure must support the functionality or services required of the system. The dynamic behavior of the system must be taken into account when designing the architecture. We must also have the necessary infrastructure to support these services.
  - Do the pieces fit together? This is a matter of interface and relationships between the pieces, . But good fit—that is fit that maintains system integrity—also has to do with whether the system, when composed of the pieces, has the right properties. 
• cross-cutting concerns. We refer to broad-scoped qualities or properties of the system as cross-cutting concerns, because their impact is diffuse or systemic. It may be a matter of preferring not to isolate these concerns because the decomposition is being driven by other concerns, or it may be that no matter how you might “slice-and-dice” the system, multiple parts are going to have to collaborate to address these cross-cutting concerns. At any rate, to effectively address cross-cutting concerns, they must be approached first at a more broad-scoped level. Many system qualities (also known as non-functional requirements or system properties, often specified in service level agreements) are of this nature. To make the picture more complicated, the system qualities may conflict, so that trade-offs have to be made taking into account the relative priorities of the system qualities.

An architecture is not a simple flat view of the component topology, though an architecture diagram showing the components and relationships among them is a central thinking and communicating tool for the architects and the development team, and others they partner with. Our architecture needs to include:

• Meta-architecture: the architectural vision, style, principles, key communication and control mechanisms, and concepts that guide the team of architects in the creation of the architecture.
• architectural views: Just as building architectures are best envisioned in terms of a number of complementary views or models, so too are software architectures. In particular, structural views help document and communicate the architecture in terms of the components and their relationships, and are useful in assessing architectural qualities like extensibility. Behavioral views are useful in thinking through how the components interact to accomplish their assigned responsibilities and evaluating the impact of what-if scenarios on the architecture. Behavioral models are especially useful in assessing run-time qualities such as performance and security. Execution views help in evaluating physical distribution options and documenting and communicating decisions.

In creating these views, we pay attention to:

• architectural patterns: structural patterns such as layers and client/server, and mechanisms such as brokers and bridges.
• key architectural design principles including abstraction, separation of concerns, postponing decisions, and simplicity, and related techniques such as interface hiding and encapsulation.
• design of architectural mechanisms, where mechanisms deal with the interaction of components to achieve specific system capabilities. 
• system decomposition principles and good interface design.

What Software Architecture Is Not
Software architecture must be distinguished from lower-level design (e.g., design of component internals and algorithms) and implementation, on the one hand, and other kinds of related architectures, on the other. For instance, software architecture is not the information (or data) model, though it uses the information model to get type information for method signatures on interfaces, for example. It is also not the architecture of the physical system, including processors, networks, and the like, on which the software will run. However, it uses this information in evaluating the impact of architectural choices on system qualities such as performance and reliability. More obviously, perhaps, it is also not the hardware architecture of a product to be manufactured. While each of these other architectures typically have their own specialists leading their design, these architectures impact and are impacted by the software architecture, and where possible, should not be designed in isolation from one another. This is the domain of systemarchitecting. (As an interesting aside, our software architecting process has usefully been applied, without the software modeling specifics, to system, hardware and organization architecting.)
References

• Malan, Ruth and Dana Bredemeyer, Software Architecture: Central Concerns, Key Decisions (.pdf, 124kb, May 2002.
• Malan, Ruth and Dana Bredemeyer, "Less is More with Minimalist Architecture" (MinimalistArchitecture.PDF, 47 kb), draft of the paper to be published in IEEE's IT Professional, September/October 2002. © 2002 IEEE. 2002 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.
• Malan, Ruth, Modularity and what we can learn from Trek, posted to A Trace in the Sand blog, June 20, 2006.
• Ulrich, Karl and Stephen Eppinger, Product Design and Development, McGraw-Hill, 2004.

Restrictions on Use: All material that is copyrighted by Bredemeyer Consulting and published on any pages of our site, may be downloaded and printed for personal use. If you wish to quote or paraphrase fragments of our work in another publication or web site, please properly acknowledge us as the source, with appropriate reference to the article or web page used. If you wish to republish any of our work, in any medium, you must get written permission from the lead author (in this case, Ruth Malan). Also, any commercial use must be authorized in writing by Bredemeyer Consulting.