1. 1 Architecture Business Cycle CSSE 477 Software Architecture Steve Chenoweth, Rose-Hulman Institute Monday, Sep 5, 2011 SA Ch 1

2. 2 Today Start the general topics in SA Start the general topics in SA –Background for the specific skills you’ll build Time to work on Project 1 in class Time to work on Project 1 in class –Add to your journal, a quantitative analysis of the opportunities to improve performance, –Like the example from Friday’s slides. –Turn in, on Angel, by end of today (11:55 PM) – –Just added - See the example journal and spreadsheet from last year's class, in the same directory as this file, so you'll know what I am looking for! These are as-of the final turnin for this first project. Tonight – Vote for the grading scheme (on Angel Lessons, under “Your input, and surveys”)

3. 3 Outline Vasa – first of many case histories Vasa – first of many case histories –We learn from others’ mistakes! –Critical thinking’s finest hour? Architecture Business Cycle Architecture Business Cycle Advice and Rules of Thumb for "Good" Architecture Advice and Rules of Thumb for "Good" Architecture Naval architecture is an interesting analogy to software architecture, as we’ll see…

4. 4 History of the Vasa January 1625: Initial contract January 1625: Initial contract Early 1626: Accelerated schedule as building commenced Early 1626: Accelerated schedule as building commenced Later 1626: Ship size increased Later 1626: Ship size increased 1627: Shipwright died 1627: Shipwright died August 1628: Maiden voyage August 1628: Maiden voyage

5. 5 Schedule Pressure Original project was to take 4 years Original project was to take 4 years Shorter schedule demanded by King  Shorter schedule demanded by King  Ship builders opted to extend small ship rather than start over Ship builders opted to extend small ship rather than start over Gustav II Adolf

6. 6 Changing Requirements King asked for larger size to accommodate more guns (Big war with Poland, not always going so well) King asked for larger size to accommodate more guns (Big war with Poland, not always going so well) Eventually asked for 2 decks of guns Eventually asked for 2 decks of guns (The Polish-Swedish wars started in 1600, over whether Sigismund was the rightful king of Sweden. It began as an internal struggle in Sweden, which Sigismund lost, but he also was king of Poland!) Sigismund

7. 7 No Written Specifications Original ship was familiar to ship builders Original ship was familiar to ship builders Scaling up was done without written specifications Scaling up was done without written specifications

8. 8 No Written Plan 3 "managers" worked without written plans 3 "managers" worked without written plans Shipwright died during project Shipwright died during project 400 people working in 5 different groups: largest project in Sweden at this time 400 people working in 5 different groups: largest project in Sweden at this time

9. 9 Missing Science 17th century ship builders could only measure stability and heeling characteristics by trial 17th century ship builders could only measure stability and heeling characteristics by trial Center of gravity could not be predicted accurately Center of gravity could not be predicted accurately

10. 10 Cross-Section of Vasa

11. 11 Failed Stability Test Lurch test conducted by 30 men running back and forth on deck Lurch test conducted by 30 men running back and forth on deck Test stopped when it became clear that ship would capsize Test stopped when it became clear that ship would capsize Neither of the 2 remaining project managers attended the test Neither of the 2 remaining project managers attended the test

12. 12 Result - on Maiden Voyage :

13. 13 Stakeholders Developing Organization Management Developing Organization Management Marketing Marketing End User End User Maintainenace Organization Maintainenace Organization Customer Customer

14. 14 Architecture Business Cycle Stakeholders Stakeholders Developing Organization Developing Organization Technical Environment Technical Environment Architect's Experience Architect's Experience Steve’s useful heuristic for “what it’s like” – It’s “technical leadership” : ½ social activity, in the middle of everyone else, listening to & selling ideas ½ creating great designs that lead to success

15. 15 Architecture Activities – § 1.2 Creating business case Creating business case Understanding requirements Understanding requirements Creating or selecting architecture Creating or selecting architecture Documenting and communicating architecture Documenting and communicating architecture Analyzing architecture Analyzing architecture Implementing system Implementing system Ensuring conformance of implementation Ensuring conformance of implementation

16. 16 Architecture Process Advice - § 1.3 (1/3) 1. Architecture should be product of a single architect or small group with identified leader University of Oregon’s TeachEngineering System Vision and Design team. From test.teachengineering.org/founding_partner s.php. test.teachengineering.org/founding_partner s.php

17. 17 Architecture Process Advice - § 1.3 (1/3) 2. Architect should have functional requirements and a prioritized list of quality attributes 3. Architecture should be well-documented with at least one static and one dynamic view We’ll be doing this!

18. 18 Architecture Process Advice - § 1.3 (2/3) 4. Architecture should be circulated to stakeholders, who are active in review 5. Architecture should be analyzed (quantitatively and qualitatively) before it is too late. In the building trades, an architect also consults with the clients and users: Curtis J. Moody, FAIA, Columbus, OH architect, reviewing building plans with school principal Monica Grant. From web site http://www.architecture week.com/cgi- bin/awimage? dir=2001/0718&article=culture_1- 2.html&image= 11474_image_3.jpg.

19. 19 Architecture Process Advice - § 1.3 (3/3) 6. System should be developed incrementally from an initial skeleton that includes major communication paths 7. Architecture should result in a small number of specific resource contention areas We’ll continue doing this!

20. 20 "Good" Architecture Rules of Thumb - § 1.3 (1/3) 1. Use information hiding to hide computing infrastructure 2. Each module should protect its secrets with a good interface 3. Use well-known architecture tactics to achieve quality attributes –E.g., for performance – Resource demand, management, or arbitration (see Friday) You did these!

21. 21 "Good" Architecture Rules of Thumb - § 1.3 (2/3) 4. Minimize and isolate dependence on a particular version of a commercial product or tool. 5. Separate producer modules from consumer modules. –MVC is a good example of that! 6. For parallel-processing, use well-defined processes or tasks.

22. 22 "Good" Architecture Rules of Thumb - § 1.3 (3/3) 7. Assignment of tasks or processes to processors should be easily changeable (even at runtime) 8. Use a small number of simple interaction patterns