at am method

7/27/2019 At Am Method

1/35

ATAM

Architecture Trade-off AnalysisMethod with case study

Bart Venckeleer, inno.com


2/35

2

SEI Software Architecture Tools and Methods

Active Reviews for Intermediate Designs (ARID)Architecture-Based System EvolutionArchitecture Competence AssessmentArchitecture Expert (ArchE)Architecture Tradeoff Analysis Method (ATAM)

Attribute-Driven Design (ADD) MethodCost Benefit Analysis Method (CBAM)Mission Thread WorkshopQuality Attribute Workshop (QAW)Views and Beyond Approach to Architecture Documentation


3/35

3

ATAM in relationship with other SEI methods

Active Reviewsfor IntermediateDesigns (ARID)

ArchitectureCompetence Assessment

ArchitectureTradeoff

Analysis Method(ATAM)

Cost Benefit Analysis Method

(CBAM)

Quality AttributeWorkshop

(QAW)

Views andBeyond

Approach to Architecture

Documentation

clarified qualityattribute

requirements


4/35

4

Why Architectural Analysis?

The earlier you find a problem

in a software project, the betteroff you are.

An unsuitable architecture willbring disaster on a project.

Architecture evaluation is acheap way to avoid disaster.


5/35

5

Architecture Trade-off Analysis Method

The ATAM is based upon a set of attribute-specific measures of thesystem

Analytic (performance & availability) Qualitative (modifiability, safety,

security)The ATAM workshops typically takesthree days and the involvement of 10-20 people

Evaluators Architects and other system stakeholders

Benefits: clarified quality attribute

requirements

improved architecturedocumentation documented basis for architectural

decisions identified risks early in the life-cycle increased communication among

stakeholders

An architecture evaluation doesnt tell you yes or no or 6,75 out of 10. It tells you were the risksare.


6/35

6

Risks, Nonrisks, Sensitivity Points andTrade-off Points

The latency for processing an important messagemight be sensitive to the priority of the lowestpriority process involved in handling the message.The average number of person-days of effort it takesto maintain a system might be sensitive to thedegree of encapsulation of its communicationprotocols and file formats.

If the processing of a confidential message has ahard real-time latency requirement then the level of encryption could be a trade-off point.

The rules for writing business logic modules in thesecond tier of your three-tier client-server style arenot clearly articulated. This could result in replicationof functionality, thereby compromising modifiabilityof the third tier (a quality attribute response and itsconsequences)

Assuming message arrival rates of once per second,a processing time of less than 30 milliseconds, and

the existence of one higher priority process, then aone-second soft deadline seems reasonable.

Risks are potentially problematic

architectural decisions.

Nonrisks are good decisions thatrely on assumptions that arefrequently implicit in thearchitecture.

A sensitivity point is a property of one or more components (and/orcomponent relationships) that iscritical for achieving a particularquality attribute response.

A trade-off point is a property thataffects more than one attribute andis a sensitivity point for more thanone attribute.


7/35


8/358

What Result Does an Architecture Evaluation Produce?

Answers to two kind of

questions:

Is the architecture suitable forthe system for which is wasdesigned?

Which of two or morecompeting architectures is themost suitable one for thesystem at hand?

suitable

It meets its quality goals

Predictable behaviour Performance Modifiable Security

The system can be built Staff

Budget Legacy Time

If the sponsor of a system cannot tell you what any of the quality goalsare for the system, then the architecture will do.


9/359

Summary of the ATAM Steps

Presentation

1. Present the methodEvaluation leader

2. Present business drivers12 slides; 45 min; guidelines forcontent; project manager

3. Present architecture

20 slides; 60 min; guidelines forcontent + checklist withquestions; architect

Investigation and Analysis4. Identify the architectural

approachesarchitect

5. Generate the qualityattribute utility tree

Workshop, templates for

utility tree and scenarios6. Analyse the architectural

approachesworkshop, templates forrisks, nonrisks, sensitivitypoints and trade-off pointsTesting

7. Brainstorm and prioritisescenariosVoting workshop

8. Analyse the architecturalscenarios

