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
II - The Architecture Process
The selection of a specific methodology for capturing, defining, and describing
the system architecture is an arbitrary decision. The following methodology
is used as an example. Other methodologies can be used as long a they
provide a sufficiently rich set of artifacts needed to articulate the
requirements and the solutions that meet those requirements
1 describes the process by which the architecture of the system is discovered,
verified, and deployed.
methodology provides a broad framework in which systems architecture can
be put to work. Depending on the specific needs of the organization, each
methodology phase may be adapted to the desired outcome. In some situations,
the business case and IT Strategy already exist and the technical aspects
of the system dominate the effort. In other situations, the framework
for thinking about the problem must first be constructed before any actual
system construction can take place.
methodology provides guidelines without overly constraining the solution
domain. The methodology is vendor neutral, notation neutral and adaptive
to the organization's short and long-term needs. The methodology has been
proven in the field, in a wide variety of manufacturing industry environments.
1. The Methodology Steps
Methodology and 4+1
The primary components of the methodology that are focused on 4+1 Architecture
description are shown in Figure 3. This methodology is deployed in the
off the shelf (COTS) products integrated into a federated system. The
external functionality of a COTS product is defined by the vendor. The
behavior of the system is usually fixed in some way, with little or no
ability to alter the internal functioning. External behaviors can sometimes
be tailored to meet business needs, within the framework of the COTS product.
of Business databases used to separate the data from the applications.
Legacy applications hold information within their boundaries that must
be integrated with the new system. In many instances, it is not feasible
to move this legacy data to a new system.
engines used to manage the business processes. In many environments the
work processes are fluid, changing with the business climate. Adapting
the work processes to the business process is usually done through some
form of workflow.
this context, the traditional software development approach to system
architecture is not appropriate. Writing software in the COTS environment
is a rare occurrence. The 4+1 architecture is adapted to describe the
behavioral and best practice attributes of the system. In the COTS domain,
the 4+1 Architecture descriptions are now:
- the functional requirements of the business process that are directly
implemented by the system. These include any manual processes or custom
components that must be provided to work around gaps in the COTS system.
- the abilities of the system that are required to meet the business requirements.
- the vendor, system integrator, business process, and management teams
and resources needed to define, acquire, install, deploy, and operate
- the infrastructure needed to define, acquire, install, deploy, and operate
- the Use Cases that describe the sequence of actions between the system
and its environment or between the external objects involved in a particular
execution of the system.
design of software systems involves a number of disciplines applied during
the various phases of the methodology. In the past, functional decomposition
and data modeling was the accepted mechanism for defining the system architecture.
The descriptive and generative aspect of these notations has given way
to UML based notations. Although the methodology described here is
technically independent of any notation or requirements methodology style,
there are advantages to using the current state-of-the-art tools.
reassurance through graphical descriptions of the system. Using a layered
descriptive language, pictures of the system can be constructed at all
levels of detail - from high level executive diagrams to programmer's
level details of data and processes.
generative descriptions, which transform functional decompositions into
textual descriptions, since pictures alone are rarely sufficient to
convey the meaning of design.
renditions that convey good design principles through a simple, clear,
and concise notation.
 The Unified
Modeling Language (UML) is a formal language used to capture the semantics
(knowledge) about a subject and express this knowledge to others, including
machines. The modeling aspects of UML focus on understanding a subject
and capturing and communicating the knowledge about the subject. The unifying
aspects of UML come about through the best practices of the industry,
principles, techniques, methods, and tools. Although UML is object oriented
it can be used in a variety of software and system settings using the
definition of system architectures [Alhi98], [Mull97].
and the Architecture
Figure 2 presents a rearranged topology for the methodology. This arrangement
focuses on applying the architectural principles to the components of
the methodology. There are steps in the methodology that are not addressed
in Figure 2. Although these steps may be impacted by architecture they
are secondary to the Requirements Analysis, Technical System Design, System
Development, and System Deployment.
2. Details of the methodology and its relationship to system architecture.
for the SRA
The System Requirements Analysis (SRA) includes the discovery of the functional
and non-functional requirements that influence the architecture of the
system. These requirements are in addition to the business processing
requirements of the system [Somm97]:
requirements - are requirements for the system that can be stated
as specific behaviors. The following requirements are for the functional
architecture not the business processes provided by this functional architecture.
- enables complexity reduction.
- deals with grouping of abstractions.
hiding - conceals details.
- provides meaningful decomposition.
- provides separation of collaborating components.
/ Cohesion - are measurements of system structure.
completeness, and primitiveness - are properties of components.
of policy and implementation - data and process are isolated.
of interface and implementation - user interfaces and core processes
point references - referential integrity is maintained.
and conquer strategies - modular architecture.
requirements - are usually termed the system's abilities and represent
a set of attributes of the software and hardware that can be measured.
- the robustness of the system in the presence of faults.
- the ability to increase the system's performance with little or no
impact on the system architecture.
- the ability to deliver services when called upon to do so.
- the ability to repair the software or hardware with no impact on the
- the ability to deliver services within the expectations of the users.
- the ability to repair the system without causing consequential damage.
- the ability to make changes to the hardware and software components
without influencing availability.
for the TSD
The Technical System Design (TSD) develops a detailed description of the
system in terms of the multiple views. Each of the views is a refinement
of the functionality of the COTS products laid over the business processes.
view - describes the scope and policies of business systems across
the enterprise. This view considers all the users of the system in an
attempt to normalize the requirements so any one set of requirements or
user does not dominate the system architecture. This view is based on
providing a system that is considered infrastructure.
view - describes the semantics (the meaning) of the information and
the information processing. This view assumes the information is isolated
from the processing and that the processing activities will change over
time, while the semantics of the information remains static throughout
the lifecycle of the system.
view - describes the functional decomposition of the system. This
view decomposes the system into computational units and reconstructs the
system in a manner that best supports the functional organization of the
view - describes the infrastructure of the system as seen from the
physical components, networks, servers, peripherals, and workstations.
view - describes the technology choices that must be made when selecting
vendors for the infrastructure and enabling the COTS components.
of Part II
This is part II of a five part note. The next part describes the steps
in the architecture process.
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 II
in a Nutshell: A Desktop Quick Reference, S. S. Aihir, O'Reilly, 1998.
UML, P.-A. Muller, WROX, 1997.
Engineering A Good Practice Guide, I. Someerville and P. sawyer, John
Wiley & Sons, 1997.