of 34 /34
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

Preso slidedeck

Embed Size (px)

Text of Preso slidedeck

Page 1: Preso slidedeck

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

Page 2: Preso slidedeck

Software ArchitectureIt’s about Marcus Aurelius, not


Page 3: Preso slidedeck

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.

Page 4: Preso slidedeck

But It’s All So Simple!

Page 5: Preso slidedeck

You Never Know...

Page 6: Preso slidedeck

DRY, YAGNI, “Just in case”, are useful-

Until they’re not

Page 7: Preso slidedeck

MVC, DI, TDD, SOA, etc, are useful-

Unless they’re not

Page 8: Preso slidedeck
Page 9: Preso slidedeck

Steve Perry

1. Matador series2. Star Wars3. Aliens4. Conan

Page 10: Preso slidedeck
Page 11: Preso slidedeck

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

Page 12: Preso slidedeck

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

Page 13: Preso slidedeck

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

Page 14: Preso slidedeck

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.

Page 15: Preso slidedeck

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.

Page 16: Preso slidedeck

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.

Page 17: Preso slidedeck

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.

Page 18: Preso slidedeck

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

Page 19: Preso slidedeck

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

Page 20: Preso slidedeck

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.

Page 21: Preso slidedeck

Unknown Unknowns


In hindsight, it’s easy to say that he should have expected a trap.

You can’t fully protect from Unknown Unknowns.

Page 22: Preso slidedeck

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?

Page 23: Preso slidedeck

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.

Page 24: Preso slidedeck

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

Page 25: Preso slidedeck

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

Page 26: Preso slidedeck

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:

Page 27: Preso slidedeck

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.

Page 28: Preso slidedeck

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

Page 29: Preso slidedeck

This is NEVER communication

Page 30: Preso slidedeck

This is only funny because it’s true.

But it isn’t communication.

And it’s really not involvement.

Page 31: Preso slidedeck

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

Page 32: Preso slidedeck


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.

Page 33: Preso slidedeck

In Short: