continuously validating architectures · 2017-05-02 · title: continuously validating...
TRANSCRIPT
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
2Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 2
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
3Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 3
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
4Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 4
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
5Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 5
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?
6Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 6
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?
7Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 7
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?
8Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 8
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?
9Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 9
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?
10Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 10
SATURN 2017
Technology is changing rapidly…
Why Validate Continuously?
…and Software Architectures need to evolve continuously!
11Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 11
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….
12Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 12
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
13Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 13
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.
14Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 14
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
15Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 15
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
16Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 16
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
17Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 17
SATURN 2017
Scenario Based
Decision Driven
Checklists
How Should We Validate?
Customer feedback is our best tool!
Utility Trees
18Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 18
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
19Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 19
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
20Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 20
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
21Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 21
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
22Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 22
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?
23Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 23
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?
24Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 24
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®!
25Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 25
SATURN 2017
Document your architecture using a Wiki – and update it during the validation session!
Continuous Architecture Documentation: We Use a Wiki
26Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 26
SATURN 2017
Ask Questions
Software Is Never Done!
Surface Problems
Not Solutions
Summary & Recommendations
Be Kind!
27Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 27
SATURN 2017
Questions?
28Continuously Validating ArchitecturesMay 1–4, 2017©2017 [Copyright Murat Erder & Pierre Pureur] 28
SATURN 2017
Book: store.elsevier.com/9780128032848
Blog: https://pgppgp.wordpress.com/
Murat Erder: [email protected] @muraterder
Pierre Pureur: [email protected] @pgp60