See step 6

Reporting9. Present the results

Document template;evaluation team


10/35

CASE Study: Purchase2Pay


11/35


12/3512

Purchase2Pay: Business Context and Drivers

Business environment Invoice documents that are received from business units worldwide

are centralized in one geographical location: Bratislava.

Bratislava is responsible forLabeling invoices

Scanning invoicesPosting the invoices to SAP

Invoice verification is performed by business workers in Europe


13/3513

Purchase2Pay : Business Context and Drivers

Driving requirements Every invoice must get a unique identification Every invoice must be stored electronically in a central repository Every invoice must be submitted to a verification process (review

and approval) Posters must make use of the electronic version of the invoice

Reviewers and approvers must make use of the electronic versionof the invoice

The lead time from invoice reception to invoice approval is lessthan one week


14/3514

Purchase2Pay: Business Context and Drivers

Major stakeholders and users Stakeholders

ProcurementFinanceLegal

U sersScannerPosterReviewerApprover


15/3515

Purchase2Pay: Business Constraints

Time to market Very fast

User demands Easy to use Fast

Standards SAP Documentum

Cost To be minimized


16/3516

Purchase2Pay: Technical Constraints

COTS SAP Documentum

Integration requirements SAP Documentum

Hardware requirements Run on current hardware and network infrastructure


17/3517

Purchase2Pay: Quality Attribute Requirements

Usability

E-documents can easily be read when displayed on screen

Availability Very High availability during Bratislava business hours High availability 24/7 for other business workers

Performance Throughput

Infrastructure must allow to process at least 400 invoices per hour every 9 seca request for a document upload is submitted; there will be a download every 3sec!

UI responsivenessaverage 5 sworse case 10 s


18/3518

Step 3: Present Architecture

Architect describes

Technical constraints Other systems involved Attribute specific architectural

approaches

Evaluation team notes Architectural approaches

used/mentioned Potential risks towards drivers Additional stakeholders

mentioned

1. Summary of architecture presentation

2. Updated list of stakeholder rolesfor phase 2

3. Second iteration on scopedefinition


19/3519

Purchase2Pay: Driving Architectural Requirements

COTS SAP Documentum

Cost

SAP client license cost

Load Bratislava

Avg document upload and download: 1 doc every 9 sec each

EuropeAvg document download: 1 doc every 3 sec


20/35

20

Purchase2Pay: High-level Architectural View

scan invoiceCaptiva

verify scanned documents

archive

inputQueue

e-connector task

SAP

sap invoice

archive

Windows 2000 OS

Documentum query

DocumentViewer

http

Verification & Approval Tool

http

Post Tool

service

Browser


21/35

21

Purchase2Pay: Trace Use case Scenario

: SIConfirmScan

: IDocumentumInputQueue

put(pfdFile)

: Win2000Scheduler : IP2PBuilder

start()

get()

: ISapInvoice

: ISapObjectFactory

newSapInvoice()

: IDocumentumArchive

setInvoiceDocumentReference()

setSapInvoiceReference

archiveDocument()

: IContent

createVerificationWorkflow()

: ISapVerificationWorkflow

setInitialProcessInput()


22/35


23/35


24/35


25/35

25

Step 5: Generate the Quality Attribute Utility Tree

Evaluation leader facilitates

Identification Prioritization Refinement to scenarios

Of most important qualityattributes.

Questioners are responsible To highlight important quality

attributes Point out difference between

generated and presented drivers

Listen for additionalstakeholders mentioned

Utility Performance

Data latency (M, L) Minimize storage latencyon customer DB to 200 ms

(H,M) Deliver video in real time

Transaction throughput (M,M) Maximize average

throughput to authenticationserver

ModifiabilityNew Product CategoriesChange COTS

(H,L) change web user interfacein < 4 person weeks

AvailabilityHardware Failure

(L,M) power output at site 1requires traffic redirect to site 3

in < 3 s (H,M) network failure is detected

and recovered in < 1,5 min

SecurityData confidentiality

(L,H) customer databaseauthorisation works 99,999% of time


26/35

26

Purchase2Pay: Quality Attribute Tree

