BOX 3.1

Software Architecture

Software system architecture is conventionally defined as the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationship among them. In essence, architecture is the set of organizing principles, both structural and semantic, that constrain the ways by which software elements of a system interact. A well-conceived software architecture can facilitate separation among work assignments allocated to software developers because it defines key elements of the “contracts” that regulate the intended connections among software elements.

Architectural commitments for a software system have implications throughout the lifecycle of the system. Architectural commitments can predict critical quality attributes related to performance, security, reliability, and other “non-functional” properties. As a consequence, architectural decisions are among the most important first decisions program managers and stakeholders make yet the most difficult to change or correct.

The committee’s definition of software architectures includes more than just structural considerations relating to which components may interact with which other components through what kinds of “connectors.”1 Semantic architectural commitments may relate to protocols, data representation invariants, exceptional flow of control, timing properties and deadlines, concurrency and threading, pattern compliance, and other attributes. This combination of structural and semantic commitments is of benefit when


1 David Garlan, 2003, “Formal Modeling and Analysis of Software Architecture: Components, Connectors, and Events” in Formal Methods for Software Architectures, Pp. 1-24 in Formal Methods for Software Architectures, Marco Bernardo and Paola Inverardi, eds., Berlin: Springer Publishers.

contain many innovative elements, as do some DoD business systems. Nevertheless, there are very often large spans of functionality that are precedented. This means the overall system architecture is likely to include a mix of precedented and innovative structures.

In modern systems, the concept of “architecture” has broadened to include not only structural commitments (as noted in the definition at the start of this chapter), but also other design commitments that constrain and guide subsidiary design decisions, particularly decisions regarding how components of the system are meant to interact with other components. Architecture commitments open or close opportunities for future evolution and enhancement. In other words, it is risky if not impossible to evaluate different alternatives or different vendors without an understanding of the architectures implicit in what they propose.

In particular, modern software ecosystems have a set of architectural commitments at their core. Web services, for example, are structured in conventional ways with well-defined software interfaces among the components and, additionally, a number of “rules of the road” regarding what are appropriate interactions across those interfaces (examples shown in Chapter 1). Another example is modern data-intensive computing, such as done extensively at companies such as Google and Yahoo!. Much of this data-intensive computing activity shares a single relatively simple system architecture concept, called MapReduce, which is designed to address the challenges of distributed computing with enormous amounts of data. The MapReduce concept has turned out to be applicable to a very wide range of problems, with the result that there is now a growing community of users for a “big data” ecosystem focused around a set of open-source tools.7 Despite the technical simplicity of the MapReduce meta-


Hadoop, Zookeeper, HDFS and MapReduce at Apache are explained further online at

The National Academies of Sciences, Engineering, and Medicine
500 Fifth St. N.W. | Washington, D.C. 20001

Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement