What is Software Architecture? (.pdf)

Definitions of Software Architecture

What Software Architecture is Not

Join our
mailing list

Architecture Training

Software Architecture Class

Enterprise Architecture Workshop

Role of the Architect Workshop

Architecture Consulting

Consulting Services Overview

Any well-designed system has parts that interact in subsystems, which work together to contribute to the larger purposes of the system. Animals have circulatory systems, composed of a heart, arteries, and veins. These parts collaborate closely in the circulatory system, but also interact with other subsystems: digestive, nervous, motor, sensory, and so on. Of course, such a system was not architected in the traditional sense. But complex physical systems have long had discrete parts which are combined to form larger separable entities, with composite interactions that together deliver on the system goals. For example, vehicles have subsystems (breaking, transmission, engine, etc.), composed of parts (spark plug, piston, crankshaft, and so on). The patterns here have been so long understood, we do not even talk about them as patterns.

Over time, architects see patterns in the way that systems are structured, and as these patterns become widespread in an industry, they become dominant designs. The differences among cars, for example, has little to do with gross structure for all have pretty much the same subsystems and parts, each performing well-understood functions. Differentiation, in such a world, focuses on qualities of the system. The architect is now freed from concentrating on the gross decomposition of functionality, and the emphasis shifts to achieving the qualities that will set this model apart from others. Tradeoffs have to be made across the parts to achieve the qualities and overall system integrity within the production and operating cost goals set for the system.

In the software world, we are still working on both frontiers: the problem of how to decompose the system into parts and how to accomplish the system properties. Architectural patterns are emerging to address these areas: structural patterns such as layers address gross system decomposition concerns. 3-tier and 5-tier (layered) architectures have become prevalent within IT and product areas alike. Within application domains, we are seeing these structural patterns becoming more tuned to the application area, with components, not just layer abstractions, emerging as common elements across architectures. We are also seeing patterns emerging for mechanism design, where mechanisms deal with the interaction of components to achieve specific system capabilities.   

References

• See Architecture and Design Patterns Books 
• See also Christopher Alexander's patterns work in the building architecture area. This work inspired the software architecture patterns work.
• Grady Booch's Software Architecture Handbook (work-in-progress) site has an extensive classification of patterns. See http://www.booch.com/architecture/patterns.jsp?view=kind_name%20catalog. You will need to log in to view this page.
• Microsoft has also been working on a patterns classification. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/entarch.asp
• Malan, Ruth and Dana Bredemeyer, Software Architecture: Central Concerns, Key Decisions (.pdf, 124kb), May 2002.
• Malan, Ruth and Dana Bredemeyer, Conceptual Architecture Action Guide, http://www.bredemeyer.com/pdf_files/ActionGuides/ConceptualArchitectureActionGuide.PDF, April 2005.