other systems as well as behavior. Indeed, we will see that these properties determine the overall design
of the architecture. All of them, and others, affect how the delivered system is viewed by its eventual
recipients, and so they find a voice in one or more of the system's stakeholders.
The underlying problem, of course, is that each stakeholder has different concerns and goals, some of
which may be contradictory. Properties can be listed and discussed, of course, in an artifact such as a
requirements document. But it is a rare requirements document that does a good job of capturing all of a
system's quality requirements in testable detail. The reality is that the architect often has to fill in the
blanks and mediate the conflicts.
ARCHITECTURES ARE INFLUENCED BY THE DEVELOPING ORGANIZATION
In addition to the organizational goals expressed through requirements, an architecture is influenced by
the structure or nature of the development organization. For example, if the organization has an
abundance of idle programmers skilled in client-server communications, then a client-server architecture
might be the approach supported by management. If not, it may well be rejected. Staff skills are one
additional influence, but so are the development schedule and budget.
There are three classes of influence that come from the developing organization: immediate business,
long-term business, and organizational structure.
An organization may have an immediate business investment in certain assets, such as existing
architectures and the products based on them. The foundation of a development project may be that
the proposed system is the next in a sequence of similar systems, and the cost estimates assume a
high degree of asset re-use.
An organization may wish to make a long-term business investment in an infrastructure to pursue
strategic goals and may view the proposed system as one means of financing and extending that
The organizational structure can shape the software architecture. In the case study in Chapter 8
(Flight Simulation: A Case Study in Architecture for Integrability), the development of some of the
subsystems was subcontracted because the subcontractors provided specialized expertise. This
was made possible by a division of functionality in the architecture that allowed isolation of the
ARCHITECTURES ARE INFLUENCED BY THE BACKGROUND AND EXPERIENCE OF THE
If the architects for a system have had good results using a particular architectural approach, such as
distributed objects or implicit invocation, chances are that they will try that same approach on a new
development effort. Conversely, if their prior experience with this approach was disastrous, the architects
may be reluctant to try it again. Architectural choices may also come from an architect's education and
training, exposure to successful architectural patterns, or exposure to systems that have worked
particularly poorly or particularly well. The architects may also wish to experiment with an architectural
pattern or technique learned from a book (such as this one) or a course.
ARCHITECTURES ARE INFLUENCED BY THE TECHNICAL ENVIRONMENT
A special case of the architect's background and experience is reflected by the
The environment that is current when an architecture is designed will influence that architecture. It might
include standard industry practices or software engineering techniques prevalent in the architect's
professional community. It is a brave architect who, in today's environment, does not at least consider a
Web-based, object-oriented, middleware-supported design for an information system.
RAMIFICATIONS OF INFLUENCES ON AN ARCHITECTURE
Influences on an architecture come from a wide variety of sources. Some are only implied, while others
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
29 / 463