SAF - An introduction

Arnon Rotem-Gal-Oz
Product Line Architect

www.rgoarchitects.com
What SAF isn’t
 Detailed guidance on how to design
your next architecture

 Detailed guidance on how to document

your next architecture

 Guidance on the Architect’s soft skills

 Prescriptive Process
So why do I need SAF

 Congratulations !!!
 You are the new lead Architect for Project X
What SAF is
 An Architecture Framework
 Activities – focus on needs
 Techniques to help accomplish the
activities

 Focused on Solution/Project
architecture
 Lightweight
 Core Activities
 S – identify Stakeholders
 P – set Principles, guidelines & constraints
 A – define quality Attributes
 M – Model
 M –Map to technology
 E – Evaluate
 D - Deploy
identify Stakeholders
The Usual Suspects
 Customer  Security Analysts
 End-User  Project New
 Project Manager comers
 Management
 Testers
 Developers
 Customer’s IT
group
 Maintainers
 Mapping Stakeholders

High

Keep Manage
Satisfied Closely

Concern
Importance
(or Power)
Monitor Keep
(Minimum Effort) Informed

low
low High
Interest
Based on Schekkerman - IEAD
set Principles, guidelines &
constraints
Principles & Guideline
 Set an direction for the solution

 Initial directions to consider for the

solution
Constraints
 constraints limit the (architectural) solution
space
 Vs. requirements that set goals for the
system

 Stakeholders should therefore not only

specify requirements, but also constraints!
Origins
 Past Experience
 Stakeholders
 Standards
 Company
 Customer
 International
Multiple Tiers (1/2)
principle example
 What – Hardware architecture,
deployment unto multiple computers

 Rationale/Benefits
 Easier to purchase, deploy, upgrade
 Easier to solve security, performance
issues
 Enables administrator specialization
Multiple Tiers (2/2)
principle example
 Implications
 Need to carefully consider
communications of
layers/components/services that cross
tier boundaries
 Alternatives
 Single-Tier
 N-Tiers (i.e. preset number of tiers)
 Scope
 Installable modules
Other examples
 Principles
 Layered architecture, federated database
 Guidance
 At least 2 threads on UI
 Constraints
 Technical – Platform/technology (e.g.
use .NET)
 Financial – Budget (don’t event think about
that fancy Rule Engine)
define quality Attributes
System Quality Attribute
 Performance
 Availability
 Time To Market
 Cost and Benefits
 Usability
End User’s view  Projected life time Business
 Security Community
 Targeted Market
 Integration with view
Legacy System
 Maintainabilit  Roll back
y Schedule
 Portability
Developer’s view
 Reusability
 Testability

A list of quality attributes exists in

ISO/IEC 9126-2001 Information Technology – Software Product Quality
Building a Utility Tree (1/2)

 decompose and refines the business

goals and quality attributes

 The root of the tree is “utility” – the

overall “goodness” of the system
Building a Utility Tree (2/2)
 Select the most important quality goals
to be the high-level nodes
 E.g. performance, modifiability, security,
and availability
 The tree reflects the hierarchical nature
of quality attributes and provides the
basis for prioritization
Adding Scenarios (1/2)
 Represent stakeholders’ interests
 weighted according to stakeholder consensus of
their relative importance
 Help Understand quality attribute
requirements
 Make the goals concrete and
measurable
 Reflect both run-time and non-run-time
considerations
Adding Scenarios (2/2)
 Scenarios should cover a range of
 Anticipated uses of (“use case”
scenarios),
 Anticipated changes to (growth
scenarios)
 Unanticipated stresses (“Soap opera
scenarios”) to the system.
 A scenario is a statement that incorporates
 A context; a stimulus; a response
 Scenarios should be as specific as possible.
Senarios Examples (1/3)
examples
 Use case scenario
Context Stimulus
 Under normal operation, perform a database transaction
in under 100 milliseconds.
Response
 Remote user requests a database report via the Web during peak
period and receives it within 5 seconds.

 Growth scenario
 Add a new data server to reduce latency in scenario 1 to 2.5
seconds within 1 person-week.
 For a new release, integrate a new component implementation in
three weeks.
 Exploratory scenario
 Half of the servers go down during normal operation without
affecting overall system availability.
Scenarios examples (2/3)
 Performance
 Response
 Under normal conditions update 100 moving
objects on the map < 200 milisecons
 Latency
 Under normal or stress conditions, a critical
alert generated by the system will be
displayed to the user in less than 1 second
 Data loss
 Under all conditions a message acknowledged
by the system shall not be lost (10^5
probability)
Scenarios example (3/3)
 Availability
 Hardware failure
 When a mission is in progress, upon a server
mal-function, the system will be fully operable
within 30 seconds or less
 Changeability
 Add Feature
 Add a new sensor-type to the system in 2
