Preso slidedeck

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

Transcript of 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

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?