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

2. What SAF isnt Detailed guidance on how to design your next architecture Detailed guidance on how to design your next architecture Detailed guidance on how to document your next architecture Detailed guidance on how to document your next architecture Guidance on the Architects soft skills Guidance on the Architects soft skills Prescriptive Process Prescriptive Process

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

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

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

6. identify Stakeholders

7. The Usual Suspects Customer Customer End-User End-User Project Manager Project Manager Management Management Developers Developers Maintainers Maintainers Security Analysts Security Analysts Project New comers Project New comers Testers Testers Customers IT group Customers IT group

8. Mapping Stakeholders low High low High ConcernImportance (or Power) Interest Monitor (Minimum Effort) KeepInformed KeepSatisfied ManageClosely Based on Schekkerman - IEAD

9. set Principles, guidelines & constraints

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

11. 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!

12. Origins Past Experience Past Experience Stakeholders Stakeholders Standards Standards Company Company Customer Customer International International

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

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

15. Other examples Principles Principles Layered architecture, federated database Layered architecture, federated database Guidance Guidance At least 2 threads on UI At least 2 threads on UI Constraints Constraints Technical – Platform/technology (e.g. use.NET) Technical – Platform/technology (e.g. use.NET) Financial – Budget (dont event think about that fancy Rule Engine) Financial – Budget (dont event think about that fancy Rule Engine)

16. define quality Attributes

17. System Quality Attribute Performance Performance Availability Availability Usability Usability Security Security Maintainabilit y Maintainabilit y Portability Portability Reusability Reusability Testability Testability End Users view Developers view Time To Market Time To Market Cost and Benefits Cost and Benefits Projected life time Projected life time Targeted Market Targeted Market Integration with Legacy System Integration with Legacy System Roll back Schedule Roll back Schedule Business Community view A list of quality attributes exists in ISO/IEC 9126-2001 Information Technology – Software Product Quality

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

19. Building a Utility Tree (2/2) Select the most important quality goals to be the high-level nodes Select the most important quality goals to be the high-level nodes E.g. performance, modifiability, security, and availability E.g. performance, modifiability, security, and availability The tree reflects the hierarchical nature of quality attributes and provides the basis for prioritization The tree reflects the hierarchical nature of quality attributes and provides the basis for prioritization

20. Adding Scenarios (1/2) Represent stakeholders interests Represent stakeholders interests weighted according to stakeholder consensus of their relative importance weighted according to stakeholder consensus of their relative importance Help Understand quality attribute requirements Help Understand quality attribute requirements Make the goals concrete and measurable Make the goals concrete and measurable Reflect both run-time and non-run-time considerations Reflect both run-time and non-run-time considerations

21. Adding Scenarios (2/2) Scenarios should cover a range of Scenarios should cover a range of Anticipated uses of (use case scenarios), Anticipated uses of (use case scenarios), Anticipated changes to (growth scenarios) Anticipated changes to (growth scenarios) Unanticipated stresses (Soap opera scenarios) to the system. Unanticipated stresses (Soap opera scenarios) to the system. A scenario is a statement that incorporates A scenario is a statement that incorporates A context; a stimulus; a response A context; a stimulus; a response Scenarios should be as specific as possible. Scenarios should be as specific as possible.

22. Senarios Examples (1/3) examples Use case scenario Under normal operation, perform a database transaction Under normal operation, perform a database transaction in under 100 milliseconds. in under 100 milliseconds. Remote user requests a database report via the Web during peak period and receives it within 5 seconds. Remote user requests a database report via the Web during peak period and receives it within 5 seconds. Growth scenario Growth scenario Add a new data server to reduce latency in scenario 1 to 2.5 seconds within 1 person-week. 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. For a new release, integrate a new component implementation in three weeks. Exploratory scenario Exploratory scenario Half of the servers go down during normal operation without affecting overall system availability. Half of the servers go down during normal operation without affecting overall system availability. ContextStimulus Response

23. Scenarios examples (2/3) Performance Performance Response Response Under normal conditions update 100 moving objects on the map < 200 milisecons Under normal conditions update 100 moving objects on the map < 200 milisecons Latency Latency Under normal or stress conditions, a critical alert generated by the system will be displayed to the user in less than 1 second 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 Data loss Under all conditions a message acknowledged by the system shall not be lost (10^5 probability) Under all conditions a message acknowledged by the system shall not be lost (10^5 probability)