man-months or less
Model
Choose views
 To satisfy stakeholders’ concerns

 Minimal set of views

 System context
 Logical (e.g. Packages)
 Physical (e.g. Deployment)
Documentation & Presentation

 Keep “Barely good enough”

 Unless required otherwise by
customer/company standards

 Match the intended audience

Services & ESB take 1
id Serv ice View

«Service»
Alerts

UI

«Service»
ESB Ow nSite

«Service»
COP

«Service»
Nav igation
Services & ESB – take 2

Alerts

COP Navigatio
ESB n

UI Own
Site
Map to tools/technology
Mapping
 Work in lock-step with design

 Buy vs. Make vs. Reuse vs. Customize

 The wrong tools can compromise your

architecture / increase your costs
significantly
Example – Mapping
mismatch
 Management introduced a distributed
objects framework as a constraint
 Project decided on SOA

 A lot of energy & effort making the

distributed objects act like a message
bus
Evaluate
Evaluation Methods
 On Paper
 SEI
 ATAM; SAAM; ARID
 LAAAM
 Active Design Reviews
 In Code
 POCs
 Architectural prototype
 (GUI Prototype)
 Formal Evaluation Example
LAAAM
 Assessment Matrix
 Evaluate suitability of strategies against
scenarios Strategies
Value
Cost

Scenarios

Based on Jeromy Carriere

 LAAAM – Assessment Approach

 Each dimension is rated on a five point

scale, from High to Low
Value Development Cost Operations Cost
Low 0 2 2
Low-Moderate .5 1.5 1.5
Moderate 1 1 1
Moderate-High 1.5 .5 .5
High 2 0 0

 Each dimension is given a weight, to

express its importance relative to the other
dimensions
 Assessment is performed in two passes:
1. Treat each cell as independent
2. Normalize across each row
Based on Jeromy Carriere
 LAAAM – Example (1/2)

Strategy
A. Perform B. C. D.
no Incrementall Completel Completely
rearchitectin y wrap y port port
g. Maintain existing ABC existing existing
with minimal application ABC ABC
effort the components application applications
existing ABC in the model s to .NET. to J2EE,
application provided using
architecture. with .NET. existing
Introduce enterprise
no new frameworks.
dependencie
s on ABC
Scenario Analysis Weight components.
1. A new Value 1 Moderate Moderate- Moderate Moderate
application High
leverages the
Development 1.5 High Low High High
XYZ data store.
Cost
Operations 1 Low Low- Low Low-
Cost Moderate Moderate
Assessment 3 6 3 2.5
Based on Jeromy Carriere
 LAAAM – Example (2/2)

Scenario Analysis Weight A B C D

2. The XYZ Value 1 Low Moderate- High High
application's High
presentation
Development 1.5 N/A Moderate Moderate- Moderate-
is customized
Cost High High
by the user to
determine Operations 1 N/A Low- Low Low-
layout and Cost Moderate Moderate
content. Assessment 0 4.5 4.75 4.25

3. The peak Value 1 Low Moderate- High High

transaction High
rate for the
Development 1.5 High Low- Moderate- High
XYZ
Cost Moderate High
application
increases by Operations 1 High Moderate Low Moderate
10x (after Cost
scenario 2). Assessment 0 4.75 4.75 3

Based on Jeromy Carriere

Code Evaluation Examples
 POCs
 Service Broker suitability for POS
scenarios
 MSMQ vs. Tibco RV + EMS
 Prototype
 Moving the first serive to NHibernate
Deploy
Architecture Deployment
 Making sure the architecture really fits
the problem
 Making sure the architecture is
followed

 Tip: Short iterations allow for better

feedback loop
 Consider SCRUM’s 30 day sprints
 Spiral Process
Determ ine ob jectiv es
Ev aluate alt ern atives
alternatives and id en tify, resol ve risk s
cons traints Risk
analys is
Risk
analys is
Risk
analys is Opera-
Prot otyp e 3 ti onal
Prototyp e 2 prot oyp e
Risk
REVIEW analysis Prot o-
ty pe 1
Requi rements pl an Sim ul ati ons, m odels, b en ch marks
Li fe-cycle pl an Concept o f
Operation S/W
requi rements Prod uct
design Detail ed
Requi rement desi gn
Develop ment
pl an valid ati on Code
Desi gn Uni t t es t
Integrati on
and t est p lan V&V Integr ation
Plan next p has e test
Accep tance
Serv ice test Develop, v erify
next -l evel p rod uct

Bohem
Final Words
 SAF
 S – identify Stakeholders
 P – set Principles, guidelines & constraints
 A – define quality Attributes
 M – Model
 M –Map to technology
 E – Evaluate
 D - Deploy