QA-L1 QA- L2 BP TP Scenario

Performance Latency H H Opening a e-invoice for reading takes less that 3seconds from any site that is in scope of p2p

Performance Throughput H H Opening documents at a continuous rate of 2documents per second has average response time

better than 3 sec per doc for any of the sites inscope of p2p

Availability Overall H H A site that is disconnected due to network failure isre-connected with full bandwidth in less than 2hours

Availability Overall H M Hardware failure of one CPU in the infrastructurecomponents (SAP, Documentum) has no effecton realization of QA

Availability Overall H H There will be no more than 4 unavailabilitysituations per year


27/35

27

Step 6: Analyse the Architectural Approaches

Scenario: Detect and recover from HW failure of

prim CPUAttribute(s): AvailabilityEnvironment: Normal operationsStimulus: One CPU failsResponse: 99,999% availability

Architectural decisions

Arch.decision

Sensitivity Trade-off Risk Nonrisk

Backup CPUs S2 R8

No backupchannel

S3 T3 R9

Watchdog S4 N12

Heartbeat S5 N13

Failoverrouting

S6 N14


28/35

28

Step 7: Brainstorm and Prioritise Scenarios

Workshop to generate

Use case scenarios Expectations on usage of thesystem

Growth scenarios Expectations on growth of thesystem

Exploratory scenarios Expectations on huge change

Workshop to merge prioritize

Merge similar scenarios

#Votes = 30% of scenariosrounded up to even number

55 scenarios 18 votes

1. List of high priority scenarios 2. List of remaining scenario's3. Augmented utility tree4. List of risks, arising from

mismatch between high-priorityscenarios and utility tree


29/35

29

Step 8: Analyse the scenarios

See step 6

Arch.decision

Sensitivity trade-off Risk Nonrisk

Backup CPUs S2 R8

No backup

channel

S3 T3 R9

Watchdog S4 N12

Heartbeat S5 N13

Failoverrouting

S6 N14


30/35

30

Scenario: E-connector looses connection with SAP

Attribute: Availability-Overall Availability

Stimulus: Temporary network fault

Response: The system has an overall availability of 99,25% (max 2hour down/ month)

Architectural decision Sensitivity Trade-off Risk Non-risk

DCTM content serverruns on a clusteredenvironment with 2nodes

Commonmodefailure cannot behandled

Probability of commonmode failureis low

Integrationrelationship betweenSAP andDocumentum is 'dataconsistency and isnot protected

Human usermust reportmalfunction

Fromcomplainttoresolution> 2 hours


31/35

31

Scenario: Invoice poster needs e-document for data entry in SAP/R3

Attribute: Perfomance-Latency

Stimulus: Document request to Documentum

Response: Document is available for processing in less than 10 s

Architectural decision Sensitivity Trade-off Risk Non-risk

E-documents arescanned in color at200 dpi

Size of documentis sensitiveto quality of scanning

UsabilityvsPerformance

Documenttoo large forroundtrip in10 s.

E-documents are notcached

Everydocumentmust befetchedfrom DMTM

Developmentcost vsbandwidth cost

Documentroundtriptime exceeds10 s.


32/35


33/35

33

What Are the Benefits of Performing an ArchitecturalEvaluation?

Puts stakeholders in the same

roomForces an articulation of specificquality goalsResults in prioritization of conflicting goalsForces a clear explicitation of the architectureImproves the quality of architectural documentationUncovers opportunities for crossproject reuse

Results in improvedarchitectural practices


34/35


35/35

Inno.com experience

ATAM assessments are too often executed when it becomes clear that

the project can not be delivered Positive example seen at Alcatel Financial sector started to adopt ATAM recently

In general projects spend little effort during the requirementsworkflow to specify and analyze quality attribute requirements

The quality of a software system depends largely on de skills andexperience of individual developers

The preparation of a quality attribute workshops is extremelyimportant but also difficult and time consuming

Brainstorm relevant example quality attribute scenarios Be prepared to educate stakeholders while moving forward

Architectural documentation is sparse and often inaccurate

at am method

Documents