preso slidedeck

Click here to load reader

Post on 16-Aug-2015

11 views

Category:

Technology

0 download

Embed Size (px)

TRANSCRIPT

  1. 1. Matt Osbun Email: [email protected] Google+: +MattOsbun Twitter: @MattOsbun LinkedIn (Wait for it): MattOsbun Software developer 11 years Software Architect 4 years Insurance, mortgage, book publishing, B2B, B2C
  2. 2. Software Architecture Its about Marcus Aurelius, not Microservices
  3. 3. The One Thing Software Architecture is risk management for applications, without which acronyms, architecture strategies and quotes from a certain Stanford CS professor will hinder more than help.
  4. 4. But Its All So Simple!
  5. 5. You Never Know...
  6. 6. DRY, YAGNI, Just in case, are useful- Until theyre not
  7. 7. MVC, DI, TDD, SOA, etc, are useful- Unless theyre not
  8. 8. Steve Perry 1. Matador series 2. Star Wars 3. Aliens 4. Conan
  9. 9. GRASP General Responsibility Assignment Software Patterns Computer scientist Craig Larman states that "the critical design tool for software development is a mind well educated in design principles. It is not the UML or any other technology. Protected Variation: Protecting elements from changes to other elements. Creating a design for a software project This is incidental
  10. 10. Responsibilities: - Designed masonry work - Selected tools and stone to use - Supervised work of other masons Completely Incidental The Master Mason As an Architect: - Select Technologies - Create Overall Design - Oversee Work - Responsible for Domain Knowledge
  11. 11. Dr. Hannibal Lecter "No. That's incidental. What's the first and principal thing he does, what need does he serve?" This is not incidental Software Architecture is about problem solving
  12. 12. Foreseeable and Imaginary Change Architecture that protects from foreseeable change has foreseeable value. Architecture that protects from imaginary change has imaginary value. The single hardest part of a software architects job is deciding what changes are foreseeable and what changes are imaginary.
  13. 13. Marcus Aurelius "This, what is it in itself, and by itself, according to its proper constitution? What is the substance of it? What is the matter, or proper use? What is the form, or efficient cause? What is it for in this world, and how long will it abide? Thus must thou examine all things that present themselves unto thee." Experience lies. Examine everything.
  14. 14. Once you know who you are, you know what you have to do 1. With requirements, ask Why do we need this? in order to define what is really needed. 2. With designs, ask What is it for in this world in order to define what a system does. Without knowing what something is and why it is needed, you cannot accurately judge what changes are foreseeable and what are imaginary.
  15. 15. Case Study Questions 1. What problem was this application written to solve? 2. Why did these insurance policies exist? 3. Why did the customer need them? The effects of legal changes in policyholder eligibility cant be determined if you dont know who needs your policies and why they need them.
  16. 16. So when we do our best and we pull all this information together that is really only the known knowns and the known unknowns
  17. 17. Known Knowns You have an X-Wing You have an exhaust port You have guns on the towers You know what you have to do. Hope you can bulls-eye a womp rat in your T-15
  18. 18. Known Unknowns I'm altering the deal. Pray I don't alter it any further. Pro Tip: When entering a forced deal with Vader, its not a bad idea to have a plan for if youre betrayed.
  19. 19. Unknown Unknowns Whoops In hindsight, its easy to say that he should have expected a trap. You cant fully protect from Unknown Unknowns.
  20. 20. Case Study Questions 1. What was known at the time the application was designed? 2. What Known Unknowns existed and what were the risks associated with designing to account for these Unknowns? 3. Was this an Unknown Unknown? Should it have been? Was expansion into a market allowing polygamy a Known Unknown that was deemed unnecessary to account for? Was it an Unknown Unknown?
  21. 21. Elegant Clever Easy and obvious A new approach to a problem If you clearly understand your domain, problem, and systems involved, an elegant solution becomes clear If you dont, then you often find yourself overcoming problems through over-cleverness I could have thought of that! Makes clear the nature and purpose of the systems involved I didnt know you could do that! Can make systems and their interactions difficult to follow.
  22. 22. This was not done by accident. Architectural decisions are more important than results. Results can be a matter of luck. Good decisions show you understand good architecture Case Study
  23. 23. Dr. House on Design Decisions It is in the nature of medicine that you are gonna screw up. You are gonna kill someone. If you can't handle that reality, pick another profession. " At some point, one of your designs will fail to protect from change. Even if you had all the answers for all of your Known Unknowns. Likely, no one will die
  24. 24. Takeaways From The Insurance Company Unhandled change does not necessarily mean a design failure You will have to go forward knowing that you cant know everything I ask about this a lot now:
  25. 25. Hatfields and McCoys? Pure theory is not seen as valuable. Architects arent developers and shouldnt play one on TV. Developers and Architects play different, but equally important, roles.
  26. 26. This is not communication. I dont even know what this is- I have no idea how Id explain it.
  27. 27. This is NEVER communication
  28. 28. This is only funny because its true. But it isnt communication. And its really not involvement.
  29. 29. Clear Communication Communication that isnt clear and easy to understand is just noise If a design needs significant explanation, then its too complicated Elegant designs rarely need significant explanation Clever designs almost always do. I tried to find a fun graphic for this. Ironically, they were all too complicated
  30. 30. Involvement Refining the interaction between design and development is iterative Architecture should be treated as an Agile process. Continuous iteration in order to reduce the impact of problems that will arise.
  31. 31. In Short: Questions?
  32. 32. Matt Osbun [email protected] https://plus.google.com/+MattOsbun https://twitter.com/MattOsbun https://www.linkedin.com/in/mattosbun