Architectural Tradeoff and Analysis Method ATAM

1
Architectural Tradeoff and Analysis Method (ATAM)

• Thomas LaToza
• 9/16/2003
• CS 427

2
ATAM - Overview

• What is the ATAM?
• Applying ATAM should you?
• ATAM vs. agilism

3
What is the ATAM?

• Requirements communication / generation method
• Scenarios
• Scenario prioritization
• Architectural assessment method
• Architectural decisions assessed against
  scenarios
• Do both of these belong in the same meeting /
  done at the same time?
• A very formalized way for participants to
  communicate

4
Participants

• Evaluation team (3-5)
• competent, unbiased outsiders
• Decision makers (?)
• Architect
• Project manager
• Customer
• Stakeholders (12-15)
• Developers / testers
• Users
• Developers on related projects

5
Products

• Scenarios
• H/M/L decision maker priority
• H/M/L architect difficulty
• Characterize Architectural decisions as
• Sensitivity point quality / scenario supported
• Tradeoff point effects multiple qualities /
  scenarios
• Risk / nonrisk safe / not safe
• Communication / sense of community
• Business goals
• Architecture

6
Steps

• Phase 1 evaluators and decision makers 1 day
• Present
• ATAM
• Business drivers
• Architecture
• Identify architectural approaches
• Generate quality attribute utility tree
• Analyze architectural approaches
• Phase 2 add stakeholders 2 days
• Brainstorm and prioritize scenarios
• Analyze architectural approaches
• Present results
• Phase 3
• Analyze cost / benefit of ATAM

7
ATAM - Overview

• What is the ATAM?
• Applying ATAM should you?
• ATAM vs. agilism

8
ATAM vs. Agilism

• You can all come up with poster child projects
  ideal for either methodology
• Large project, stable requirements
• Small project, churning requirements
• Most projects arent one of these
• Mid size
• Larger, but loosely connected teams
• Requirements somewhat stable
• Many projects may be both at one time
• Should you use ATAM?
• Is there a middle ground? Some planning, some
  change

9
ATAM Cost / Benefit

• Cost
• 1 2 weeks of time for 8 10 highly paid
  people, 2 days for another 10-12 people
• Delays project start
• Forces development of architecture up front
• Benefit
• Financial saves money
• Forces prepartion / documentation / understanding
• Captures rationale
• Catch architectural errors before built
• Make sure architecture meets scenarios
• More general, flexible architecture
• Reduces risk

10
ATAM SE Beliefs

• Architecture is important
• it should be analyzed
• Architecture can be prescribed
• decisions should be analyzed
• Architecture is central for communicating
• it should be documented
• Architecture is expensive to change
• it is cheaper to analyze early
• Architecture affects the entire project
• many stakeholders should be involved
• Requirements can be understood early
• architecture should be designed to meet them

11
Agile SE Beliefs

• Individuals and interactions over processes and
  tools
• Working software over comprehensive documentation
  
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• Source www.agilemanifesto.org

12
Up front vs. continuous

• Stakeholder communication
• Vs. agilism lots of communication always
• Anticipate scenarios, perfect architectural
  qualities
• Vs. agilism react to in implemented code
• Team structure partition
• Vs. agilism collective ownership
• Requirements understood
• Vs. agilism information available now

13
ATAM vs. Agilism Beliefs

• Better up front
• (unanticipated, architectural) Change is
  expensive
• Change best made cheap by anticipation
• Personal communication is expensive
• Therefore ATAM

• Better later
• Change is cheap
• Change best made cheap by simplicity
• Personal communication is cheap
• Therefore piecemeal growth

14
Depends on

• Amount of requirements churn
• Size of team
• Experience of architect
• Incremental delivery of product
• Length of project
• Qualities desired

15
Better up front

• Partition teams and responsibilities
• Determining requirements errors
• Not wasting time changing a broken architecture
• Determining cost and qualities of finished system
• Analyzing risks

16
Better later

• Longer you can delay making a decision, the
  deeper the understanding and
• More likely it will be the correct one
• Easier it will be to make
• YAGNI requirements will likely be forgotten
• Requirements will likely be added
• Speculative generality extraneous abstraction /
  complexity from an anticipatory architecture
  increases construction cost and errors
• System is fully functional at all times for
  stories so far considered

17
Which true when?

• Partition teams and responsibilities
• Determining requirements errors
• Not wasting time changing a broken architecture
• Determining cost and qualities of finished system
• Analyzing risks

• Longer you can delay making a decision, the
  deeper the understanding and
