The architecture business cycle
Download
1 / 58

The Architecture Business Cycle - PowerPoint PPT Presentation


  • 1016 Views
  • Updated On :

The Architecture Business Cycle. Paul C. Clements Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 Sponsored by the U.S. Department of Defense © 1998 by Carnegie Mellon University. Carnegie Mellon University. Software Engineering Institute. 1.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The Architecture Business Cycle' - LeeJohn


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
The architecture business cycle l.jpg

The Architecture Business Cycle

Paul C. Clements

Software Engineering Institute

Carnegie Mellon University

Pittsburgh, PA 15213-3890

Sponsored by the U.S. Department of Defense

© 1998 by Carnegie Mellon University

Carnegie Mellon University

Software Engineering Institute

1


The importance of architecture l.jpg
The Importance of Architecture

  • To a project

    • vehicle for stakeholder communication

    • key to achieving system qualities

    • basis for development project structure

  • To an organization

    • can be reused from project to project

    • forms a basis for product lines

    • is a foundation for new market entry

  • To a community

    • standard models emerge for mature domains

    • is a basis for component markets


Definition of software architecture l.jpg
Definition of Software Architecture

  • The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.


Communication vehicle l.jpg
Communication Vehicle

  • Architecture provides a common frame of reference in which competing interests may be exposed and negotiated.

    • negotiating requirements with users

    • keeping the customer informed of progress and cost

    • implementing management decisions and allocations


Result of early design decisions 1 l.jpg
Result of Early Design Decisions -1

  • An architecture defines constraints on an implementation.

    • implementations must conform to architecture

    • (global) resource allocation decisions constrain implementations of individual components

    • system trade-offs are in the architectural realm


Result of early design decisions 2 l.jpg
Result of Early Design Decisions -2

  • The architecture dictates organizational structure for development/maintenance efforts. Examples include

    • division into teams

    • units for budgeting, planning

    • basis of work breakdown structure

    • organization for documentation

    • organization for CM libraries

    • basis of integration

    • basis of test plans, testing

    • basis of maintenance

  • Once decided, architecture is extremely hard to change!


Result of early design decisions 3 l.jpg
Result of Early Design Decisions -3

  • Architecture permits/precludes achievement of a system’s desired quality attributes. For example:

  • If you desire Examine

  • performance inter-component communication

  • modifiability component responsibilities

  • security inter-component communication,

  • specialized components (e. g., kernels)

  • scalability localization of resources

  • ability to subset inter-component usage

  • reusability inter-component coupling

  • The architecture influences qualities, but does not guarantee them.


Result of early design decisions 4 l.jpg
Result of Early Design Decisions -4

  • An architecture helps users reason about and

  • manage change (about 80% of effort in systems

  • occurs after deployment).

  • Architecture divides all changes into three classes.

    • local: modifying a single component

    • non-local: modifying several components

    • architectural: modifying the gross system topology, communication, and coordination mechanisms

  • A good architecture is one in which the most likely changes are also the easiest to make.


Reusable model l.jpg
Reusable Model

  • Less is more: It pays to restrict the vocabulary of design alternatives.

  • Architectural styles serve as that restricted vocabulary of design alternatives.

  • Working with known styles

    • reduces learning time

    • enhances communication

    • takes advantage of known style properties (e.g., performance, security, reliability)


Where do architectures come from l.jpg
Where do architectures come from?

  • Architectures are influenced by

    • stakeholders of the system(s) being built

    • technical and organizational factors

    • architect’s background


Stakeholders l.jpg
Stakeholders

  • Customer: wants low cost, quick delivery, …

  • End user: wants functionality, usability, ...

  • Maintainer: wants modifiability, ...

  • Developer: wants understandability, simple interfaces, ...

  • Developing organization: amortizing infrastructure, employing personnel, low cost, ...

  • ...


Stakeholders of a system l.jpg

Development

organization’s

management

