Grady Booch
IBM Fellow

Podcast 3: Review the role of the architect (6 min 11 sec)

IBM software architect kit
http://www.ibm.com/developerworks/architecture/kits/index.html

This is part three of a four-part series on software architecture. In this installment,
we'll look at representing software architectures.

In civil engineering, an architect will represent his or her significant design
decisions in a variety of models. These may be physical, three-dimensional models of the
building itself, or more likely and ultimately, in blueprints. Now, the interesting thing
about such blueprints is that for buildings of any significance there are rarely single
blueprints that define those architectural decisions. Rather, there will be blueprints with
multiple views -- floor plans, electrical plans, heating plans, and perhaps even networking
plans. In developing software systems there is an analogy, for just like buildings, there
are multiple stakeholders with different views and different concerns and therefore architects
build models to reason about these architectural decisions. 

Let's get some definitions here out of the way. A model is a simplification of reality created
in order to better understand the system being created and therefor a model is a semantically
closed abstraction of the system. Each model takes a look at a system from a particular view,
and we define view as a representation of a whole system from the perspective of a related set
of concerns. By concerns we mean those interests which pertain the systems development, it's
operation, or any other aspects that are critical or otherwise important to one or more 
stakeholders -- a stakeholder being an individual, team, or organization or classes thereof
with interests in or concerns relative to a system. These ideas are codified in the IEEE standard
for describing software architectures, the IEEE standard 1472. There's been a considerable amount
of work in representing architectures by people such as Paul Clements and his colleagues at the
Software Engineering Institute, Zackman, and also the work of Philippe Kruchten, especially in
his classical paper on the 4+1 model view of software architecture.

One thing that is very clear from our experience in working with the architecture of complex systems
is that we know we need multiple views. It's also the case that not all systems require all views. 
If I have a simple system with a single process I can ignore process issues. If I have a small program,
I can ignore deployment and implementation views. If I'm running a system on a single processor I can 
also ignore issues of the network and deployment. It's also the case that some complex systems require
additional views. If I have a data intensive system I'll need to look at data schemes more intensely.
If I have a system for which security is an overwhelming issue, then security views are important. 
Returning back to Philippe Kruchten's 4+1 model view, this is the approach I have used in developing
the handbook of software architecture, and my experience thus far is that no matter what domain or 
complexity of system, these four views seem to be sufficient in representing the various concerns 
and aspects of an architecture. These four views are the logical process, implementation, deployment,
and use-case views. 

Let's look at each one of these. The logical view of a system, along with the process view, represent
the parts of a conceptual view of a system. The logical view is the view of a systems architecture that
encompasses the vocabulary of the problem space and solution space, the collaborations that realize a
system's use cases, the sub-systems that provide the central layering a decomposition of the system, 
and the interfaces that are exposed by those subsystems and the system as a whole. The logical view
focuses on functionality, key abstractions, mechanisms, and in reasoning about a separation of concerns
and distribution of responsibilities. The process view represents the view of a systems architecture 
that encompasses the threads and processes that form the system's concurrency and synchronization 
mechanisms. The process view focuses upon performance, scalability, and throughput. 

The implementation and deployment views represent the physical aspects of a system. The implementation
view is the view of a system's architecture that encompasses the components used to assemble and release
the physical system. The implementation view therefor focuses upon reasoning about configuration 
management. The deployment view is the view of a system's architecture that encompasses the nodes
that form the system's hardware topology in which the system executes. The deployment view therefore
focuses on distribution, communication, and provisioning. The use-case view transcends all of these
four views. This is the +1 of the 4+1 view in Philippe's model. The use-case view represents the view
of a system's architecture that encompasses the uses cases that describe the behavior of the system
as seen by its users and other external stakeholders. Thus one may have use cases for each of the 
various views as well as for the system as a whole. 

Now, these various views influenced the creation of the Unified Modeling Language. When Jim, Evar
and I came together to devise the beginnings of the UML, we were influenced by Philippe's 4+1 model 
view and insured that the UML was sufficient to represent the semantics of each of these views. Furthermore,
these views are representable in the Rational Software Architect product because we have the ability to
represent these, visualize them, and construct from each of these views. Why do we care about this 
representation? We model our architectures from multiple views in order to codify our design decisions, 
in order to reason about those decisions, and finally and most importantly, to transform those decisions
into executable code. 

In the next segment, we'll focus on the future of software architecture research.