• More likely it will be the correct one
• Easier it will be to make
• YAGNI requirements will likely be forgotten
• Requirements will likely be added
• Speculative generality extraneous abstraction /
  complexity from an anticipatory architecture
  increases construction cost and errors
• System is fully functional at all times for
  stories so far considered

• Depends on
• Amount of requirements churn
• Size of team
• Experience of architect
• Incremental delivery of product
• Length of project
• Qualities desired

18
(unanticipated, architectural) Change is
expensive

• Lots of documents to update to keep everything in
  sync
• Meetings to discuss importance of changes and if
  they are really needed (another ATAM?)
• Code and architecture may not be in sync, so must
  be careful
• As change wasnt anticipated, many other
  decisions may be affected
• Architecture, by definition, describes hard to
  change parts of system
• Code doesnt change often, so coding style may
  make change hard

19
Change is cheap

• Only minimal documentation to change
• Everyone can easily communicate to determine
  effects
• Refactoring makes mechanics cheaper and less
  error prone

20
Which true when?

• Lots of documents to update to keep everything in
  sync
• Meetings to discuss importance of changes and if
  they are really needed (another ATAM?)
• Code and architecture may not be in sync, so must
  be careful
• As change wasnt anticipated, many other
  decisions may be affected
• Architecture, by definition, describes hard to
  change parts of system
• Code doesnt change often, so coding style may
  make change hard

• Only minimal documentation to change
• Everyone can easily communicate to determine
  effects
• Refactoring makes mechanics cheaper and less
  error prone

• Depends on
• Amount of requirements churn
• Size of team
• Experience of architect
• Incremental delivery of product
• Length of project
• Qualities desired

21
Change best made cheap by anticipation

• It is possible to describe likely changes and
  design the architecture to support them.
• Change can be as simple as replacing a component
  with another.
• Arhcitectures successfully react to change by
  using modifiability tactics
• Maintain semantic coherence, generalize, limit
  options
• Prevent ripple effects
• Hide information / use indirection
• Maintain existing interfaces

22
Change best made cheap by simplicity

• Simple code
• Less duplication, less code, less to change
• Easier to understand, faster to change
• Everything needed by reqmts, so dont have to
  worry about throwing away functionality w/ out
  reqmt change

23
Which true when?

• It is possible to describe likely changes and
  design the architecture to support them.
• Change can be as simple as replacing a component
  with another.
• Arhcitectures successfully react to change by
  using modifiability tactics
• Maintain semantic coherence, generalize, limit
  options
• Prevent ripple effects
• Hide information / use indirection
• Maintain existing interfaces

• Simple code
• Less duplication, less code, less to change
• Easier to understand, faster to change
• Everything needed by reqmts, so dont have to
  worry about throwing away functionality w/ out
  reqmt change

• Depends on
• Amount of requirements churn
• Size of team
• Experience of architect
• Incremental delivery of product
• Length of project
• Qualities desired

24
Personal communication is expensive

• People may work at different times and in
  different locations
• People specialize on different projects and areas
  and have minimal common knowledge and concerns
• Getting all interested parties to communicate is
  expensive
• Need to prepare proper questions, materials, and
  documents to have useful interaction
• Those with the most knowledge, such as the
  architect or decision makers, are very busy
  people
• Easier to document everything so anyone can read
  it when they are interested

25
Personal communication is cheap

• Documentation is time consuming to create and
  maintain and should only be used when necessary
• Everyone working on project should be
  communicating all the time to do their job
  efficiently
• Dont have to try to communicate technical
  concerns to non developers, just qualities and
  stories of software
• Working system provides easy vehicle for
  communicating and verifying requirements

26
Which true when?

• People may work at different times and in
  different locations
• People specialize on different projects and areas
  and have minimal common knowledge and concerns
• Getting all interested parties to communicate is
  expensive
• Need to prepare proper questions, materials, and
  documents to have useful interaction
• Those with the most knowledge, such as the
  architect or decision makers, are very busy
  people
• Easier to document everything so anyone can read
  it when they are interested

• Documentation is time consuming to create and
  maintain and should only be used when necessary
• Everyone working on project should be
  communicating all the time to do their job
  efficiently
• Dont have to try to communicate technical
  concerns to non developers, just qualities and
  stories of software
• Working system provides easy vehicle for
  communicating and verifying requirements

• Depends on
• Amount of requirements churn
• Size of team
• Experience of architect
• Incremental delivery of product
• Length of project
• Qualities desired