This document contains notes from a presentation on software architecture. It discusses key principles like examining requirements to understand user needs, designing for foreseeable changes, and clear communication between architects and developers. Case studies are used to illustrate how understanding the problem domain leads to more elegant solutions. Overall it emphasizes that architecture is about managing risks to the application and knowing enough about the problem to design appropriately.

1. Matt Osbun
Email: mjosbun@gmail.com
Google+: +MattOsbun
Twitter: @MattOsbun
LinkedIn (Wait for it…): MattOsbun
Software developer 11 years
Software Architect 4 years
Insurance, mortgage, book
publishing, B2B, B2C

2. Software Architecture
It’s about Marcus Aurelius, not Microservices

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. But It’s All So Simple!

5. You Never Know...

6. DRY, YAGNI, “Just in case”, are useful-
Until they’re not

7. MVC, DI, TDD, SOA, etc, are useful-
Unless they’re not

9. Steve Perry
1. Matador series
2. Star Wars
3. Aliens
4. Conan

11. 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

12. 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

13. 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

14. 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.

15. 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.

16. 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.

17. 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.

18. “So when we do our best and we pull all this information
together… that is really only the known knowns and the
known unknowns”

19. 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

20. 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.

21. 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.

22. 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?

23. 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.

24. 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

25. 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

26. 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:

27. 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.

28. This is not communication.
I don’t even know what this is- I have no idea how I’d explain it.

29. This is NEVER
communication

30. This is only funny because it’s true.
But it isn’t communication.
And it’s really not involvement.

31. Clear Communication
Communication that isn’t clear and easy to understand is just noise
If a design needs significant explanation, then it’s 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

32. 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.

33. In Short:
Questions?

34. Matt Osbun
• mjosbun@gmail.com
• https://plus.google.com/+MattOsbun
• https://twitter.com/MattOsbun
• https://www.linkedin.com/in/mattosbun