Software Architecture Definition?

When I was a student in the MIT Systems Design and Management Program, I had to take a course titled “Systems Architecture”. The course was about overall systems and not specifically on software. In that course, there was a paper I read that forever shaped my view on what software architecture should be. The paper is titled “A Taxomony of Decomposition Strategies Based on Structures, Behaviors, and Goals” by Phillip J. Koopman (DE-Vol. 83, 1995 Design Engineering Technical Conferences, Volume 2, ASME 1995). In this paper, Koopman describes architecture as containing structures, behaviors, and goals along with a variety of decomposition strategies. In my own work in software architecture, I find that I must tie my structure and behavior specifications to business goals and when I don’t have all three pieces, my architecture often doesn’t withstand the rigors of peer review from a wide audience.

How does this definition of architecture components stand up to other definitions? The standard on software architecture - IEEE 1471-2000 - says
Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

The standard defines the following bold terms:

A system is a collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. A system exists to fulfill one or more missions in its environment. [IEEE 1471]

The environment, or context, determines the setting and circumstances of developmental, operational, political, and other influences upon that system. [IEEE 1471]

A mission is a use or operation for which a system is intended by one or more stakeholders to meet some set of objectives. [IEEE 1471]

A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. [IEEE 1471]

This definitions correlates to Koopmans article in the following ways: the goals of the architecture are the mission; the behavior maps to the relationships and the principles, and the structure maps to the fundamental organization.

In practice I see many designs that show mapping and decomposition with behavior and structure (think UML class diagrams and sequence diagrams) or a mapping between goals and behavior (UML Use Cases and Sequence Diagrams) but very architecture artifacts that successfully map all three.

I will be looking at other definitions of architecture in future blog posts.