stakeholder

Maintenance

organization

stakeholder

End user

stakeholder

Customer

stakeholder

Behavior,

performance,

security,

reliability!

Modifiability!

Low cost,

keeping people

employed, leveraging

existing corporate

assets!

Neat features,

short time to market,

low cost, parity with

competing products!

Low cost, timely

delivery, not changed

very often!

Architect

Ohhhhh...

Stakeholders of a System

Marketing

stakeholder


Technical environment l.jpg
Technical Environment

  • Current trends: today’s information system will likely employ a

    • database management system

    • Web browser for delivery and distribution across platforms

  • This was not true 10 years ago.

  • Available technology: decisions on using a centralized or decentralized system depend on processor cost and communication speed; both are changing quantities.


Architect s background l.jpg
Architect’s Background

  • Architects develop their mindset from their past experiences.

    • Prior good experiences will lead to replication of prior designs.

    • Prior bad experiences will be avoided in the new design.


Summary influences on the architect l.jpg

Architect’s influences

Stakeholders

Requirements

Architect(s)

Development

organization

Architecture

Technical

environment

System

Architect’s

experience

Summary: Influences on the Architect


Factors influenced by architectures l.jpg
Factors Influenced by Architectures

  • Structure of the development organization

  • Enterprise goals of the development organization

  • Customer requirements

  • Architect’s experience

  • Technical environment

  • The architecture itself


Architecture influences the development organization structure l.jpg
Architecture Influences the Development Organization Structure

  • Short term: Work units are organized around architectural units for a particular system under construction.

  • Long term: When company constructs collection of similar systems, organizational units reflect common components

    • e.g., operating system unit or database unit

    • especially true in product line organization


Architecture influences the development organization s enterprise goals l.jpg
Architecture Influences the Development Organization’s Enterprise Goals

  • Development of a system may establish a foothold in the market niche.

  • Being known for developing particular kinds of systems becomes a marketing device.

  • Architecture becomes a leveraging point for additional market opportunities and networking.


Architecture influences customer requirements l.jpg
Architecture Influences Customer Requirements Enterprise Goals

  • Knowledge of similar fielded systems leads customers to ask for particular features.

  • Customers will alter their requirements on the basis of the availability of existing systems.


Architecture influences the architect s experience and technical environment l.jpg
Architecture Influences the Architect’s Experience and Technical Environment

  • Creation of a system affects the architect’s background.

  • Occasionally, a system or an architecture will affect the technical environment.

    • the WWW for information systems

    • the three-tier architecture for database systems


A cycle of influences l.jpg
A Cycle of Influences Technical Environment

  • Architectures and organizations influence each other.

    • Influences to and from architectures form a cycle.

    • An organization can manage this cycle to its advantage.


Architecture business cycle abc l.jpg

Architect’s influences Technical Environment

Stakeholders

Requirements

Architect(s)

Development

organization

Architecture

Technical

environment

System

Architect’s

experience

Architecture Business Cycle (ABC)


Importance of the abc l.jpg
Importance of the ABC Technical Environment

  • Recognizing architecture as a capital asset

    • develop it with care

    • develop it with more than one system in mind

    • keep it, nurture it, grow it, use it later

  • Looking for new business opportunities that architecture opens up

  • Planning and managing the feedback cycle


Example of abc product lines l.jpg
Example of ABC: Product Lines Technical Environment

  • Architecture enables entire suite of products to be built more efficiently

  • Case study: CelsiusTech AB of Sweden


Abc for celsiustech l.jpg
ABC for CelsiusTech Technical Environment

Architect’s influences

Customer and end user

Various navies

Requirements

(Qualities)

Fault tolerance

Tailorability

Asset reuse

Time to market

Developing organization

CelsiusTech

Architect(s)

Architecture

Technical environment

Ada

Object orientation

Iterative development

System

SS2000 products

Architect’s experience

Real-time embedded C3I


