UNIT 3

ANALYZING ARCHITECTURE
SYLLABUS

1. Architecture Evaluation
2. Architecture design decision making
3. ATAM
4. CBAM
5. software product lines
6. Software Architecture in future
 TOPIC 1: ARCHITECTURE EVALUATION
Architecture factors: (Any one of the following three forms)

1. Evaluation by the Designer

2. Evaluation by peers
3. Analysis by outsider
EVALUATION BY THE DESIGNER

• The importance of the decision

• The number of potential alternatives.

• Good enough as opposed to perfect

EVALUATION BY PEERS

• The reviewers determine a number of quality attribute scenarios to drive the review

• The architect presents the portion of the architecture to be evaluated

• For each scenario, the designer walks through the architecture and explains how
the scenario is satisfied

• Potential problems are captured

ANALYSIS BY OUTSIDERS

• “Outside” is relative; this may mean outside the development project,

outside the business unit where the project resides but within the same
company; or outside the company altogether. To the degree that
evaluators are “outside,” they are less likely to be afraid to bring up
sensitive problems, or problems that aren’t apparent because of
organizational culture
THE ARCHITECTURE TRADEOFF ANALYSIS
METHOD (ATAM)
Participants in the ATAM

1. The evaluation team

2. Project decision makers.

3. Architecture stakeholders
ATAM EVALUATION TEAM ROLES
Role Responsibilities
• Team Leader Sets up the evaluation; coordinates with client, making sure client’s needs are met;
establishes evaluation contract; forms evaluation team; sees that final report is produced and
delivered.
• Evaluation Leader Runs evaluation; facilitates elicitation of scenarios; administers scenario
selection/prioritization process; facilitates evaluation of scenarios against architecture; facilitates
on-site analysis
• Scenario Scribe Writes scenarios on flipchart or whiteboard during scenario elicitation; captures
agreed-on wording of each scenario, halting discussion until exact wording is captured
• Proceedings Scribe Captures proceedings in electronic form on laptop or workstation: raw
scenarios, issue(s that motivate each scenario (often lost in the wording of the scenario itself), and
resolution of each scenario when applied to architecture(s); also generates a printed list of adopted
scenarios for handout to all participants
• Questioner Raises issues of architectural interest, usually related to the quality attributes in which
he or she has expertise
PROJECT DECISION MAKERS.

• These people are empowered to speak for the development project or

have the authority to mandate changes to it. They usually include the
project manager, and if there is an identifiable customer who is footing
the bill for the development, he or she may be present (or represented)
as well. The architect is always included—a cardinal rule of architecture
evaluation is that the architect must willingly participate.
ARCHITECTURE STAKEHOLDERS

• Unlike the evaluation team and the project decision makers,

stakeholders do not participate in the entire exercise.

• Their job during an evaluation is to articulate the specific quality

attribute goals that the architecture should meet in order for the
system to be considered a success
STEP 1: PRESENT THE ATAM

• The first step calls for the evaluation leader to present the ATAM to the
assembled project representatives. This time is used to explain the
process that everyone will be following, to answer questions, and to set
the context and expectations for the remainder of the activities. Using
a standard presentation, the leader describes the ATAM steps in brief
and the outputs of the evaluation.
STEP 2: PRESENT THE BUSINESS DRIVERS.

• In this step, a project decision maker (ideally the project manager or the
system’s customer) presents a system overview from a business perspective.
The presentation should describe the following:
• The system’s most important functions
• Any relevant technical, managerial, economic, or political constraints
• The business goals and context as they relate to the project
• The major stakeholders
• The architectural drivers (that is, the architecturally significant requirements)
STEP 3: PRESENT THE ARCHITECTURE.

• In this presentation the architect covers technical constraints such as operating

system, hardware, or middleware prescribed for use, and other systems with
which the system must interact. Most important, the architect describes the
architectural approaches.
Important architectural information (4–8 slides)
• Context diagram
• Module or layer view
• Component-and-connector view
• Deployment view
STEP 4: IDENTIFY ARCHITECTURAL
APPROACHES.
• During that step, the architect is asked to explicitly name the patterns
and tactics used, but the team should also be adept at spotting ones
not mentioned. In this short step, the evaluation team simply catalogs
the patterns and tactics that have been identified. The list is publicly
captured by the scribe for all to see and will serve as the basis for later
analysis
STEP 5: GENERATE QUALITY ATTRIBUTE
UTILITY TREE.
• In this step, the quality attribute goals are articulated in detail via a
quality attribute utility tree.
• In this step, the evaluation team works with the project decision
makers to identify, prioritize, and refine the system’s most important
quality attribute goals
STEP 6: ANALYZE ARCHITECTURAL
APPROACHES
• the evaluation team can identify and record a set of sensitivity points
and tradeoffs, risks, and nonrisks. At the end of step 6, the evaluation
team should have a clear picture of the most important aspects of the
entire architecture, the rationale for key design decisions, and a list of
risks, nonrisks, sensitivity points, and tradeoff points
STEP 7: BRAINSTORM AND PRIORITIZE
SCENARIOS.
• In this step, the evaluation team asks the stakeholders to brainstorm
scenarios that are operationally meaningful with respect to the
stakeholders’ individual roles
• Once the scenarios have been collected, they must be prioritized, for
the same reasons that the scenarios in the utility tree needed to be
prioritized:
STEP 8 AND 9: PRESENT RESULTS
• . In step 9, the evaluation team groups risks into risk themes, based on
some common underlying concern or systemic deficiency.
Then the following outputs are presented:
■ The architectural approaches documented
■ The set of scenarios and their prioritization from the brainstorming
■ The utility tree
■ The risks discovered
■ The nonrisks documented
■ The sensitivity points and tradeoff points found
■ Risk themes and the business drivers threatened by each one
LIGHTWEIGHT ARCHITECTURE EVALUATION

• we have developed a Lightweight Architecture Evaluation method, based on the

ATAM, for smaller, less risky projects.
• A Lightweight Architecture Evaluation exercise may take place in a single day, or even
a half-day meeting. It may be carried out entirely by members internal to the
organization.

• Because the participants are all internal to the organization and fewer in number than
for the ATAM, giving everyone their say and achieving a shared understanding takes
much less time. Hence the steps and phases of a Lightweight Architecture Evaluation
can be carried out more quickly.
CBAM- COST BENEFIT ANALYSIS METHOD

• . CBAM has for the most part been applied when an organization was
considering a major upgrade to an existing system and they wanted to
understand the utility and value for cost of making the upgrade, or
they wanted to choose between competing architectural strategies for
the upgrade. CBAM is also applicable for new systems as well,
especially for helping to choose among competing strategies.
DECISION MAKING CONTEXT - CBAM

• The most immediate economic implication of a business goal decision

on an architecture is how it affects the cost of implementing the
system. The quality attributes achieved by the architecture decisions
have additional economic implications because of the benefits (which
we call utility) that can be derived from those decisions; for example,
making the system faster or more secure or easier to maintain and
update. It is this interplay between the costs and the benefits of
architectural decisions that guides (and torments) the architect.
UTILITY-RESPONSE CURVES

• Our economic analysis uses quality attribute scenarios (from Chapter 4)

as the way to concretely express and represent specific quality
attributes. We vary the values of the responses, and ask what the utility
is of each response. This leads to the concept of a utility-response curve.
• We can portray each relationship between a set of utility measures and a
corresponding set of response measures as a graph—a utility-response
curve. Some examples of utility-response curves are shown in Figure. In
each, points labeled a, b, or c represent different response values. The
utility-response curve thus shows utility as a function of the response
value.
DETERMINING BENEFIT AND NORMALIZATION

• The overall benefit of an architectural strategy across quality attribute scenarios

is the sum of the utility associated with each one, weighted by the importance
of the scenario. For each architectural strategy i, its benefit Bi over j scenarios
(each with weight Wj) is
Bi = ∑j (bi,j × Wj )
• Referring to Figure each bi,j is calculated as the change in utility (over whatever
architectural strategy is currently in place, or is in competition with the one
being considered) brought about by the architectural strategy with respect to
this scenario:
bi,j = Uexpected – Ucurrent
• One method of weighting the scenarios is to prioritize them and use their
priority ranking as the weight. So for N scenarios, the highest priority one is
given a weight of 1, the next highest is given a weight of (N–1)/N, and so on
CALCULATING VALUE FOR COST

• The VFC for each architectural strategy is the ratio of the total benefit,
Bi, to the cost, Ci, of implementing it:
VFC = Bi / Ci
SOFTWARE PRODUCT LINES

• A software product line is a set of software-intensive systems that share a common,

managed set of features satisfying the specific needs of a particular market segment or
mission and that are developed from a common set of core assets in a prescribed way.
• The product line approach works because the core assets were built specifically to support
multiple members of the same family of products. Hence, reusing them is faster and less
expensive than reinventing those software assets for each new product or system in the
organization’s portfolio. Core assets, including the architecture, are usually designed with
built-in variation points—places where they can be quickly tailored in preplanned ways.
• Once the core assets are in place, system building becomes a matter of
■ Accessing the appropriate assets in the core asset base
■ Exercising the variation points to configure them as required for the system being built
■ Assembling that system
• The improvements in cost, time to market, and productivity that come with
a successful software product line can be breathtaking.
Consider:
■ Nokia credits the software product line approach with giving it flexibility
to bring over a dozen phones to market each year, as opposed to the three
or so it could manage before, all with an unprecedented variety of features.
■ Cummins, Inc., was able to reduce the time it takes to produce the
software for a diesel engine from about a year to about a week.
■ Hewlett-Packard builds products using one-quarter of the staff, in one-
third of the time, and with one twenty-fifth the number of defects,
compared with software built before the advent of software product line
engineering
HOW SOFTWARE PRODUCT LINE WORK?

• Requirements
• Architectural design.
• Software elements
• Modelling and analysis.
• Testing.
• Project planning artifacts.
• Requirements. Most of the requirements are common with those of earlier systems
and so can be reused
• . An architecture for a software system represents a large investment of time from the
organization’s most talented engineers
• Software elements are applicable across individual products. Element reuse includes
the (often difficult) initial design work. Design successes are captured and reused;
design dead ends are avoided, not repeated. This includes design of each element’s
interface, its documentation, its test plans and procedures, and any models (such as
performance models) used to predict or measure its behavior. One reusable set of
elements is the system’s user interface, which represents an enormous and vital set
of design decisions. And as a result of this interface reuse, products in a product line
usually enjoy the same look and feel as each other, an advantage in the marketplace.
• Performance models, schedulability analysis, distributed system issues (such as
proving the absence of deadlock), allocation of processes to processors, fault
tolerance schemes, and network load policies all carry over from product to product.
• Test plans, test processes, test cases, test data, test harnesses, and the
communication paths required to report and fix problems are already in
place.

• Project planning artifacts. Budgeting and scheduling are more

predictable because experience is a high-fidelity indicator of future
performance. Work breakdown structures need not be invented each
time. Teams, team size, and team composition are all easily
determined.
THE ROLE OF A PRODUCT LINE
ARCHITECTURE
A product line architect needs to consider three things that are unique to
product line architectures:
• Identifying variation points. This is done by using the scope definition
and product line requirements as input. The product line architect
determines where in the architecture variation points should be made
available to support the rapid building of products.
• Supporting variation points. This is done by introducing variation
mechanisms, which will be discussed in the next section.
• Evaluating the architecture for product line suitability, which will be
discussed later in this chapter.
STRATEGIES IN PRODUCT LINE

• There are two primary models for how an organization may grow a product line:
• In a proactive product line, an organization defines the family using a comprehensive definition of scope. They do this
not with a crystal ball but by taking advantage of their experience in the application area, their knowledge about the
market and technology trends, and their good business sense. The proactive model allows the organization to make the
most far-reaching strategic decisions. Explicitly scoping the product line allows you to look at areas that are
underrepresented by products already in the marketplace, make small extensions to the product line, and move quickly
to fill the gap. In short, proactive product line scope allows an organization to take charge of its own fate. Sometimes
an organization does not have the ability to forecast the needs of the market with the certainty suggested by the
proactive model. The proactive model also takes some time to define and implement, and in that time the organization
needs to continue to construct products.
• In a reactive product line, an organization builds the next member or members of the product family from earlier
products. This is best used when there is uncertainty of requirements. Perhaps the domain is a new one. Perhaps the
market is in flux. Or perhaps the organization cannot afford to build a core asset base that will cover the entire scope
all at once. In the reactive model, with each new product the architecture is extended as needed and the core asset
base is built up from what has turned out to be common. The reactive model puts much less emphasis on up-front
planning and strategic direction setting. Rather, the organization lets itself be taken where the market dictates. This is
an example of agile architecting, as described in Chapter 15.
INCREMENTAL VS. BIG BANG

• . If you are proactively building a product line, you still need to choose how to populate it: all at once or
incrementally over time. Populating the core asset base all at once is a strategy that has worked
successfully for some organizations. However, it tends to require all or nearly all of the 496 Part Four 25
—Architecture and Software Product Lines organization’s resources be focused on that task, at the
expense of new product production. A different approach is to populate the core asset base
incrementally, as circumstances and resources permit. Each product that goes out the door is built with
whatever core assets are available at the time. That means that early products will include software not
derived from core assets. But those products will still be better off (that is, faster to market, of higher
quality, and easier to maintain) than products built entirely from unique code. And it’s entirely possible
that some of the software unique to those early products can be extracted, adapted, and generalized to
become core assets themselves, thus helping populate the core asset base in a reactive fashion.
Knowing the various adoption models can help an organization choose the one that is right for it. For
example, the proactive model requires a heavier initial investment but less rework than the reactive
model. The reactive model relies exclusively on rework with little initial investment. Which model should
act as a guide for a particular organization depends on the business situation
TOP-DOWN VS. BOTTOM-UP

• Top-down adoption arises when a (typically high level) manager decrees that
the organization will use the approach. The problem is to get employees in
the trenches to change the way they work. Bottom-up adoption happens
when designers and developers working at the product level realize that
they are needlessly duplicating each other’s work and begin to share
resources and develop generic core assets. The problem is finding a
manager willing to sponsor the work and spread the technique to other parts
of the organization. Both approaches work; both are helped enormously by
the presence of a strong champion—someone who has thoroughly
internalized the product line vision and can share that compelling vision with
others. (It works better if the champion is in a position of some authority.)
SERVERLESS ARCHITECTURE: THE FUTURE OF SOFTWARE
ARCHITECTURE

• Evolution of Cloud Infrastructure

• Serverless Architecture Overview
• Serverless architecture is a new revolution in cloud computing.
Serverless architecture does not mean you do not need servers to run
the code. Serverless architecture means that the code will be run on
some third-party vendor’s serverless framework instead of your own
server.
• The serverless architecture works in two different ways: 1) Backend-as-
a-service (Baas) and 2) Function-as-a-service (FaaS).
SOFTWARE ARCHITECTURE IN FUTURE

