team situational awareness and architectural decision making with the software architecture...
DESCRIPTION
European Conference on Software Architecture (ECSA 2013) presentation on 4 July 2013 by Marcin NowakTRANSCRIPT
Team Situational Awareness andArchitectural Decision Making with the
Software Architecture Warehouse
Marcin Nowak and Cesare [email protected], [email protected]
Faculty of Informatics, University of Lugano, Switzerland
Team Situational Awareness andArchitectural Decision Making with the
Software Architecture Warehouse
Marcin Nowak and Cesare [email protected], [email protected]
Faculty of Informatics, University of Lugano, Switzerland
“The life of a software architect is a long and rapid succession of suboptimal design decisions
taken partly in the dark”*
3Philippe Kruchten
Good decisions
InformedSmart
4Panel discussion on Architecture Decisions, SATURN 2013 Mineapollis, Minesota
Good decisions
InformedSmart
5
Situational Awareness
“The perception of elements in the environment within a volume of time and space, the
comprehension of their meaning, and the projection of their status in the near future”*
6* Endsley, M.R. (1995b). Toward a theory of situation awareness in dynamic systems. Human Factors 37(1), 32–64
Situational Awareness
“The perception of elements in the environment within a volume of time and space, the
comprehension of their meaning, and the projection of their status in the near future”*
7* Endsley, M.R. (1995b). Toward a theory of situation awareness in dynamic systems. Human Factors 37(1), 32–64
Situational Awareness
8
Perception recognizemonitor
Comprehension make sense
Projection predict future
* Endsley, M.R. (1995b). Toward a theory of situation awareness in dynamic systems. Human Factors 37(1), 32–64
Assumption #1
Situational Awareness => good decisions
9
“[…] 86% of architectural decisions are group decisions.”
10* Difficulty of Architectural Decisions – A Survey with Professional Architects Dan Tofan, Matthias Galster, Paris Avgeriou, ECSA 2013
Assumption #2
No single architect has complete SA
11
Good decisions
InformedSmart
Consensual
12
Good decisions
InformedSmart
Consensual
13
Team Situational Awareness
“The degree to which every team member possesses the SA required for his or her
responsibilities”*
14* Endsley, M.R. (1995b). Toward a theory of situation awareness in dynamic systems. Human Factors 37(1), 32–64
Team Situational Awareness
“The degree to which every team member possesses the SA required for his or her
responsibilities”*
15* Endsley, M.R. (1995b). Toward a theory of situation awareness in dynamic systems. Human Factors 37(1), 32–64
Motivation
Team Situational Awareness => good collaborative decisions
16
Team Situational Awareness for Architecture Decisions
17
distributed decision space
decision metrics
decision process guidance
Perception
Comprehension
Projection
Reactive design document
18
Decision Space
Architect
Architect
Architect
Architect
Other stakeholders
Real-time sharing, collaborative decision making
Decision Space Comprehension
19
Decision Space Comprehension
20
QuestionableComplex
ObsoletePromising
Positive
Risky
Negative
ISO 42010 decision meta-model
21
ArchitectureElement
affectsArchitecture Decision
RationaleConcern
depends upon
pertains
raises
justifies
ISO 42010 decision meta-model
22
Issue
addressesAlternative
addresses
solvesArchitecture Decision
RationaleConcern
depends upon
pertains
raises
justifies
Argumentation viewpoint meta-model
23
Issue
addressesAlternative
addresses
solvesArchitecture Decision
RationaleConcern
depends upon
pertains
raises
justifies
Position
Action
StakeholderDecision Force
recommends
pertains states
Argumentation view example
24
AccountAccess
Security
Web Services Security
Mechanism
Design Issue
WS-Security
HTTPS
Plain text
Architecture Decision Design Alternatives
Compatibility issues
Heavyweight
Unsecure!
Simple
Practice proven
Stakeholder Positions
WS-Security
Argumentation view example
25
WS-Security
Design Issue Architecture Decision Design Alternatives
Compatibility issues
Heavyweight
Stakeholder Positions
AccountAccess
Security
Web Services Security
Mechanism
HTTPS
Plain text
Unsecure!
Simple
Practice provenHTTPS
Argumentation view example
26
Design Issue Architecture Decision Design Alternatives
HTTPS
WS-Security
Compatibility issues
Heavyweight
AccountAccess
Security
Web Services Security
Mechanism
Plain text
Unsecure!
Simple
Practice proven
Stakeholder Positions
HTTPS
Argumentation view example
27
Design Issue Architecture Decision Design Alternatives
Plain text
Unsecure!
Simple
Stakeholder Positions
HTTPS
WS-Security
Compatibility issues
Heavyweight
AccountAccess
Security
Web Services Security
Mechanism
Practice proven
Plain text
Position and alternative life cycle
28
No positions
Position and alternative life cycle
29
No positions Aligned Positions
Position and alternative life cycle
30
No positions Aligned Positions
Colliding Positions
Position and alternative life cycle
31
No positions
Sealed
Aligned Positions
Colliding Positions
Position and alternative life cycle
32
No positions
Sealed
Inconclusive positions Conclusive positions
Aligned Positions
Colliding Positions
Design Issue life-cycle
33
No Alternatives
Inconclusive Choice
Incomplete Choice
Conclusive Choice
Warring Choice
No Decisions
Design Issue life-cycle
34
No Alternatives
Inconclusive Choice
Complete choice
Incomplete Choice
Conclusive Choice
Warring Choice
No Decisions
Design Issue life-cycle
35
No Alternatives
Inconclusive Choice
Complete choice
Incomplete Choice
Conclusive Choice
Warring Choice
No Decisions
Plain text
HTTPS
WS-Security
AccountAccess
Security
Web Services Security
MechanismHTTPS
Design Issue life-cycle
Plain text
HTTPS
WS-Security
AccountAccess
Security
Web Services Security
MechanismHTTPS
No Alternatives
Inconclusive Choice
Complete choice
Incomplete Choice
Conclusive Choice
Warring Choice
No Decisions
36
Design Issue life-cycle
Plain text
HTTPS
WS-Security
AccountAccess
Security
Web Services Security
MechanismHTTPS
No Alternatives
Inconclusive Choice
Complete choice
Incomplete Choice
Conclusive Choice
Warring Choice
No Decisions
37
Design Issue life-cycle
38
Plain text
HTTPS
WS-Security
AccountAccess
Security
Web Services Security
MechanismHTTPS
No Alternatives
Inconclusive Choice
Complete choice
Incomplete Choice
Conclusive Choice
Warring Choice
No Decisions
38
Design Issue life-cycle
Plain text
HTTPS
WS-Security
AccountAccess
Security
Web Services Security
MechanismHTTPS
No Alternatives
Inconclusive Choice
Complete choice
Incomplete Choice
Conclusive Choice
Warring Choice
No Decisions
39
Software Architecture Warehouse
40
Formative Evaluation
41
• User-centric design• 2 yearly iterations (with students of “Software
Architecture and Design” master course)• 50+ co-located design workshops• 5-10 participants• 146 issues• 401 alternatives• 694 positions
41
Formative Evaluation Findings
42
• Connectivity• Position volatility• Decision space dynamics vary greatly• Need for decision process framing
(sealing, time-boxing)• Lack of collective attention focus• Multimodality of the decision discussion
42
Position revoking
43
43
Team re-focusing
44
44
Team re-focusing
45
45
Constraining decision-process
46
46
Constraining decision-process
47
47
Summary
48
• Documenting decision making process is as important as documenting decisions itself
• There is a lot to learn about how software architects make decisions (as a group)
48
Road ahead
49
• Decision metrics (in particular complex, graph metrics)
• Detection strategies (patterns and anti-patterns)
• Decision guidance models
49Perception
Comprehension
Projection
Team Situational Awareness andArchitectural Decision Making with the
Software Architecture Warehouse
Marcin Nowak and Cesare [email protected], [email protected]
Faculty of Informatics, University of Lugano, Switzerland
Public software architecture warehouse demo:http://demo.saw.sonyx.net
http://saw.inf.unisi.ch