24. Scenarios example (3/3) Availability Availability Hardware failure Hardware failure When a mission is in progress, upon a server mal-function, the system will be fully operable within 30 seconds or less When a mission is in progress, upon a server mal-function, the system will be fully operable within 30 seconds or less Changeability Changeability Add Feature Add Feature Add a new sensor-type to the system in 2 man-months or less Add a new sensor-type to the system in 2 man-months or less

25. Model

26. Choose Views IEEE 1471-2000

27. Choose views To satisfy stakeholders concerns To satisfy stakeholders concerns Minimal set of views Minimal set of views System context System context Logical (e.g. Packages) Logical (e.g. Packages) Physical (e.g. Deployment) Physical (e.g. Deployment)

28. Documentation & Presentation Keep Barely good enough Keep Barely good enough Unless required otherwise by customer/company standards Unless required otherwise by customer/company standards Match the intended audience Match the intended audience

29. Services & ESB take 1

30. Services & ESB – take 2 COP Alerts UI OwnSite Navigation ESB

31. Map to tools/technology

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

33. Example – Mapping mismatch Management introduced a distributed objects framework as a constraint Management introduced a distributed objects framework as a constraint Project decided on SOA Project decided on SOA A lot of energy & effort making the distributed objects act like a message bus A lot of energy & effort making the distributed objects act like a message bus

34. Evaluate

35. Evaluation Methods On Paper On Paper SEI SEI ATAM; SAAM; ARID ATAM; SAAM; ARID LAAAM LAAAM Active Design Reviews Active Design Reviews In Code In Code POCs POCs Architectural prototype Architectural prototype (GUI Prototype) (GUI Prototype)

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

37. LAAAM – Assessment Approach Each dimension is rated on a five point scale, from High to Low Each dimension is rated on a five point scale, from High to Low Each dimension is given a weight, to express its importance relative to the other dimensions Each dimension is given a weight, to express its importance relative to the other dimensions Assessment is performed in two passes: Assessment is performed in two passes: 1. Treat each cell as independent 2. Normalize across each row Value Development Cost Operations Cost Low022 Low-Moderate.51.51.5 Moderate111 Moderate-High1.5.5.5 High200 Based on Jeromy Carriere

38. LAAAM – Example (1/2) Strategy ScenarioAnalysisWeight A. Perform no rearchitectin g. Maintain with minimal effort the existing ABC application architecture. Introduce no new dependencie s on ABC 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 J2EE, using existing enterprise frameworks. 1. A new application leverages the XYZ data store. Value1Moderate Moderate- High ModerateModerate Development Cost 1.5HighLowHighHigh Operations Cost 1Low Low- Moderate Low Assessment3632.5 Based on Jeromy Carriere

39. LAAAM – Example (2/2) ScenarioAnalysisWeight ABCD 2. The XYZ application's presentation is customized by the user to determine layout and content. Value1Low Moderate- High HighHigh Development Cost 1.5N/AModerate Moderate- High Operations Cost 1N/A Low- Moderate Low Assessment04.54.754.25 3. The peak transaction rate for the XYZ application increases by 10x (after scenario 2). Value1Low Moderate- High HighHigh Development Cost 1.5High Low- Moderate Moderate- High High Operations Cost 1HighModerateLowModerate Assessment04.754.753 Based on Jeromy Carriere

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

41. Deploy

42. Architecture Deployment Making sure the architecture really fits the problem Making sure the architecture really fits the problem Making sure the architecture is followed Making sure the architecture is followed Tip: Short iterations allow for better feedback loop Tip: Short iterations allow for better feedback loop Consider SCRUMs 30 day sprints Consider SCRUMs 30 day sprints

43. Spiral Process Risk analysis Risk analysis Risk analysis Risk analysis Proto- type 1 Prototype 2 Prototype 3 Opera- tional protoype Concept of Operation Simulations, models, benchmarks S/W requirements Requirement validation Design V&V Product design Detailed design Code Unit test Integration test Acceptance test Service Develop, verify next-level product Evaluate alternatives identify, resolve risks Determine objectives alternatives and constraints Plan next phase Integration and test plan Development plan Requirements plan Life-cycle plan REVIEW Bohem

44. Final Words

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