B. Alleman is associated with Niwot Ridge Consulting, www.niwotridge.com
About This Note:
note is presented in five parts as follows:
to Software Architecture
- The Architecture
in the Architecture Process
from Planning to Implementation
III - Steps in the Architecture Process
Without a framework for defining architecture and the steps in which it
participates, it is difficult to grasp the impact architecture has on
the outcome of the system process.
process of discovering, defining, and maintaining an architecture for
a specific set of requirements and the applications that support them
is a non-trivial task [Garl95], [Abow95]. There is a distinct difference
between architecture and engineering [Rech97]. Generally speaking, engineering
deals with measureables using analytical tools derived from mathematics
and the hard sciences - engineering is a deductive process. Architecture
deals largely with unmeasurables using non-quantative tools and guidelines
based on practical lessons learned - architecture is in inductive process.
steps taken during the development of a system architecture include:
of the System - the purpose, focus, assumptions, and priorities of the
case analysis - how will the system earn its keep?
analysis - the external behavior and appearance of the system.
planning - the mapping between the requirements and the software.
prototyping - the construction of a prototype system, complete with
all the components. This prototype can be used to verify the abilities
of the final system.
management - the professional management of the project, including resources,
risk, and deliverables [PIM96].
prototyping - the construction of an architecture platform to verify
the abilities of the system components.
deployment - the deployment of the system in a production environment.
This deployment must allow for the incremental functionality of the
system, while verifying the capabilities of the application.
transition - move the incrementally deployed system into full production.
and maintenance - a phase of the system in which all functionality is
deployed and the full bookable benefits are being accrued.
migration - an activity that continuously makes improvements to the
system, within the architectural guidelines [Foot97].
Vision of the System
The construction of a Vision is a wickedly subtle process. When first
asked to articulate a "vision" the system stake holders usually ask "why,
it is obvious what we want the system to do." The reality is that the
vision statement includes not only the technical aspects of the system,
but also the social, political, economic and operational aspects of the
purpose, focus, assumptions, and priorities of a software project are
essential elements of an enterprise-wide vision statement. If any of these
elements change during system acquisition and deployment, there is a significant
risk that the models used to define the system will be obsolete. The first
step in an architecture-centered development methodology is to establish
a viable vision statement, with the assumption that it should not be changed
once acquisition and deployment have begun. Any changes that occur in
the vision must be reflected in the project models and subsequent analysis
vision statement becomes a binding agreement between the software suppliers
and the software consumers - users of the system. This vision statement
must be succinct, ranging from a single slide to less than 10 pages of
text. The vision statement establishes the context for all subsequent
project activities, starting with Requirements Analysis and ending with
the Continuous Migration of the system.
The creation of a Business Case Analysis is a critical success factor
for any system project. Without a clear understanding of the costs and
benefits of the proposed system architecture, the decision-makers cannot
be presented with complete information. The style of the business case
as well as the contents of the analysis is usually an organization specific
A project's requirements define the external behavior and appearance of
the system without specifying its internal structure [Somm97], [Jack96].
External functional behavior, however, includes internal actions needed
to ensure the desired non-functional requirements of the external behavior.
The external appearance comprises the layout and navigation of the user
interface screens, transaction processing activities as well as the behavior
of the system in terms of its abilities. These abilities are usually defined
as adjectives for the properties that system possesses. Reliability, Availability,
Maintainability, Scalability, Performance, Testability, Efficiency, Reusability,
Interoperability, and Changeability as well as other non-functional properties
of the system architecture.
effective approach for capturing behavioral requirements is through Use
Cases, which consist of top-level diagrams and extensive textual descriptions
[Schn98], [Buhr96], [Lamr97]. The Use Case notation is deceptively simple
but has one invaluable quality - it enforces abstraction. It is one of
the most effective notations devised for expressing complex concepts and
a powerful way to ensure the top-level requirements are represented with
simplicity and clarity.
1. - Use Case for Order Taking and Fulfillment.
circle, or individual Use Case, is accompanied by a description of relevant
requirements. It usually takes the form of a list of sequential actions
described in domain-specific prose. Use Case definitions are developed
jointly with domain experts and provide a domain model of the system for
the purpose of defining architecture. Once system integration and deployment
begins, Use Cases are extended with system-specific scenario diagrams
that will be elaborated in workflow, procedural changes and system tests
[Buhr96], [Jaco92], [Schn98].
appearance, functionality, and navigation of the user interface are closely
related to the Use Cases. Here, low fidelity prototyping - drawing the
screens with paper and pencil - often proves effective. Again, end-user
domain experts must be involved in the screen-definition process.
the Use Cases and user interfaces defined, the context for architectural
planning has been established. In addition to generating documentation
(including paper-and-pencil sketches or output from CASE tools), the architecture
team acquires a better understanding of the desired system capabilities
in the context of the end-user domain.
Cases provide the visible means of capturing the external behavior of
the system. The next step in the requirements analysis is to partition
the nouns and noun phrases, verbs and verb phrases. This activity can
be done through Class-Responsibility-Collaboration (CRC) Cards. This tool
identifies and specifies the data and processes of the system in an informal
manner [Bell98]. The CRC Card method is based on the theory of role-playing
in which the participants have specific knowledge about their own roles
and make requests of other participants to gain knowledge of their roles.
Through this role-playing the nouns and verbs of the system are revealed.
If the UML is to be used in the development of the system architecture
described in 4+1, then the different components of the UML must be assigned
specific roles [Tanu98]:
1. UML to 4+1 Mapping
State Transition Diagrams
The process of "planning" the architecture involves more than listing
the attributes of the system. It involves a deep understanding of how
the elements of the architecture interact with each other as well as external
elements. By their nature requirements are vague and ambiguous. Treating
requirements elicitation like code development will surely lead to a disappointing
are inherently ambiguous, intuitive, and informal. Requirements are a
right-brain activity. Software is logically unintuitive (i.e., hard to
decipher) and meant to be interpreted unambiguously by a machine. Software
is a left-brain activity. Architecture bridges the semantic gap between
the requirements and software.
first role is to define the mapping between the Requirements and the Software.
It captures intuitive decisions in a more formal manner, making it useful
to programmers and system integrators, and defines the internal structure
of the system before it is turned into code so that current and future
requirements can be satisfied.
architecture also has another significant role: it defines the organization
of the software project. Architecture planning is the missing link in
many software projects, processes, and methods, often because no one is
quite sure what architecture really is [Rech97], [Perr92], [Kruc95], [Bass98],
[Shaw96]. One framework for defining software architecture is provided
by the ISO standard for Open Distributed Processing (ODP) called the International
Standard ISO/IEC 10746 (ITU X.900), 1995.
There are other frameworks promulgated in the industry, ranging from commercially
based paradigms to government standards: Software Engineering Institute,
Manufacturing Systems Integration Division, National Institute of Standards
and Technology, Department of Defense, and Quality Function Deployment.
There is no universal standard for software architecture. The ODP is a
generic set of guidelines appropriate for client/server environments as
well as the emerging Internet and object oriented paradigms. The ODP defines
five viewpoint references (enterprise, information, computational, engineering,
and technology). When used in conjunction with good system engineering
practices and proven software development and system engineering guidelines,
the ODP provides a clear and concise framework for the deployment of manufacturing
centric systems. In addition to the ODP guideline several other architectures
are in use today that require examination. The Zachman Framework [Zach87]
is a traditional architectural approach that is not object oriented. It
is a reference model with 30 architecture viewpoints based on two paradigms:
Journalism (who, what, when, where, why, and how) and Construction (planner,
owner, builder, designer, and subcontractor). Domain analysis which transforms
project-specific requirements into general domain requirements for familiar
systems. The 4+1 view model which is closely tied to UML and the Rational
Unified Process. Many other architectural styles are defined in [Shaw96].
ODP is a way to think about complex systems that simplifies decision-making.
It organizes the system architecture in terms of five standard viewpoints
[ISO94a], [ISO94b], [ISO94c], [ISO94d]:
viewpoint - the purpose, scope, and policies of the business system
as defined by the workflows and business rules.
- the semantics of information and information processing.
viewpoint - the functional decomposition of the system in modules,
interfaces and the messages exchanged across the interfaces.
viewpoint - the infrastructure required to support the distributed
- choice of technology for the implementation of the system.
2. The RM-ODP Viewpoints and Software Engineering, from [ISO94a]
viewpoint defines the conformance to the architectural requirements. Without
this conformance to requirements, the architecture is meaningless, because
it will have no clear impact upon implementation. ODP facilitates this
process by embodying a pervasive conformance approach. Simple conformance
checklists are all that are needed to identify conformance points in the
ODP+4 methodology - based on the 4+1 Architecture [Kruc95] - generates
an Open Distributed Processing architecture as well as formal and informal
artifacts, including the Vision Statement, the Use Case-based requirements,
the rationale and the conformance statements.
enterprise viewpoint defines the business purpose and policies of the
system in terms of high-level enterprise objects. These business-object
models identify the essential constraints on the system, including the
system objective and important policies. Policies for business objects
are divided into three categories:
- what must be performed by the system.
- what can be enforced by the system.
- what must not be performed by the system.
Business Enterprise Architecture comprises a set of logical object diagrams
(in UML notation), and prose descriptions of the diagram semantics [Larm97].
The language of the enterprise view is concerned with the performable
actions that change policy, such as creating an obligation or revoking
3. UML notation for describing the enterprise-wide data objects for
a sales company.
preparing the enterprise viewpoint specification, policies are determined
by the organization rather than imposed on the organization by technology
information viewpoint identifies what the system must know, expressed
as a model, emphasizing attributes that define the system state. Because
ODP is an object-oriented approach, the models also include essential
information processes encapsulated with attributes, thus following the
conventional notion of an object.
objects are not programming objects. The information objects do not denote
objects that must be programmed. On the other hand, the architecture does
not exclude this practice. Architecture objects represent positive and
negative constraints on the system. Positive constraints identify things
that the system's software must do. Negative constraints are things that
the system's software does not have to do. Knowledge of these constraints
aids the designers because it eliminates much of the guesswork in translating
requirements to system. Architects should focus their modeling on the
system aspects of greatest risk, complexity, and ambiguity, leaving straightforward
details for the development step. The information model does not constitute
an engineered design. In particular, engineering analysis, such as database
normalization, is explicitly delegated to the development activities.
This Object Oriented approach is motivated by several forces:
use Object Oriented (OO) methodologies to define the architecture of
their products. In some cases the OO components are provided through
a gateway creating a traditional system with OO wrappers. In other products
the system is constructed using OO technologies. Other systems are hybrids
of OO and traditional client/server and SQL database technologies.
- OO architecture
pervades the Internet
- OO is
a better means of analyzing systems requirements using UML, Use Cases,
and CRC Cards.
computational viewpoint defines the top-level application program interfaces
(API). These are fully engineered interfaces for subsystem boundaries.
During implementation, the system integration team will develop application
modules that comply with these boundaries. Architectural control of these
interfaces is essential to ensuring a stable system structure that supports
change and manages complexity.
computational viewpoint specification defines the modules (objects, API's,
subsystems) within the ODP system, the activities with these modules,
and the interactions that occur among them. Most modules in the computational
specification describe the application functionality. These modules are
linked through their interaction descriptions.
CORBA Interface Definition Language (IDL), an ISO standard notation for
ODP computational architectures, becomes a fundamental notation for software
architects at these boundaries. It has no programming language and operating
system dependencies, and can be translated to most popular programming
languages for both CORBA and Microsoft technology bases (i.e., COM/DCOM).
engineering viewpoint defines the infrastructure requirements independent
of the selected technologies. It resolves some of the complex system decisions,
including physical allocation, system scalability, and communication qualities
of service (QoS), and fault tolerance.
benefit of using the ODP is it separates the various concerns (design
forces) during the architecture process. The previous viewpoints resolved
other complex issues of less concern to distributed systems architects,
such as APIs, system policies, and information schemas. Conversely, these
other viewpoints were able to resolve their respective design forces,
independent of distribution concerns. Decisions must be made regarding
system aspects such as object replication, multithreading, and system
topology. It is during this activity that the physical architecture of
the system is developed.
technologies that will be used to implement the system are selected in
this view. All other viewpoints are fully independent of these technology
decisions. Since the majority of the architecture design process is independent
of the deployed hardware, commercial technology evolution can be readily
systematic technology selection process includes initial identification
of the conceptual mechanisms (such as persistence or communication). Specific
requirements of the conceptual mechanism are gathered from the other viewpoints
and concrete mechanisms such as DBMS, OODBMS, and flat files are identified.
Then specific candidate mechanisms are selected from available products.
Other project factors, such as product price, training needs, and maintenance
risks, are considered at this point. It is important to restate the rationale
behind these selections, just as it is important to record the rationales
for all viewpoints as future justification of architectural constraints.
projects wrongly consider this technology view as system architecture.
By developing the technical viewpoints before the other ODP architectural
views, the project is turned upside down.
of Part III
This is part III of a five part note. The next part covers moving from
the planning to implementation.
B. Alleman, has provided consulting services to a variety of industries
and business domains in the industrial and commercial market places. These
include, e-commerce systems, publishing systems, information technology
strategies, manufacturing systems, engineering design systems, and software
has direct experience in a variety of large scale integration environments
and business domains. He also has extensive program and project management
experience with multiple concurrent projects involving hardware, software,
multiple sites and legacy business systems integration.
Alleman has deep technical and architectural knowledge of a variety of
system paradigms including: client/server, CORBA, and web-based systems.
is the Principal Consultant for Niwot Ridge Consulting, Niwot, Colorado,
- Part III
Style to Understand Descriptions of Software Architecture," G. Abowd,
G. Allen and D. Garland, ACM Transactions on Software Engineering
and Methods, 4(4), pp. 319-164, 1995.
Style to Understand Descriptions of Software Architecture," G. Adowd,
R. Allen and D. Garlan, ACM Software Engineering Notes, December,
1993, pp. 9-20.
Best Industrial Practice for Software Architecture Evaluation," G.
Abowd, L. Bass, P. Clements, R. Kazman, L. Northrop, and A. Zaremski,
CMU/SEI-96-TR-025, Software Engineering Institute, Carnegie Mellon
University, Pittsburgh, PA, January 1996.
Architecture in Practice, L. Bass, P. Clements and R. Kazman, Addison
CRC Card Book, D. Bellin and S. Suchman Simone, Addison Wesley, 1998.
Case Maps for Object-Oriented Systems, R. J. A. Buhr and R. S. Casselman,
Ball of Mud," B. Foote and J. Yoder, University of Illinois at Urbana-Champaign,
Mismatch or Why It's Hard to Build Systems Out of Existing Parts,"
D. Garlan, R. Allen, and J. Ockerbloom, Proceedings of the Seventh
International Conference on Software Engineering, April 1995.
Practice for Architectural Description," IEEE Standard P1471, 1998.
Reference Model of Open Distributed Processing - Part 1: Overview
and Guide to Use," ISO/IEC CD 10746-1, July 1994.
Reference Model of Open Distributed Processing - Part 2: Descriptive
Model," ISO/IEC CD 10746-1, February 1994.
Reference Model of Open Distributed Processing - Part 3: Prescriptive
Model," ISO/IEC CD 10746-1, February 1994.
Reference Model of Open Distributed Processing - Part 4: Architectural
Semantics," ISO/IEC CD 10746-1, July 1994.
Telecommunications Union: message Sequence Charts, ITU-T, Z.120, 1994.
Software Engineering: A Use Case Driven Approach, I. Jacobson, Addison
4+1 View Model of Architecture," P. Kruchten, IEEE Software, 12(6),
pp. 42-50, 1995.
UML and Patterns: An Introduction to Object-Oriented Analysis and
Design, C. Larman, Prentice Hall, 1997.
for the Study of Software Architecture," D. E. Perry and A. L. Wolf,
ACM Software Engineering Notes, October, 1993, pp. 40-52.
to the Project Management Body of Knowledge, W. Duncan, Project Management
Institute, 130 South State Road, Upper Darby, PA 19082, 1996.
Art of Systems Architecting, E. Rechtin and M. W. Maier, CRC Press,
Use Cases: A Practical Guide, G. Schneider and J. P. Winters, Addison
Architecture: Perspectives on an Emerging Discipline, M. Shaw, and
D. Garlan, Prentice-Hall, 1996.
Architecture in the Business Software Domain: The Descartes Experience,"
M. Tanuan, Proceedings of ISAW3, ACM 1998, pp. 145-148.
for Information Systems Architecture," J. Zackman, IBM Systems Journal,
26, Number 3, 1987.