SAF — An introduction Arnon Rotem-Gal-Oz Product Line

SAF - An introduction Arnon Rotem-Gal-Oz Product Line Architect www. rgoarchitects. com

What SAF isn’t l Detailed guidance on how to design your next architecture l Detailed guidance on how to document your next architecture l Guidance on the Architect’s soft skills l Prescriptive Process

So why do I need SAF l Congratulations !!! Ø You are the new lead Architect for Project X

What SAF is l An Architecture Framework Ø Ø l Activities – focus on needs Techniques to help accomplish the activities Focused on Solution/Project architecture Ø Lightweight

Core Activities l l l l 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 l l l Customer End-User Project Manager Management Developers Maintainers l l Security Analysts Project New comers Testers Customer’s IT group

Mapping Stakeholders High Keep Satisfied Manage Closely Monitor Keep Informed Concern Importance (or Power) (Minimum Effort) low Based on Schekkerman - IEAD Interest High

set Principles, guidelines & constraints

Principles & Guideline l Set an direction for the solution l Initial directions to consider for the solution

Constraints l constraints limit the (architectural) solution space Ø l Vs. requirements that set goals for the system Stakeholders should therefore not only specify requirements, but also constraints!

Origins l l l Past Experience Stakeholders Standards Ø Ø Ø Company Customer International

Multiple Tiers principle example (1/2) l What – Hardware architecture, deployment unto multiple computers l Rationale/Benefits Ø Ø Ø Easier to purchase, deploy, upgrade Easier to solve security, performance issues Enables administrator specialization

Multiple Tiers principle example l Implications Ø l Need to carefully consider communications of layers/components/services that cross tier boundaries Alternatives Ø Ø l (2/2) Single-Tier N-Tiers (i. e. preset number of tiers) Scope Ø Installable modules

Other examples l Principles Ø l Guidance Ø l Layered architecture, federated database 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 l l l l Performance Availability Usability End User’s view Security Maintainabilit y Portability Developer’s view Reusability Testability l l l Time To Market Cost and Benefits Projected life time Targeted Market Integration with Legacy System Roll back Schedule Business Community view A list of quality attributes exists in ISO/IEC 9126 -2001 Information Technology – Software Product Quality

Building a Utility Tree (1/2) l decompose and refines the business goals and quality attributes l The root of the tree is “utility” – the overall “goodness” of the system

Building a Utility Tree (2/2) l Select the most important quality goals to be the high-level nodes Ø l 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) l Represent stakeholders’ interests Ø l l l 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) l l 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 Ø l A context; a stimulus; a response Scenarios should be as specific as possible.

Senarios Examples (1/3) examples l Use case scenario Context Ø Stimulus Under normal operation, perform a database transaction in under 100 milliseconds. Response Ø l Growth scenario Ø Ø l Remote user requests a database report via the Web during peak period and receives it within 5 seconds. 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) l Performance Ø Response § Ø Latency § Ø Under normal conditions update 100 moving objects on the map < 200 milisecons 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) l Availability Ø Hardware failure § l 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 l To satisfy stakeholders’ concerns l Minimal set of views Ø Ø Ø System context Logical (e. g. Packages) Physical (e. g. Deployment)

Documentation & Presentation l Keep “Barely good enough” Ø l Unless required otherwise by customer/company standards Match the intended audience

Services & ESB take 1

Services & ESB – take 2 Alerts COP Navigation ESB UI Own Site

Map to tools/technology

Mapping l Work in lock-step with design l Buy vs. Make vs. Reuse vs. Customize l The wrong tools can compromise your architecture / increase your costs significantly

Example – Mapping mismatch l l l 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 l On Paper Ø SEI § Ø Ø l ATAM; SAAM; ARID LAAAM Active Design Reviews In Code Ø Ø Ø POCs Architectural prototype (GUI Prototype)

Formal Evaluation Example LAAAM l Assessment Matrix Ø Evaluate suitability of strategies against scenarios Strategies Value Cost Scenarios Based on Jeromy Carriere

LAAAM – Assessment Approach l Each dimension is rated on a five point scale, from High to Low Value 0 2 2 Low-Moderate . 5 1. 5 Moderate 1 1 1 Moderate-High 1. 5 . 5 High l Operations Cost Low l Development Cost 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. 2. Treat each cell as independent Normalize across each row Based on Jeromy Carriere

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

LAAAM – Example (2/2) Scenario Analysis 2. The XYZ application's presentation is customized by the user to determine layout and content. Value 3. The peak transaction rate for the XYZ application increases by 10 x (after scenario 2). Value Development Cost Operations Cost Weight A B C D 1 Low Moderate. High 1. 5 N/A Moderate -High 1 N/A Low. Moderate 0 4. 5 4. 75 4. 25 1 Low Moderate. High 1. 5 High Low. Moderate -High 1 High Moderate Low Moderate 0 4. 75 3 Assessment Development Cost Operations Cost Assessment Based on Jeromy Carriere

Code Evaluation Examples l POCs Ø Ø l Service Broker suitability for POS scenarios MSMQ vs. Tibco RV + EMS Prototype Ø Moving the first serive to NHibernate

Deploy

Architecture Deployment l l l 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 alternatives and cons traints Risk analys is Ev aluate altern atives id en tify, resol ve risk s Risk analys is REVIEW Requi rements pl an Life-cycle plan Develop ment pl an Plan next p has e Bohem Integrati on and test p lan Prototyp e 3 Prototyp e 2 Risk analysis Prototy pe 1 Operational protoyp e Sim ul ati ons, m odels, b en ch marks Concept o f Operation S/W requi rements Requi rement valid ati on Prod uct design Detailed desi gn Code Uni t t es t Desi gn V&V Integr ation test Accep tance test Develop, v erify Serv ice next-l evel p rod uct

Final Words

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