Architecture for Disaster Resistant Systems @I TAKE Unconference 29 05 2015
•Download as ODP, PDF•
2 likes•1,202 views
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.
Recommended
Recommended
More Related Content
Similar to Architecture for Disaster Resistant Systems @I TAKE Unconference 29 05 2015
Similar to Architecture for Disaster Resistant Systems @I TAKE Unconference 29 05 2015 (20)
More from Adi Bolboaca
More from Adi Bolboaca (20)
Recently uploaded
Recently uploaded (20)
Architecture for Disaster Resistant Systems @I TAKE Unconference 29 05 2015
- 1. Architecture for Disaster Resistant Systems - Resilience (materials science) - www.mozaicworks.com
- 2. Me Adi Bolboacă Programmer Organizational & Technical Trainer & Coach www.mozaicworks.com
- 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
- 5. Architecture = -Ἀρχιτέκτων ἀρχι τέκτων Architect = chief builder 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
- 10. Deployment & Risk Management 1. Assess 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
- 24. Aviation - Measurements Pilots use tools to continously assess the current situation 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 architecturewww.mozaicworks.com
- 29. Aviation - Practices www.mozaicworks.com - From Lufthansa magazine - Always pair when a high risk is involved!
- 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
- 33. Questions? www.mozaicworks.com Let's talk at Open Space as well!
- 34. Thank you! adrian.bolboaca@mozaicworks.com Twitter: @adibolb Blog: blog.adrianbolboaca.ro www.mozaicworks.com See the slides at http://www.slideshare.net/adibolb
- 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