Chapter 6- Architecture and Business
Tadele M.
1
6.1 - Economic Analysis of Architectures
2
Basis for Economic Analyses
The development effort, the time and costs of complex systems
are considerably high.
Software analysis and evaluation becomes a well-established
practice inside the architecting community of the software
systems.
In order to assess system’s quality against the requirements of
its customers, the architects and the developers need methods
and tools to support them during the evaluation process.
3
Benefits & Costs of Architecture Evaluation
(+)Identifies and solves conflicting goals
(+) Forces clear explanation of architecture
(+) Puts stakeholders in the same room
(+) Improve quality of architecture documentation
(+) Uncovers opportunities for cross-project reuse
(+) Identifies risks early in the life cycle
(-) Costs time and money
4
Types of Architecture Evaluation
Technical: Evaluation against system quality attributes, e.g.
performance, security and modifiability, Suitability of design
decisions, E.g. Architecture Tradeoff Analysis Method
(ATAM).
Economic: Biggest tradeoffs in large complex systems
usually have to do with economics, cost and benefits
associated with architectural design decisions, E.g. Cost
Benefit Analysis Method (CBAM)
5
Cost-Benefit Analysis Method (CBAM)
CBAM is an architecture-centric method for analyzing the costs,
benefits and schedule implications of architectural decisions.
ATAM considered the design decisions with respect to
architectural quality attributes like modifiability, performance,
availability, usability, and so on.
CBAM is different from the former methods, it add the costs
(and implicit budgets or money) as quality attributes.
6
Context of CBAM
• The software architect or decision maker wishes to maximize
profits.
• These decisions should, as much as possible, maximize the
benefit that the system provides and minimize its cost.
7
CBAM
This approach asserts that architectural strategies (ASs) affect
the quality attributes (QAs) of the system and in turn provide
the stakeholders of the system with some benefit.
The benefit added to the system through the implementation of
an AS is referred to as utility.
Each AS provides a specific level of utility to the stakeholders,
and each AS has cost and schedule implications.
This information can aid the stakeholders in choosing ASs based
on their return on investment (ROI), which is the ratio of
benefit to cost.
8
CBAM Steps
9
10
Case Study: The NASA ECS Project
The Earth Observing System is a constellation of NASA
satellites that gathers data about the Earth for the U.S.
The Earth Core System (ECS) collects data from various
satellite downlink stations for further processing.
The mission of the ECS is to process the data into higher-
form information and make it available in searchable form to
scientists around the world.
The goals are to provide a common way to store and process
data and to provide a public mechanism for introducing the
new data formats and processing algorithms needed, thus making
the information widely available to the scientific community
at large.
The long-term nature of the project also makes modifiability
an important requirement.
11
Step 1: Collate Scenarios
Collate the scenarios elicited during the ATAM exercise,
and allow stakeholders to contribute new ones.
Prioritize these scenarios based on satisfying the business
goals of the system and choose the top one-third for
further study.
12
Step 1: Collate Scenarios…
13
Step 2: Refine Scenarios…
Refine the scenarios by focusing on their stimulus/response
measures.
Elicit the worst, current, desired, and best-case QA response level
for each scenario
14
Step 3: Prioritize Scenarios
• Allocate 100 votes to each stakeholder and have them distribute
the votes among the scenarios by considering the desired
response value for each scenario.
15
Step 4: Assign Utility
• Determine the utility for each QA response level (worst-case,
current, desired, or best-case) for all scenarios.
16
Step 5: Develop ASs for Scenarios and
Determine Their Expected Response Levels
Develop Architectural Strategies , and determine the
expected QA response levels that will result from
implementing these ASs.
Given that an AS may affect multiple scenarios.
17
Step 5: Develop ASs for Scenarios and
Determine Their Expected Response Levels…
18
Step 6: Determine Expected Utility
Levels by Interpolation
• Using the elicited utility values determine the utility of the "expected"
QA response level.
19
Step 7: Calculate the Total Benefit
Obtained from an AS
Subtract the utility value of the "current" level from the
"expected" level and normalize it using the votes elicited
in step 3.
Sum the benefit of a particular AS across all scenarios
and across all relevant QAs
20
Step 7: Calculate the Total Benefit
Obtained from an AS
21
Step 8: Choose ASs Based on ROI
Subject to Cost Constraints
To complete the analysis, the team estimated cost for each
architectural strategy.
The estimates were based on experience with the system,
and a return on investment for each architectural strategy
was calculated.
ROI =Benefit/Cost
Using the ROI, we were able to rank each strategy.
22
Step 8: Choose ASs Based on ROI
Subject to Cost Constraints…
23
Step 9: Confirm the results with intuition
Of the chosen ASs, consider whether these seem to align with
the organization's business goals.
If not, consider issues that may have been overlooked during the
analysis.
If significant issues exist, perform another iteration of these steps
24
6.2: Architecture Competence
Competence of Individuals
Duties
Skills Knowledge
Technical Duties of an Architect
General Duty Specific Duties
Creating an architecture
Evaluating and analyzing an architecture
Documenting an architecture
Architecting
Working with and transforming other
systems
Performing other architecting duties
Managing the requirements
Implementing the product
Other life cycle activities Testing the product
Evaluation future technologies
Selecting tools and technology
Non-Technical Duties of an Architect
General Duty Specific Duties
Managing the project
Management Managing the people
Supporting the management
Supporting the organization
Organization and business Supporting the business
related duties
Providing technical leadership
Leadership and team building Building a team
Skills of an Architect
General Skill Area Specific Skills
Outward
Communication skills Inward
Within team
Interpersonal skills With other people
Leadership
Workload management
Work skills Skills to excel in corporate environment
Skills for handling information
Skills for handling unexpected incidents
Knowledge of an Architect
General Knowledge Area Specific Knowledge
Architecture
Software Engineering
Computer Science knowledge Design knowledge
Programming knowledge
Specific knowledge
Technology and Platforms
General knowledge
Domain knowledge
Organization context and Industry knowledge
management Enterprise knowledge
Leadership and management techniques
Organizational Competence
It is not enough for the architect to be competent
The organizational setting is usually outside the control of
individual architects.
The architect must operate in an environment that
understands how to create/nurture/reward architects.
Some Examples of Activities by a
Competent Organization
Establish a career track for architects.
Establish a clear statement of responsibilities and authority
for architects.
Establish a mentoring program for architects.
Establish an architecture training/education program.
Include architecture milestones in project plans.
Have architects provide input into product definition.
Have architects advise on development team structure.
Give architects influence throughout the entire project life
cycle.
Reward or penalize architects based on project success or
failure.
Assessing an Organization
There are three practice areas that can be used to assess an
organization's competence.
Software Engineering
Technical Management
Organizational Management
Software Engineering
Organizations should have defined practices for
Quality Attribute Elicitation
Tools and Technology Selection
Modeling and Prototyping
Architecture Design, Description, and Evaluation
Software Design (design conforms to architecture)
Software Coding (code conforms to design and
architecture)
Software Verification and Testing
Technical Management
Organizations should have defined practices for
Business or Mission Goals
Setting functional requirements
Allocating Resources
Setting architect’s workload and schedule
Funding stakeholder involvement
Project plan structure aligned with architecture structure.
Adequate time planned for architecture evaluation.
Establish organization-wide architecture practices
Process monitoring and improvement
Reuse
Collaboration with manager
Organizational Management
Organizations should have defined practices for
Career track for Architects
Leadership roles for architects
Succession planning
Ongoing training
Creating and sustaining an internal community of
architects
Supporting participation in external communities
Organizational Planning
Technology Planning and Forecasting
6.3: Architecture and Product Lines
Product Lines of Software
A product line of software is:
a set of software-intensive systems sharing a common, managed
set of features that satisfy 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
Reuse
A product line represents strategic (planned) reuse.
A common set of assets (core assets) that includes
Requirements
Architecture
Test cases
Build scripts
Documentation
…
These assets are constructed specifically to support reuse.
What Makes Product Lines Work?
Planned reuse of
Requirements. Most of the requirements are common with those
of earlier systems and so can be reused.
Architectural design. For a new product, if quality goals are the
same then the architecture is largely the same.
Software elements. Software elements are applicable across
individual products because the architecture is the same across
products.
Modeling and analysis. 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.
What Makes Product Lines Work? - 2
Planned reuse of
Testing. 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.
and more…
Costs of Product Lines
Up front planning takes time.
It takes 2-3 systems to start seeing savings begin for product
lines.
Alternatively, the product line can be evolved when new
products are defined. But this may require rework of the
architecture.
Product Line Scope
Some products are in scope (white)
Some products are out of scope (speckled)
Some products need to be decided on a case by case basis
(lined)
c. d
Scope is a Critical Decision
Too broad a scope and the systems become difficult to design
and construct.
Too narrow a scope and there are too few systems to justify
the additional expense and complexity.
Scoping decisions made by
finding commonality and variation points among potential
products
interactions between marketing and the architect to define as
broad a scope as technically feasible without introducing
excessive cost when building products.
Evaluating a Product Line Architecture
Largely the same as a normal evaluation.
Special attention should be paid to variation points.
Can be applied to
core assets, to assess suitability for product line
instance architecture, to assess suitability for a particular
desired product.
Thank You !!
46