Celsiustech s software architecture l.jpg
CelsiusTech’s Software Architecture Technical Environment

  • Two dominant styles

    • layered architecture to separate application-specific software from software used across the entire product line

    • blackboard style to decouple producers and consumers of data

  • Both styles promote modifiability and reusability.


Layered architecture l.jpg

Target Technical Environment

tracking

Fire

control

General applications:

100% Ada

ASC

ECM

Operator’s console

Common application

Common applications:

100% Ada

Picture compilations

IPC

Fundamentals

Fundamentals:

95% Ada, 5% assembly language

Tactical

configuration

Common

functions

Diagnostics

Database

LAN

IPC

Base system 2000:

10% Ada, 90% C

OS-2000

Base system architecture

Layered Architecture


Runtime blackboard architecture l.jpg

Track information Technical Environment

Updates

Updates

Data-providing

application

COOB

HCI

Requests

Requests

Track-ball updates

Runtime Blackboard Architecture

  • Similar to A-7E data banker module


Current members of product family l.jpg
Current Members of Product Family Technical Environment

  • Sold 55 variants in SS2000 product family

    • Swedish Goteborg class Coastal Corvettes (KKV) (380 tons)

    • Danish SF300 class multi-role patrol vessels (300 tons)

    • Finnish Rauma class Fast Attack Craft (FAC) (200 tons)

    • Australian/New Zealand ANZAC frigates (3225 tons)

    • Danish Thetis class Ocean Patrol vessels (2700 tons)

    • Swedish Gotland class A19 submarines (1330 tons)

    • Pakistani Type 21 class frigates

    • Republic of Oman patrol vessels

    • Danish Niels Juel class corvettes


Result of changes shrinking predictable schedules l.jpg

A Technical Environment

B

C

D

E

F

G

Ships

1986

1992

1996

1988

1990

1994

Result of Changes:Shrinking, Predictable Schedules


Result of changes lower staffing l.jpg

200 Technical Environment

180

160

140

120

100

80

60

40

20

0

1986

1987

1990

1992

1988

1989

1991

1993

1994

1995

1996

Result of Changes: Lower Staffing


Result of changes reuse l.jpg

140 Technical Environment

120

100

80

60

40

20

0

Number of System Modules

E

D

C

B

  • A

Ships

Unique application

Modified

Common (verbatim)

National application

Reusable application

Result of Changes: Reuse


Abc feedback loop l.jpg
ABC Feedback Loop Technical Environment

  • CelsiusTech is now exploring other domains in which their architecture and product line approach offers promise.

  • Air defense sector: Surprise! 40% of brand new system could be lifted verbatim from SS2000.


How is architecture based development different l.jpg
How is architecture-based development different? Technical Environment

  • The architecture-specific aspects of system creation include:

    • forming an organizational structure that supports/reflects architecture

    • architecture design process

      • using reference models and domain models

      • using patterns and styles

      • building skeletal system, incremental development

    • architecture evaluation

    • checking for conformance


Can we evaluate an architecture l.jpg
Can We Evaluate an Architecture? Technical Environment

  • Yes. Since architecture

    • is the key to system qualities

    • involves decisions relevant to achieving those qualities

    • is not a random process

  • it follows that we can evaluate architectural decisions for their effect on qualities.

  • Analyzing for system qualities early in the life cycle allows for a comparison of architectural options.


Why evaluate an architecture l.jpg
Why evaluate an architecture? Technical Environment

  • All design involves tradeoffs. Not all tradeoffs are optimal (or anywhere near). Architecture is the earliest artifact where trade-offs are visible.

  • A evaluation ensures that:

    • the right questions are asked . . . early

    • tradeoff points are explicitly identified

  • Since architecture has such a profound effect on the success/failure of a project, evaluating an architecture is cheap risk insurance.


