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
V - Applying the Methodology
A Critical Success Factor in the architecture business is the clear and
concise application of a methodology (any methodology) to the problem.
The attributes clear and concise cannot be over emphasized. The UML notation
is one means of conveying clear and concise architecture, but other "languages"
can be used.
methodology described in the previous sections must be deployed against
a live system in order to be of any value to the organization. This section
applies the methodology in a checklist manner. The architect, the developers,
and the deployment team can use these checklists to ask questions about
the proposed (or existing) system.
great movement must experience three stages: ridicule, discussion, and
- John Stuart Mill.
Role of the Architect
The architect's role in all of these processes is to maintain the integrity
of the vision statement using the guidelines provided in this White Paper.
This can be done by:
asking architecture questions in response to system requirements, requests
for new features, alternative solutions, vendor's offerings and the suggestions
on how to improve the system - does this suggestion, product or feature
request fit the architecture that has been defined? If not, does the requested
item produce a change in the architecture? If so, does this item actually
belong in the system?
asking the developers, integrators, and product vendors to describe how
their system meets the architectural principles stated in the vision of
the system. These
questions are intended to maintain the integrity of the system for future
and unforeseen needs, not the immediate needs of the users. Without this
integrity, the system will not be able to adapt to these needs.
adapting to the needs of the users and the changing technology. The discipline
of software architecture is continually changing. The knowledge of software
architecture is expanding through research and practice. The architect
must participant in this process as well.
The management of the system architecture is a continuous improvement
process much in same way any quality program continually evaluates the
design and production process in the search for improvement opportunities.
evaluation - the architecture of the proposed system is continually
compared with other architectural models to confirm its consistency.
management - the architecture is actively managed in the same way
software development is managed.
design processes - there are formal design processes for software
architecture, just as there are formal processes for software development.
These processes must be used if the architecture is to have an impact
on the system integrity.
design process - the non-functional requirements must be provided
in the detailed system design. The design process will include the metrics
needed to verify the non-functional requirements are being met in the
The ODP framework provides a number of functions to manage the architecture
of the system [Booc99]:
- how are the various components of the system being defined, created,
and managed? Are these components defined using some framework in which
their architectural structure can be validated?
- are the various components and their authors participating in a rigorous
process? Can the architectural structure of the system be evaluated across
the various components with any consistency? Is there a clear and concise
model of each coordinating function in the system?
- are the various transactions in the system clearly defined? Are they
visible? Are they recoverable? Do the transactions have permanence?
- is the data in the system isolated from the processing components?
management - is there a mechanism for defining and maintaining the
metadata for each data and process type?
- have the security attributes of the system been defined before the data
and processing aspects?
The computational specifications of the system are intended to be distribution-independent.
Failure to deal with this transparency is the primary cause of difficulty
in the implementation of a physically distributed, heterogeneous system
in a multi-organizational environment. Lack of transparency shifts the
complexities from the applications domain to the supporting infrastructure
domain. In the infrastructure domain, there are many more options available
to deal with transparency issues. In the application domain,
- hides the differences in data representation and procedure calling mechanisms
to enable internetworking between heterogeneous systems.
- makes the use of physical addresses, including the distinction between
local and remote resource usage.
- hides the relocation of a service and its interface from other services
and the interfaces bounded by it.
- masks the relocation of a service from that service and the services
that interact with it.
- masks the deactivation and reactivation of a service.
- masks the failure and possible recovery of services, to enhance the
fault tolerance of the system.
- hides the coordination required to satisfy the transactional properties
of operations. Transactions have four critical properties: Atomicity,
Consistency, Isolation, and Durability. These properties are referred
to as ACID [Bern97]. Atomicity means that the transaction execute to completion
or not at all. Consistency means that the transaction preserves the internal
consistency of the database. Isolation means the transaction executes
as if it were running alone, with no other transactions. Durability means
the transaction's results will not be lost in a failure.
The construction of software is based on several fundamental principals.
These are called enabling techniques [Busc96]. All the enabling techniques
are independent of a specific software development method, programming
language, hardware environment, and to a large extent the application
domain. These enabling techniques have been known for years. Many were
developed in the 1970's in connection with publications on structured
programming [Parn72], [Parn85].
the importance of these techniques has been recognized in the software
development community for some time, it is now becoming clear of the strong
link between system architecture and these enabling principles. Patterns
for software architecture are explicitly built on these principles.
- is a fundamental principle used to cope with complexity. Abstraction
can be defined as the essential characteristic of an object that distinguishes
it from all other kinds of objects and thus provides crisply defined conceptual
boundaries relative to the perspective of the viewer. [Booc94]. The word
object can be replaced by component or module to achieve a broader definition.
- deals with grouping the elements of an abstraction that constitute its
stricture and behavior, and with separating different abstractions from
each other. Encapsulation provides explicit barriers between abstractions.
hiding - involves concealing the details of a component's implementation
from its clients, to better handle system complexities and to minimize
coupling between components.
- is concerned with the meaningful decomposition of a system design
and with its grouping into subsystems and components.
- different or unrelated responsibilities should be separated from each
other within the system. Collaborating components that contribute to the
solution of a specific task should be separated from components that are
involved in the computation of other tasks.
and Cohesion - are principles originally introduced as part of structured
design. Coupling focuses on inter-module aspects. Cohesion emphasizes
intra-module characteristics. Coupling is the measure of strength of association
established by the connection from one module to another. Strong coupling
complicates a system architecture, since a module is harder to understand,
change, or to correct if it is highly interrelated with other modules.
Complexity can be reduced by architecting systems with weak coupling.
measures the degree of connectivity between the functions and elements
of a single function. There are several forms of cohesion, the most desirable
being functional cohesion. The worst is coincidental cohesion in which
unrelated abstractions are thrown into the same module. Other forms of
cohesion - logical, temporal, procedural, and informal cohesion are described
in the computer science literature.
completeness, and primitiveness - sufficiency means that a component
should capture those characteristics of an abstraction that are necessary
to permit a meaningful and efficient interaction with the component. Completeness
means that a component should capture all relevant characteristics of
its abstraction. Primitiveness means that all the operations a component
can perform can be implemented easily. It should be the major goal of
every architectural process to be sufficient and complete with respect
to the solution to a given problem.
of policy and implementation - a component of a system should deal
with policy or implementation, but not both. A policy component deals
with context-sensitive decisions, knowledge about the semantics and interpretation
of information, the assembly of many disjoint computations into a result
or the selection of parameter values. An implementation component deals
with the execution of a fully-specified algorithm in which no context-sensitive
decisions have to be made.
of interface and implementation - any component in a properly architected
system should consist of an interface and an implementation. The interface
defines the functionality provided by the component and specifies how
to use it. The implementation includes the actual processing for the functionality.
point references - any function within the system should be declared
and defined only once. This avoids problems with inconsistency.
and conquer strategies - is familiar to both system architects and
political architects. By dividing the problem domain into smaller pieces,
the effort necessary to provide a solution can be lessened.
The non-functional properties of a system have the greatest impact on
its development, deployment, and maintenance. The overall abilities of
the system are a direct result of the non-functional aspects of the architecture.
- since systems usually have a long life span, they will age [Parn94].
This aging process creates new requirements for change. To reduce maintenance
costs and the workload involved in changing a system's behavior, it is
important to prepare its architecture for modification and evolution.
- the software systems that result from a specific architecture do not
exist independently from other systems in the same environment. To support
interoperability, system architecture must be designed to offer well-defined
access to externally-visible functionality and data structures.
- deals with the use of the resources available for the execution of the
software, and how this impacts the behavior of the system.
- deals with the general ability of the software to maintain its functionality
in the face of application or system errors and in situations of unexpected
or incorrect usage.
- a system needs support from its architecture to ease the evaluation
of its correctness.
The following checklist can be used as a guideline for applying these
a vision statement for the system. This vision statement must be acceptable
not only to the management and executive team members, but to the end
users as well. It is not uncommon to have a wonderfully crafted statement
of the systems vision, that can be placed on the boardroom wall, only
to have the shop floor user consider the vision out of touch with what
actually happens in the real world. Developing the vision statement is
not a simple task and should be given sufficient time and effort. This
statement will form the foundation of the project and will be used to
resolve conflicts in the direction of the development effort - why are
we doing this is answered by the vision statement.
business case process is common is most organizations. The constraints
of the financial calculations will be defined ahead of time. The business
case must consist of hard - bookable - savings. After these savings have
been identified, soft savings can be considered.
requirements analysis can take place in a variety of forms. The real goal
here is to bring out the needs of the user, within the context of good
system architecture. The users needs can be captured through interviews,
Use Cases, CRC Cards, or a nearly any requirements generation process.
The primary goal of the architect is to prevent the requirements from
corrupting the underlying system architecture. This tradeoff process requires
skill and persistence. In many cases the user will articulate a requirement
as a must have behavior of the system. The consequence of this requirement
may damage the architectural structure of the system. The architect's
role is to incorporate the requirement without upsetting the architecture.
This is done by iterating on both the requirements and the architecture
until there is the proper fit.
the IEC 10746 ODP structure, the architect defines the system from the
five (5) viewpoints. The capturing of these viewpoints can be done through
any appropriate tool. In the current OO paradigm, the UML notation is
a powerful means of describing all five viewpoints. The complete UML language,
in conjunction with CRC Cards, can describe the system logical and physical
prototyping process provides a powerful means of trying out parts of the
system design without the commitment to production. During the prototyping
activity, the system architecture is being evaluated against the planned
architecture. During this process, the architect must be vigilante to
avoid compromising the structural, aspect, and behavioral integrity system
without good cause. It is the natural inclination of the developers and
end user to accept a work around at this point. This work around will
become a permanent undesirable feature of the system if it is accepted
without the full understanding of the consequences.
incremental deployment process should follow the Business Case analysis
rollout strategy. The business case describes how the benefits will be
booked over time and by which component of the organization. The system
deployment must follow this benefit stream in order to accrue the savings.
transition to production process is a continuation of the incremental
deployment. The full training and operational support activities are now
operation and maintenance of the system is then turned over to the production
continuous migration of the system is a process not usually considered
part of system architecture. Without the architectural influences on this
activity, the system will quickly decay into a legacy set of components.
are numerous examples of layered architecture in the current literature.
Presenting one here may appear redundant. However, we need to start some
place and the EDM/PDM domain provides unique requirements not always found
in general business systems. This example, shown in Figure 5-1, is derived
from [Hofm97] and adapted to the manufacturing domain.
this example architecture the components are partitioned into functional
- is an application system that implements workflow metaphors for business
processes. This component is usually a COTS product or at least a set
of components that adheres to the Workflow Management Coalition specifications.
The workflow component acts as a glue piece above all the application
systems of the enterprise, integrating all the applications. If there
is an atomic process to be performed, the work can be performed externally
to the workflow system or as part of an application component embedded
in the workflow process.
Objects - are made up of two types:
Interfaces - provide for the manipulation of kernel objects through
graphical user interfaces. The interface objects are typically partitioned
into presentation objects and dialog controls that manage the flow of
control in the dialog.
Interfaces - provide for manipulation of application kernel objects
using batch processes. This batch processing is often neglected
Handling - is a common service provided by the standard architecture.
Exceptions ride up along the application domain until they reach the upper
layer and can be handled by software or made visible to the users. In
practice exception handling consists of several exception classes and
protocols plus components to map exceptions to meaningful messages for
Kernel - is a set of components grouped by structural similarity,
not by functional requirements.
transaction objects - a meaningful business process may require
several steps or dialogs, which in turn interact with lower level business
processes. Business transaction objects are used to control the sequencing
of these actions.
- provide the core set of functions needed for EDM or PDM. These functions
are usually derived from the analysis of the business.
functions - provide a core set of functions used by the application.
These functions typically have a narrow interface, perform complex calculations
or behavior (management change, format conversion, database processing).
System - consists of an interface and a set of application kernel
objects that are manipulated through the interface.
1. A Standard Architecture
is the conclusion of a five part article. The previous four parts were
published on this web site, with the same title.
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,
Reference section which follows applies to this section only.
Principles of Transaction Processing, P. A. Bernstein and E. Newcomer,
Morgan Kaufmann, 1997.
System of Patterns: Pattern-Oriented Software Architecture, Frank
Buschmann, et al, John Wiley and Sons, 1996.
to Software Architecture," C. Hofmann, E. Horn, W. Keller, K. Renzel,
and M. Schmidt, in Software Architecture and Design Patterns in Business
Applications, edited by M. Broy, E. Denert, K. Renzel, and M. Schmidt,
Technical University at Muhchen, TUM-I9746, November, 1997.
the Criteria to be Used in Decomposing Systems into Modules," D. Parnas,
Communications of the ACM, Vol. 15, pp. 1053-1058, December 1972.
Modular Structure of Complex Systems," D. Parnas, P. Clements, and
D. Weiss, IEEE Transactions in Software Engineering, Vol. SE-11, No.
3, March 1985.