Embed Size (px)
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
Software ArchitectureIt’s about Marcus Aurelius, not
Microservices
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.
But It’s All So Simple!
You Never Know...
DRY, YAGNI, “Just in case”, are useful-
Until they’re not
MVC, DI, TDD, SOA, etc, are useful-
Unless they’re not
Steve Perry
1. Matador series2. Star Wars3. Aliens4. Conan
GRASPGeneral 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
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
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
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 architect’s job is deciding what changes are foreseeable and what changes are imaginary.
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.
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.
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 can’t be determined if you don’t know who needs your policies and
why they need them.
“So when we do our best and we pull all this information together… that is really only the known knowns and the known unknowns”
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
Known Unknowns
“I'm altering the deal. Pray I don't alter it any further.”
Pro Tip: When entering a forced deal with Vader, it’s not a bad idea to have a plan for if you’re betrayed.
Unknown Unknowns
Whoops…
In hindsight, it’s easy to say that he should have expected a trap.
You can’t fully protect from Unknown Unknowns.
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?
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 don’t, 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 didn’t know you could do that!”
Can make systems and their interactions difficult to follow.
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
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
Takeaways From The Insurance Company
• Unhandled change does not necessarily mean a design failure
• You will have to go forward knowing that you can’t know everything
• I ask about this a lot now:
Hatfields and McCoys?
Pure theory is not seen as valuable.
Architects aren’t developers and shouldn’t play one on TV.
Developers and Architects play different, but equally important, roles.
This is not communication.I don’t even know what this is- I have no idea how I’d explain it.
This is NEVER communication
This is only funny because it’s true.
But it isn’t communication.
And it’s really not involvement.
Clear Communication
Communication that isn’t clear and easy to understand is just noiseIf a design needs significant explanation, then it’s too complicatedElegant designs rarely need significant explanationClever designs almost always do.
I tried to find a fun graphic for this. Ironically, they were all too complicated
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.
In Short:
Questions?
Matt Osbun
• https://plus.google.com/+MattOsbun
• https://twitter.com/MattOsbun
• https://www.linkedin.com/in/mattosbun
