Continuously Validating Architectures · 2017-05-02 · Title: Continuously Validating Architectures in an Agile-Centric World Author: Erder Murat (Deutsche Bank), Pierre Pureur (Travelers)

1Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 1

SATURN 2017

Continuously Validating Architectures©2017 [Copyright Murat Erder & Pierre Pureur]

Continuously Validating ArchitecturesMurat Erder & Pierre Pureur

“Nothing is as empowering as real-world validation, even if it's for failure.” Steven Pressfield, the War of Art: Break Through the Blocks & Win Your Inner Creative


SATURN 2017

Murat Erder – Director, Chief Data Office, Deutsche Bank

Pierre Pureur – Chief Enterprise Architect, Travelers Insurance

Who Are We?

The opinions and views expressed in this presentation are those of the authors and do not necessarily reflect the position of their employers


SATURN 2017

1. Context – a few thoughts

2. Why continuously validate architectures?

3. What do we mean by ‘Architecture Validation’

4. How should we validate?• Scenario-based approach• Decision-centric approach• Checklist-driven approach

5. When do we validate?

6. Who should validate?

7. Summary & Recommendations

Continuously Validating Architectures in an Agile Centric World


SATURN 2017

What is architecture?

Dancing House by Frank Gehry and Vlado Milunic in Prague

What has not changed is the organizational hurdles that are the same as in Greek Antiquity

Context - A Few Thoughts

The basics tenets of good architecture have not changed.

What has evolved is the technology landscape • Increased ability to work at larger scale and in a distributed manner• Desire for quicker delivery timelines


SATURN 2017

Architectures are the foundation of software

systems

Validating the architecture tells us

whether we have the right team structure

Architecture validations encourage communication among project stakeholders

Fixing defects early is the

best approach

Why Validate Architectures?


SATURN 2017

Inadequate, poorly designed or carelesslyassembled architectureswill cause a softwaresystem to fail

Failures may occur during development or in the worst possiblecase after the system has been deployed into production.

Do We Have The Right Foundation?


SATURN 2017

Conway’s Law implies that the

structure of a project determines its architecture to a

large extent

A poorly organized project team will result in a poorly

designed architecture

Do We Have The Right Team Structure?


SATURN 2017

Validating the architecture early in a software

delivery life cycle (SDLC) makes a lot of economic

sense.

Fixing defects early in the SDLC is much less

painful and costly than fixing them later or even

fixing them after the system has been

deployed in production

Why Not Fix Defects Early?


SATURN 2017

Communication & collaboration

aspects of architecture are just

as important as developing it.

Architecture evaluations help significantly with collaboration & communication

How Can We Better Communicate?


SATURN 2017

Technology is changing rapidly…

Why Validate Continuously?

…and Software Architectures need to evolve continuously!


SATURN 2017

1. Architect products, not just solutions for projects

2. Focus on Quality Attributes, not on functional requirements

3. Delay design decisions until they are absolutely necessary

4. Architect for change- leverage ”the power of small”

5. Architect for build, test and deploy

6. Model the organization after the design of the system

Software Architectures Can Evolve Continuously If We….


SATURN 2017

The IT group in a large Corporation wants to build a new mobile system to

allow prospective customers to do price comparisons, and to purchase products

Let’s follow them through their journey, as they attempt to validate their proposed architecture

Case Study: The “Mobile Shopping” System


SATURN 2017

“Architecture Validation” is a

structured process conducted by a team

of architects, designers and other

IT specialists.

Architecture validation also promotes knowledge sharing across the enterprise

What Exactly Is “Architecture Validation”?

This process has a well-defined approach, review

etiquette and ground rules.


SATURN 2017

Are Architecture and Design Decisions

compatible with our requirements?

Why Would We Want to Validate?

Our collaborative approach improves the quality and results in faster delivery by catching errors earlier in the lifecycle.

Our “Mobile Shopping” team wants to make sure that Quality Attribute requirements have been addressed


SATURN 2017

Traditional Requirement Capture

Methods Are Not Working Well For Us

We Want to Elicit Continuous Customer Feedback and Immediately Update the MVP

As an Alternative, We Use a Minimum

Viable Product (MVP) Approach

Yes – But Do We Have The Right Requirements?

also see https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233d5d16ab02


SATURN 2017

We Leverage “The Power Of Small” – We Use Minimum Viable Architectures

Microservices,Serverless,etc…

1990s: Lasagna

2010s: Ravioli

Avoid the Big Architecture Up Front (BArF) syndrome!

1970s: Spaghetti


SATURN 2017

Scenario Based

Decision Driven

Checklists

How Should We Validate?

Customer feedback is our best tool!

Utility Trees


SATURN 2017

Use Map Mapping Tools to Draw your Utility Trees

Use Architecture Trade-Off’s Analysis (ATAM) Utility Trees – They are Amazing!

Utility Trees

Quality Attribute

Quality Attribute Refinement

Scenario: Stimulus,Response, Measurement

Decision


SATURN 2017

We test the architecture against the scenarios that are associated with the quality attribute requirements for the system

Scenarios describe specific interactions between the user of an application system and the system itself.

Look for Trade-off’s

Scenario Based Approach


SATURN 2017

We evaluate decisions against the quality attribute requirements and draw a Decision Relationship Diagram

We systematically review, analyze and record the rationale behind the architecture and design decisions made by the project team.

Decision Driven Approach

We Use Utility Trees to Link Decisions to QAR’s


SATURN 2017

We organize our questions using a Utility Tree

We leverage a set of questions prepared in

advance

Checklist Driven Approach

https://www.amazon.com/Checklist-Manifesto-How-Things-Right/dp/0312430000


SATURN 2017

Initial Validation:We focus on Quality Attributes and Trade-

Offs (ATAM)

Continuous Validation: We use a brief checklist

during weekly IPM’s

Periodic Validation: We monitor our Decision Log and

focus on Decisions (DCAM)

Code Inspections: We use Static Analysis

tools often!

When Do We Validate?


SATURN 2017

We use a dedicated scribe to document the session

interactively

We use an experienced facilitator to keep

validation sessions on track

Our correct team structure and balance ensure a successful session

Who Validates the “Mobile Shopping” Architecture?


SATURN 2017

Conduct review sessions with Lego blocks - but they have to be large ones!

A Great Way to Run a Validation Session - We Play with LEGO®!


SATURN 2017

Document your architecture using a Wiki – and update it during the validation session!

Continuous Architecture Documentation: We Use a Wiki


SATURN 2017

Ask Questions

Software Is Never Done!

Surface Problems

Not Solutions

Summary & Recommendations

Be Kind!


SATURN 2017

Questions?


SATURN 2017

Book: store.elsevier.com/9780128032848

Blog: https://pgppgp.wordpress.com/

Murat Erder: [email protected] @muraterder

Pierre Pureur: [email protected] @pgp60

https://pgppgp.wordpress.com/

Documents

Continuously Validating Architectures · 2017-05-02 · Title: Continuously Validating Architectures in an Agile-Centric World Author: Erder Murat (Deutsche Bank), Pierre Pureur (Travelers)