The Discipline:

Architects (who)

Architecting (how)

Architecture (what)

Motivation (why)

Organization (where)

Lifecyle (when)

Requisite Variety Blog


We are in the process of redesigning and majorly updating this site. We are making exciting additions, but will keep much of the classic content. Stop by again soon, and often!


Software Architecture and Related Concerns

What is Software Architecture?

"Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change." -- Grady Booch

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. Structural elements are identified and assigned responsibilities that client elements interact with through "contracted" interfaces.

In creating architectures, we address

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:

In creating these views, we pay attention to:

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 system architecting. (As an interesting aside, our software architecting process has usefully been applied, without the software modeling specifics, to system, hardware and organization architecting.)


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.