• They will provide distributed platforms and control

fabrics. Hyperplexed architectures will usher in new platform
capabilities, supercharging the efficiency of software developers and
shortening applications’ time to market.
• Hyperplexed architectures will allow software developers to leverage
distributed infrastructure footprints transparently and natively, akin to
what hyperlocal cloud zones and modern content delivery networks are
doing for latency-sensitive applications and gaming. 
HYPERPLEXED ARCHITECTURES

• They will support multimodal experiences. Emerging software

applications increasingly support novel user experiences such as voice,
AR, VR, wearables, and touch. Gaming and front-end frameworks, such
as Unity 3D and React 360, are already changing to support these
experiences
• They will manage complex security challenges. Hyperplexed
software architectures will have much larger attack surface areas. The
highly distributed nature of the software and the use of open source
software will make applications harder to lock down, and security will
have to be an integral part of the software stack.
HYPERPLEXED ARCHITECTURES

• Software designs and architectures are, clearly, on the cusp of change.

Developing a new generation of software architectures will allow
companies to innovate faster, create new customer experiences, and
shift the economics of software development. Companies that rely on
legacy technologies and outdated approaches, however, will find
themselves at a disadvantage.
• Using hyperplexed enterprise software architectures is essential to reap
the benefits of the technological changes that are under way. 
THANK YOU