What is Software Architecture?

It's what software architects do / create / make! :-)

Ha! No I can't take that cop out - well at least not here.

But still . . . . we've asked probably the hardest question in the world of software development.

Why? Because no two people can seem to agree. But I think most of us who've been in the industry can say "I know it when I see it" but it's another unsatisfying answer. (Such issues also exist in the legal world http://en.wikipedia.org/wiki/Potter_Stewart)

Why is it so difficult - well think of it this way- Code is not architecture although code is the ultimate expression of the architecture. Requirements are not architecture but they help lead you to the architecture. Design patterns are not architecture but they are building blocks towards the architecture. So what is it?

Well in this blog entry I'll try to bring together different views of what constitutes software architecture. Some I have problems with as they're quite incomplete definitions IMO. Others are on the right track . . .

1) Architecture as Representation.
Wikipedia Definition - See http://en.wikipedia.org/wiki/Software_architecture

"The software architecture of a system consists of software components, their external properties, and their relationships with one another"

First of all Software Architecture is not just a a set of "relationships " - true it can be *expressed* as that but it's so much more than that - there's no talk of the end goal or the rationale for the architecture - a system to be used by people to address a specific goal. The wiki talks about "views" (as in the 4+1 model) but that is really just a slight hint that an architecture has different stakeholders - users (functional view), developers (code view, development view etc), but what also about managers?

2) IEEE Definition - Architecture as Organization with Principles in an Environment

"Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. "
"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. "

But this seems to separate the system itself from the "fundamental organization" (i.e. the architecture). But in many ways, a system's architecture is inseparable from the system itself - change the system you change the architecture. Change the architecture and you change the system.

3) Bredemeyer Consulting
http://www.bredemeyer.com/whatis.htm

Too many quotes to list so I suggest you click the link. But these guys are getting very close - they don't just give a blanket single sentence definition. But the idea of components and their interactions (dynamic and static aspects) with different views (users, managers, developers etc.) is pretty darn good. The concept of "decomposability" is emphasized here.
Also they point out that a "vision" is part of an architecture also - as an architecture, at least to my mind, is a growing entity since software is never fully "done". The vision should encapsulate some aspects of how the architecture will evolve over time.

4) IBM Developerworks
The following link is to a great summary from which I have borrowed the quotes that follow
http://www-128.ibm.com/developerworks/rational/library/feb06/eeles/index.html

"An architecture is the set of significant decisions about the organization of a software system, the selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these elements into progressively larger subsystems, and the architectural style that guides this organization -- these elements and their interfaces, their collaborations, and their composition." [Kruchten]

"The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them." [Bass et al.]

"[Architecture is] the organizational structure and associated behavior of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems." [UML 1.5]

"The software architecture of a system or a collection of systems consists of all the important design decisions about the software structures and the interactions between those structures that comprise the systems. The design decisions support a desired set of qualities that the system should support to be successful. The design decisions provide a conceptual basis for system development, support, and maintenance." [McGovern]

In this summary article Eeles does some great analysis and points out some really great things:

• Firstly all architectures should emanate from some rationale "An important aspect of an architecture is not just the end result, the architecture itself, but the rationale for why it is the way it is. Thus, an important consideration is to ensure that you document the decisions that have led to this architecture and the rationale for those decisions."
• Architectures have an experiential and style elements "Most architectures are derived from systems that share a similar set of concerns. This similarity can be described as an architectural style, which can be thought of as a particular kind of pattern, albeit an often complex and composite pattern (a number of patterns applied together). Like a pattern, an architectural style represents a codification of experience"
• The architecture influences the development team "An architecture influences team structure" and vice-versa "the current team structure and the skills available represent a very real constraint on what is possible". Unmentioned though are other influences of the other resources - time and money
• Also he points out a very important assumption we've all made "An architecture has a particular scope" that is there are software architectures, business architectures, information architectures, hardware architectures etc. which also goes back to the point about views but here not necessarily for the sake of stakeholders - different levels of description.

5) Grady Booch

http://www.booch.com/architecture/index.jsp

"At the highest level of abstraction, every system has an architecture, encompassing the key abstractions and mechanisms that define that system's structure and behavior as seen from the perspective of different stakeholders, each with a different set of concerns"

This is probably the closes to a great one sentence definition I've seen - discussing structure, behavior, viewpoints and the necessary abstractions.

6) SEI Definitions

So even the Software Engineering Institute (SEI) at Carnegie Mellon effectively punts on the definition -http://www.sei.cmu.edu/architecture/definitions.html

Summary

So many definitions - so many aspects and qualities of the architecture, so many constraints and influences on the architecture and constraints/influences emanating from the architecture.

Can you point to a software architecture - with so many viewpoints (stakeholder and scope) the answer is "Yes" and "No"? The architecture is everywhere in the system and yet nowhere. How very Zen / Buddhist.

Will the answers get much better than this? I'm not sure - as the field of software (engineering?) advances I hope so, but there is something poetic about it's current fungibility.