Architecture Business Cycle
CSSE 477 Software Architecture
Steve Chenoweth, Rose-Hulman Institute
Monday, Sep 5, 2011
SA Ch 1
1
Today
• Start the general topics in SA
– Background for the specific skills you’ll build
• 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”)
2
Outline
• Vasa – first of many case histories
– We learn from others’ mistakes!
– Critical thinking’s finest hour?
• Architecture Business Cycle
• Advice and Rules of Thumb for "Good"
Architecture
Naval architecture is an interesting analogy to software architecture,
as we’ll see…
3
History of the Vasa
• January 1625: Initial
•
•
•
•
contract
Early 1626: Accelerated
schedule as building
commenced
Later 1626: Ship size
increased
1627: Shipwright died
August 1628: Maiden
voyage
4
Schedule Pressure
• Original project was to take 4 years
• Shorter schedule demanded by King 
• Ship builders opted to extend small
ship rather than start over
Gustav II Adolf
5
Changing Requirements
• 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
Sigismund
(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!)
6
No Written Specifications
• Original ship was familiar to ship builders
• Scaling up was done without written
specifications
7
No Written Plan
• 3 "managers" worked without written
plans
• Shipwright died during project
• 400 people working in 5 different groups:
largest project in Sweden at this time
8
Missing Science
• 17th century ship builders could only
measure stability and heeling
characteristics by trial
• Center of gravity could not be predicted
accurately
9
Cross-Section of Vasa
10
Failed Stability Test
• Lurch test conducted by 30 men running
back and forth on deck
• Test stopped when it became clear that
ship would capsize
• Neither of the 2 remaining project
managers attended the test
11
Result - on Maiden Voyage :
12
Stakeholders
• Developing Organization
•
•
•
•
Management
Marketing
End User
Maintainenace
Organization
Customer
13
Architecture Business Cycle
• Stakeholders
• Developing
•
•
Organization
Technical
Environment
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
14
Architecture Activities – § 1.2
• Creating business case
• Understanding requirements
• Creating or selecting architecture
• Documenting and communicating
architecture
• Analyzing architecture
• Implementing system
• Ensuring conformance of implementation
15
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 .
16
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!
17
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/cgibin/awimage? dir=2001/0718&article=culture_12.html&image= 11474_image_3.jpg.
18
Architecture Process Advice - § 1.3
(3/3)
We’ll continue doing this!
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
19
"Good" Architecture Rules of
Thumb - § 1.3 (1/3)
1. Use information hiding to hide
You did these!
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)
20
"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.
21
"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
22