Chapter: Software Architectures : Introduction and Architectural Drivers
The Architecture Business Cycle(ABC)
The Architecture Business Cycle:
Definition: Architecture Business Cycle (ABC):
“Software architecture is a result of technical,
business, and social influences. Its
existence
in turn affects the technical, business, and social environments that subsequently
influence future architectures. We call this cycle of influences, from the
environment to the architecture and back to the environment, the Architecture
Business Cycle (ABC).”
1.The
organization goals of Architecture
Business Cycle are beget requirements, which beget an architecture, which
begets a system. The architecture flows from the architect's experience and the
technical environment of the day.
2.Three
things required for ABC are as follows:
i. Case studies of successful architectures
crafted to satisfy demanding requirements,
so as to help set the technical playing field of the day.
ii. Methods to assess an architecture before
any system is built from it, so as to mitigate
the risks associated with launching unprecedented designs. iii.Techniques for incremental architecture-based development, so
as to uncover design flaws before it
is too late to correct them.
How the ABC Works :
1. The
architecture affects the structure of the developing organization. An
architecture prescribes a structure for a system; as we will see, it
particularly prescribes the units of software that must be implemented (or
otherwise obtained) and integrated to form the system. These units are the
basis for the development project's structure. Teams are formed for individual
software units; and the development, test, and integration activities all
revolve around the units. Likewise, schedules and budgets allocate resources in
chunks corresponding to the units. If a company becomes adept at building
families of similar systems, it will tend to invest in each team by nurturing
each area of expertise. Teams become embedded in the organization's structure.
This is feedback from the architecture to the developing organization.
In the software product
line case study, separate groups were given responsibility for building and
maintaining individual portions of the organization's architecture for a family
of products. In any design undertaken by the organization at large, these
groups have a strong voice in the system's decomposition, pressuring for the
continued existence of the portions they control.
2. The
architecture can affect the goals of the developing organization. A successful
system built from it can enable a company to establish a foothold in a
particular market area. The architecture can provide opportunities for the
efficient
production
and deployment of similar systems, and the organization may adjust its goals to
take advantage of its newfound expertise to plumb the market. This is feedback
from the system to the developing organization and the systems it builds.
3. The
architecture can affect customer requirements for the next system by giving the
customer the opportunity to receive a system (based on the same architecture)
in a more reliable, timely, and economical manner than if the subsequent system
were to be built from scratch. The customer may be willing to relax some
requirements to gain these economies. Shrink-wrapped software has clearly
affected people's requirements by providing solutions that are not tailored to
their precise needs but are instead inexpensive and (in the best of all
possible worlds) of high quality. Product lines have the same effect on
customers who cannot be so flexible with their requirements. A Case Study in
Product Line Development will show how a product line architecture caused
customers to happily compromise their requirements because they could get
high-quality software that fit their basic needs quickly, reliably, and at
lower cost.
4. The process
of system building will affect the architect's experience with subsequent
systems by adding to the corporate experience base. A system that was
successfully built around a tool bus or .NET or encapsulated finite-state
machines will engender similar systems built the same way in the future. On the
other hand, architectures that fail are less likely to be chosen for future
projects.
5. A few
systems will influence and actually change the software engineering culture,
that is, the technical environment in which system builders operate and learn.
The first relational databases, compiler generators, and table-driven operating
systems had this effect in the 1960s and early 1970s; the first spreadsheets
and windowing systems, in the 1980s. The World Wide Web is the example for the
1990s. J2EE may be the example for the first decade of the twenty-first
century. When such pathfinder systems are constructed, subsequent systems are
affected by their legacy.
These and
other feedback mechanisms form what we call the ABC, illustrated in Figure , which depicts the influences of the culture and business
of the development organization on the software architecture. That
architecture is, in turn, a primary determinant of the properties of the
developed system or systems. But the ABC is also based on a recognition that
shrewd organizations can take advantage of the organizational and experiential
effects of developing an architecture and can use those effects to position
their business strategically for future projects.
Building the ABC:
Building
the ABC is done by identifying the influences to and from architectures as
follows:
ARCHITECTURES ARE INFLUENCED BY
SYSTEM STAKEHOLDERS:
1. Many
people and organizations are interested in the construction of a software
system.
· The customer,
· the end users,
· the developers,
· the project manager,
· the maintainers, and
· even those who market the system.
3. Stakeholders have different concerns that they
wish the system to guarantee or optimize, including things as diverse as
providing a certain behavior at runtime, performing well on a particular piece
of hardware, being easy to customize, achieving short time to market or low
cost of development, gainfully employing programmers who have a particular
specialty, or providing a broad range of functions.
4.
Figure shows the architect receiving helpful stakeholder "suggestions."
5. Having an
acceptable system involves properties such as performance, reliability,
availability, platform compatibility, memory utilization, network usage,
security, modifiability, usability, and interoperability with other systems as
well as behavior.
6. Indeed,
we will see that these properties determine the overall design of the
architecture.
7. 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.
8. The
underlying problem, of course, is that each stakeholder has different concerns
and goals, some of which may be contradictory.
9. Properties
can be listed and discussed, of course, in an artifact such as a requirements
document.
10.
But it is a rare requirements document that does a
good job of capturing all of a system's quality requirements
in testable detail.
11. The
reality is that the architect often has to fill in the blanks and mediate the
conflicts.
ARCHITECTURES ARE INFLUENCED BY
THE DEVELOPING
ORGANIZATION:
1. In
addition to the organizational goals expressed through requirements, an
architecture is influenced by the structure or nature of the development
organization.
2. 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.
3. 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 infrastructure.
· The organizational structure can shape the software architecture. In the
case study in (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
specialities.
ARCHITECTURES ARE INFLUENCED BY THE BACKGROUND AND EXPERIENCE
OF THE ARCHITECTS:
1. 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.
2. Conversely,
if their prior experience with this approach was disastrous, the architects may
be reluctant to try it again.
3. 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.
4. 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:
1.
A special case of the architect's background and
experience is reflected by the technical environment.
3. The
environment that is current when an architecture is designed will influence
that architecture.
4. It might
include standard industry practices or software engineering techniques
prevalent in the architect's professional community.
5. 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:
1. Influences
on an architecture come from a wide variety of sources. Some are only implied,
while others are explicitly in conflict.
2. Almost
never are the properties required by the business and organizational goals
consciously understood, let alone fully articulated.
3. Indeed,
even customer requirements are seldom documented completely, which means that
the inevitable conflict among different stakeholders' goals has not been
resolved.
4. However,
architects need to know and understand the nature, source, and priority of
constraints on the project as early as possible.
5. Therefore,
they must identify and actively engage the stakeholders to solicit their needs
and expectations.
6. Without
such engagement, the stakeholders will, at some point, demand that the
architects explain why each proposed architecture is unacceptable, thus
delaying the project and idling workers.
7. Early
engagement of stakeholders allows the architects to understand the constraints
of the task, manage expectations, negotiate priorities, and make tradeoffs.
8. Architecture reviews and iterative prototyping are two means for achieving it.
9. It should
be apparent that the architects need more than just technical skills.
10.
Explanations to one stakeholder or another will be
required regarding the chosen priorities of different properties and why
particular stakeholders are not having all of their expectations satisfied.
11.
For an effective architect, then, diplomacy,
negotiation, and communication skills are essential.
12 .The
influences on the architect, and hence on the architecture, are shown in figure. Architects are influenced by the
requirements for the product as derived from its stakeholders, the structure
and goals of the developing organization, the available technical environment,
and their own background and experience.
THE ARCHITECTURES AFFECT THE FACTORS THAT INFLUENCE
THEM:
1. The main
message of this book is that the relationships among business goals, product
requirements, architects' experience, architectures, and fielded systems form a
cycle with feedback loops that a business can manage.
2. A
business manages this cycle to handle growth, to expand its enterprise area,
and to take advantage of previous investments in architecture and system
building.
3. Some of
the feedback comes from the architecture itself, and some comes from the system
built from it.
Related Topics