Software architecture is a process; a sequence of strategic design decisions mapping specification and business goals to architecture design, and a thing; a set of views produced by the process that address different stakeholders, Michael Stal states describing how to define a software architecture.
For Stal, a professor in software engineering working as principal engineer at Siemens, the goal of an architecture is to create the backbone for an implementation. He believes that earlier proposed definitions often have been vague with a focus on cooperating components. Instead he thinks we should think about properties and adds nine more properties to complete his list.
Every software-intensive system reveals a software architecture. Stale claims there is always an architecture at hand, even though it sometimes is based on ad-hoc decisions. What for him is needed is a systematic architecture design driven by well-defined, prioritized and relevant requirements as well as risks.
There are two kinds of architecture quality. External quality defining the visible behavior as required by quality attributes and internal quality defining adoption of properties like simplicity and expressiveness by e.g. developers.
A consistent set of guidelines and tools must guide the architecture design. This is for Stal necessary to achieve high quality. Guidelines help in avoiding the architecture to become bloated with patterns and technologies reducing internal quality.
Software architecture as a thing is a means for communicating design decisions. All architectural decisions must be made explicit and described in accordance with different stakeholder’s roles and responsibilities. An architecture is also a base for the design and defines an initial skeleton for the code base.
Software architecture must cover both problem domain and solution domain. Stal notes that this infers that a multi-tier design is not an architecture. He also notes that to avoid a monolithic design both domains should be structured into subdomains and the organization of software architecture activities driven by these subdomains, not by the organization, and refers to Conway’s law.
Stal’s final four properties deal with how an architecture design spans the whole lifecycle of a system, how an architecture design must follow a test-driven approach, that an architecture must be kept separately from its environment, and that an architecture may also define a system of systems within a domain.
In a conversation with InfoQ Stefan Tilkov thinks that Stal’s post is great but Tilkov notes he doesn’t necessarily see architecture as a process separate from development, instead he think of it as a function of project and organization size. He also notes that contrary to ideas that views architecture “as a description of the system or the system’s intended form”, for him architecture is “something the system has”, regardless of how it has been created.