Cost of architecture evaluations l.jpg
Cost of architecture evaluations Technical Environment

  • AT&T

    • 300 full-scale reviews done on projects of 700 staff-days or longer

    • average cost per review: 70 staff days

  • Rational Software

    • 30 reviews done on projects gteq 500 KSLOC each

    • average cost per review: $50,000

  • SEI SAAM evaluations

    • ~15 reviews done on projects ranging from 100 KSLOC to 1,000 KSLOC

    • average cost per review: 14 to 20 staff-days

    • average length of review: 2 days


Example of indirect staff costs l.jpg
Example of Indirect Staff Costs Technical Environment

  • Using senior designers for evaluations instead of designing

  • Loss of productivity (due to reassignment of superior designers)

  • Time spent training staff in review techniques


Benefits of architectural reviews l.jpg
Benefits of Architectural Reviews Technical Environment

  • Five different types of benefits result from holding architectural reviews.

  • 1. financial

  • 2. forces preparation for review

  • 3. early detection of problems

  • 4. validation of requirements

  • 5. improved architectures


Financial benefits of reviews l.jpg
Financial Benefits of Reviews Technical Environment

  • AT&T estimated that each reviewed project saves 10% of total cost as a result of the review. Thus, a 70-staff-day review of projects of 700 staff-days pays for itself.

  • Consultants who perform architecture evaluations report 80% repeat business.


Forces preparation for review l.jpg
Forces Preparation for Review Technical Environment

  • Documentation/specifications must be provided, hence they must exist or be created.

  • Some reviews use standard questions, and the architect can prepare ahead to ensure that the architecture scores well.

  • Reviews make the criteria for evaluation explicit by prioritizing requirements or quality goals.


Early detection of problems l.jpg
Early Detection of Problems Technical Environment

  • The problems that can be found by an architectural level inspection include

    • unreasonable requirements

    • performance problems

    • problems associated with potential future modifications

  • The earlier in the life cycle that problems are found, the easier it is to fix them.


Validation of requirements l.jpg
Validation of Requirements Technical Environment

  • Reviews put stakeholders in the same room with each other, often for the first time.

    • uncovers conflicts and tradeoffs

    • provides a forum for negotiated resolution of problems

  • It often results in the generation of new requirements or the clarification of existing requirements.


Improved architectures l.jpg
Improved Architectures Technical Environment

  • Development organizations anticipate types of questions raised at reviews and

    • design architectures with questions in mind

    • prepare documentation of the type needed at review

    • give explicit consideration to qualities to be reviewed


Review techniques l.jpg
Review Techniques Technical Environment

  • There are a variety of techniques for performing architectural reviews; each has a different cost and provides different information.

  • These techniques fall into one of two basic categories.

  • 1. questioning techniques: applied to evaluate any aspect of an architecture for any given reason

  • 2. measuring techniques: applied to answer questions about a specific quality


Architecture tradeoff analysis method atam l.jpg
Architecture Tradeoff Analysis Method (ATAM) Technical Environment

  • ATAM is an architecture evaluation method that focuses on multiple quality attributes. In doing so, it:

    • illuminates points in the architecture where quality attribute sensitivities & tradeoffs occur

    • generates a framework for ongoing quantitative analysis


Atam and risks l.jpg
ATAM and Risks Technical Environment

  • The point of an ATAM analysis is not to provide precise analyses . . . the point is to discover areas of high potential risk in the architecture.

  • We want to find trends: correlations between architectural parameters and measurable properties.

  • These areas can then be made the focus of risk mitigation activities: e.g. further design, further analysis, prototyping.


Atam benefits l.jpg
ATAM Benefits Technical Environment

  • We have observed a number of benefits to performing ATAM analyses:

    • stakeholder buy-in and interaction

    • clarified requirements

    • improved architecture documentation

    • documented basis for architectural decisions

  • And, obviously, improved architectures.


Atam steps l.jpg
ATAM Steps Technical Environment

  • The ATAM takes 3 days to execute

  • Each day follows the same set of steps, but with different emphases:

