Aviation has learned how to deal with risks and we can learn from their experience in Software. This talk is about how to apply some of the Aviation concepts into Software Architecture.
3. Disaster Resistant System
A system's degree of resistance to
disasters is a measurement of its
stability under stress conditions
caused by the outside environment
or by the people who manipulate it.
www.mozaicworks.com
4. We will talk about
● Software Architecture
● Fligtht safety vs Product safety
● Risk management in Aviation vs Software
● Briefing in Aviation vs Software
● Checklists
● Measurements for fast feedback
● Tools and techniques to avoid disasters
www.mozaicworks.com
6. Pilot – Authority and
Responsibility
● Operate aircraft according to regulations
● Operate within the aircraft limitations
● Refuse any unsafe flight
● Evaluate and approve or refuse missions
● Before departure understands request
● Have all resources to perform flight
www.mozaicworks.com
7. Architect – Authority and
Responsibility
● Focus on non-functional requirements (security,
maintainabiliy, extensibility, scalability, usability, etc)
● Help the teams create standards
● Enforce standards
● Maximize reusage
● Modularize system with feedback from the stakeholders
(eg. product roadmap, usability tests)
● Work closely with teams and code with them
● Adapt architecture depending on the feedback
● Responsible for the system's health (Architecture
Stewardship)
www.mozaicworks.com
8. Aviation – Risk Management
Is a five-step process
1. Identify the Hazard
2. Asses the Hazard / Risk
3. Make a Risk Decision
4. Implement Controls
5. Supervize / Evaluate
www.mozaicworks.com
9. Architect – Risk Management
1. Assess
2. Brainstorm
3. Assign probability
4. Estimate impact
5. Decide which to consider
6. Create contingency plan
7. Create guidelines
8. Gather feedback on guidelines
9. Enforce guidelines
10. Go to 1.
www.mozaicworks.com
11. Deployment & Risk Management
2. Brainstorm
1. Risk: Security between GUI and WS
2. Risk: Communication to Hospitals DB
3. Risk: Storage API to stop working
4. Risk: GUI to stop working
5. Risk: Cloud storage to stop working
6. Risk: WS stops working
7. Risk: ...
www.mozaicworks.com
12. Deployment & Risk Management
3. Assign Probability
www.mozaicworks.com
13. Deployment & Risk Management
4. Estimate Impact
1. Risk: Security between GUI and WS → HIGH
2. Risk: Communication to Hospitals DB → HIGH
3. Risk: Storage API to stop working → MEDIUM
4. Risk: GUI to stop working → HIGH
5. Risk: Cloud storage to stop working → HIGH
6. Risk: WS stops working → HIGH
7. Risk: ...
www.mozaicworks.com
14. Deployment & Risk Management
5. Decide Which to Consider
1. Risk: Security between GUI and WS → HIGH
2. Risk: Communication to Hospitals DB → HIGH
3. Risk: Storage API to stop working → MEDIUM
4. Risk: GUI to stop working → HIGH
5. Risk: Cloud storage to stop working → HIGH
6. Risk: WS stops working → HIGH
7. Risk: ...
www.mozaicworks.com
15. Deployment & Risk Management
6. Create Contingency Plan
Risk: GUI to stop working → HIGH
● Measure the live system performance
● Message suport when it fails
● When service stops, start automatically another
service
● If service cannot be started, create new machine,
start service and reroute to new machine
● Message support if failure continues for more than 5
minutes
www.mozaicworks.com
16. Deployment & Risk Management
7. Guidelines
● Always create a deployment script
● Use the deployment script to automatically spawn
new service
● Always log
● Always message support about system failure
www.mozaicworks.com
17. Deployment & Risk Management
All these practices help us to
minimize the risks
www.mozaicworks.com
18. Aviation – Checklist Usage
The checklists are used:
a) Before engine start
b) Before Starting
c) Before takeoff
d) Cruise
e) Before landing
f) After landing
g) Engine shutdown
www.mozaicworks.com
19. Checklist – Before Engine Start
● Auxiliary fuel pump — Off
● Flight controls — Free and correct
● Instruments and radios — Checked and set
● Landing gear position lights — Checked
● Altimeter — Set
● Directional gyro — Set
● Fuel gauges — Checked
● Trim — Set
● Propeller — Exercise
● Magnetos — Checked
● Engine idle — checked
● Flaps — As required
● Seat belts/shoulder harnesses — Fastened
● Parking brake — Off
www.mozaicworks.com
20. Architecture – Checklist Usage
What if we use checklists:
a) Before project start
b) Before kick-off project
c) Before first sprint
d) During development
e) Before deployment
f) After deployment
g) For retrospective
www.mozaicworks.com
21. Checklist – Before Project Starts
● Requirements are clear
● Customer needs are identified
● Final user types (personas) are identified
● Architecture sketch finalized: system
diagram, deployment diagram
● Architecture reviewed by another architect
● Architecture reviewed by QA
● Architecture reviewed by Operations
www.mozaicworks.com
22. Checklist – Before kick-off
● We have the minimum architecture
● The team members know their roles and
responsibilities
● We have all the necessary roles in the team
● The team understand the business concept
● We have enough hardware in place
● All the software tools are installed and ready
www.mozaicworks.com
23. Checklist – Before First Sprint
● We have enough requirements clarified
● The team read and understood the
requirements for the next period
● The architecture is clear to the team
● We have architecture guidelines in place
● Standards and team rules have been
defined and improved with the team
www.mozaicworks.com
25. Architecture - Measurements
Architects should use appropriate metrics
and tools to continously assess the current
situation
The difference: metrics need to be
chosen
www.mozaicworks.com
26. Architecture - Measurements
Number of failing tests: Integration,
Performance, Security, etc
Automated = current situation
Hint: Always prefer automated metrics
www.mozaicworks.com
27. Architecture - Standards
● Code standards per language
● Code review standards
● Tool usage standards (ie commit at least
once per day)
Hint: use automated tools to enforce
code standards (ie Sonar, Code Cop)
www.mozaicworks.com
28. Architecture - Policies
● Security Policies
● Always encrypt when outside the LAN
● Programming policies
● Do not return null, always use Null Object Pattern
● Process Policies
● When the architecture is not helping, talk with the
architect(s) immediately
● The team takes decisions about the detailed
architecture
www.mozaicworks.com
30. Architecture - Practices
www.mozaicworks.com
● Code review
● Architecture review
● Pair-programming
● Team feedback
● Continous improvement
All these practices minimize the risks
and make the system resistant to
disasters
31. General Guideline
Pilots Architects should not allow
themselves to be persuaded to
attempt anything against their better
judgment.
When in doubt,
don't!
(Operations and Safety Procedures Guide for Helicopter Pilots, page 25)
www.mozaicworks.com
32. Disaster Resistant Systems
www.mozaicworks.com
A system is disaster resistant if we:
● Perform risk management before and
during the project
● Use checklists to minimize mistakes
● Continously assess risks and rate impact
● Use transparency and honesty in the team
● Use always our better judgement
36. Extend your mentoring & training
capacity
Accelerate learning through
communities of practice
Grow your functional leaders and top
talents
http://www.mozaicworks.com
adrian.bolboaca@mozaicworks.com
@adibolb