Day 0 Day 1 Day 2

Scenario Elicitation

Architecture Elicitation

& Mapping

Analysis


Day 0 information exchange l.jpg
Day 0: Information Technical EnvironmentExchange

  • Purpose: to elicit or refine architectural descriptions, to identify stakeholders, to develop scenarios and initial analyses.

  • Activities:

    • identify important quality attributes

    • document “seed” scenarios

    • identify stakeholders needed at evaluation

    • create initial representations of the architecture

    • define homework for the architect

  • Outcome: an analyzable architecture


Day 1 skeleton analyses l.jpg
Day 1: Skeleton Analyses Technical Environment

  • Purpose: to generate a baseline model that characterizes each quality attribute

  • Activities: [On a per attribute basis]

    • Elicit attribute-specific usage scenarios

    • Map important usage scenarios onto relevant architectural views

    • Attribute annotation/Skeleton analysis building

    • Sensitivity point identification

    • Initial tradeoff point identification

  • Outcome: qualitative analyses of all important quality attributes


Attribute analysis taxonomies l.jpg

Internal Technical Environment

External

event

event

Attribute Analysis Taxonomies

Performance

Stimulus

Architecture Parameters

Response

Source

Mode

Frequency Regularity

Periodic

Aperiodic

regular

overload

Clock

interrupt

Random

Sporadic

params:

period

e.g.,

e.g.,

e.g.,

missile

message

load balancing

params:

params:

detected

arrival

min inter-arrival

distribution

interval


Attribute analysis taxonomies53 l.jpg

queuing per Technical Environment

processor

Attribute Analysis Taxonomies

Performance

Stimulus

Architecture Parameters

Response

Resource

Resource Arbitration

Resource Consumption

off-line

on-line

devices/

network

sensors

cyclic

fixed

params:

dynamic

executive

priority

bandwidth

priority

CPU

queuing

memory

preemption

policy

policy

params:

queue

params:

MB

MIPS

locking

shared

deadline

(non-preemptable)

(preemptable

one-to-one

one-to-many

SJF

fixed

FIFO

priority


Attribute analysis taxonomies54 l.jpg

variability Technical Environment

window

Attribute Analysis Taxonomies

Performance

Stimulus

Architecture Parameters

Response

Latency

Throughput

Precedence

Criticality

Ordering

Best/avg/worst

jitter

Best/avg/

worst case

Response

case

window

Criticality

Partial

Total

Criticality


Day 2 finding tradeoffs l.jpg
Day 2: Finding Tradeoffs Technical Environment

  • Purpose: to identify growth areas via sensitivities and tradeoffs

  • Activities:

    • Attribute-specific growth scenario elicitation and prioritization

    • Mapping of growth scenarios onto architecture

    • Sensitivity point identification

    • Tradeoff point identification

  • Outcome: potential sensitivity/tradeoff risk areas of the architecture identified


Experience to date 1 l.jpg
Experience to date - 1 Technical Environment

  • SAAM

    • ~15 evaluations to date

    • supporting artifacts (process model, handbook, tips and guidance, seed scenarios, artifact examples)

    • good for functionality / modifiability investigations

    • good for eliciting, prioritizing specific quality requirements

    • good for eliciting architectural description


Experience to date 2 l.jpg
Experience to date - 2 Technical Environment

  • ATAM

    • 4 evaluations so far, 6-10 more planned

    • precise method is still firming up

    • handbook being written

    • customer feels good value is given

    • good at non-run-time qualities plus run-time qualities (SAAM is a procedural subset)


Conclusions l.jpg
Conclusions Technical Environment

  • Architecture is a fundamental asset in software development.

  • Companies who manage it and let it work to their benefit are discovering pay-off.

  • Architecture-based development must be matured as a discipline.

  • A key aspect of architecture-based development is architecture evaluation.


ad