Lean Architecture
Management
by Andrei Kavaleu
2
ABOUT ME
• 14+ years of experience in IT architecture,
technical leadership, software development
• Main Focus on .NET, cross-language architecture,
Architecture Design and Review, Architecture
Audit and Governance
• SEI certified Architect
• Microsoft Competency Center expert,
Architecture community leader
• Hands-on experience examples:
– As Solution Architect: Ticketing platform for Premier
League clubs (eCommerce, CRM, CMS, inventory
management, AWS migration, millions of users on
peeks)
– As Architect and Team Lead: Production automation
and railway transportation (Integration with ERP,
hardware integration, production pipeline
management, shop-floor data collection, multi-site
environment – 16 factories across EU, thousands of
workstations)
3
• Is it hard to make right architecture?
• Case for today: from Darkness to Light
• Agile transition: Complex things via simple
steps
• Lean applied: Changing architecture
• Vision is not enough: Channing processes
AGENDA
4
Is it hard to make
right architecture?
5
• What is Architecture?
• Is here someone who creates Architecture
as part of his job?
• Who implements things according to
Architecture?
• Who has no Architecture on his project?
• Who doesn’t need it?
WHAT IS ARCHITECTURE
6
Architecture is a set of rules and already
made decisions on how a system is to be built
Good architecture is good decisions and good
approach
WHAT IS ARCHITECTURE
7
WHOSE PROBLEM IS THIS?
9
EXAMPLE: BATCH PROCESSING
https://epa.ms/aws-ref-arch
10
EXAMPLE: GRID COMPUTING
https://epa.ms/aws-ref-arch
11
EXAMPLE: MEDIA SHARING
https://epa.ms/aws-ref-arch
12
EXAMPLE: WEB APPLICATION HOSTING
https://epa.ms/aws-ref-arch
13
EXAMPLE: WORD PRESS HOSTING
https://epa.ms/aws-ref-arch
14
EXPAMPLE: NETFLIX OSS STACK
https://netflix.github.io/
16
• MapReduce and more fault tolerance than you need
might sound fine, but consider the cost: you might be
switching from a mature system—with stuff like
transactions, indexes, and query optimizers
• Dynamo and Cassandra are distributed databases
prioritize write availability. Amazon wanted the “add
to cart” action to never fail. This was done by
compromising consistency, as well as basically every
feature present in a traditional RDBMS
• Kafka was designed to handle the throughput of all the
analytics events at LinkedIn: to around 1 trillion events
per day, with peaks of over 10 million messages per
second.
• …
YOU ARE NOT GOOGLE
https://epa.ms/gc-not-google
17
EXAMPLE: STACKOVERFLOW
https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/
18
Case for today:
from Darkness
to Light
19
Problem
• 20+ years old, 1.5M LoC big legacy system
• Hard to add new features and extend existing
code. Reached capacity of VB6
• Painful releases: hard to ensure appropriate
quality
• 100+ clients afraid of new changes
Business Drivers/Goals
• Get control on updates of clients apps
• Decrease operational, infrastructure, license
cost
• Add new clients easier
• Continuous Improvement
SYSTEM AS IT WAS
20
Problem
• 20+ years old, 1.5M LoC big legacy system
• Demand driven development
• 400+ forms, 600+ DB tables
• 100+ clients afraid of new changes
Business Drivers/Goals
• Get control on updates of clients apps
• Decrease operational, infrastructure, license
cost
• Add new clients easier
• Continuous Improvement
SYSTEM AS IT WAS
21
IS THIS OUR END STATE?
22
Good architecture is good decisions and good approach
RIGHT ENOUGH DECISIONS UPFRONT
• Make good decisions in face of uncertainty and lack of
time
• Don’t constraint developers
• Imagine ideal future
23
IDEAL FUTURE
Long-Term Goals:
• Speed and Confidence
Improve product development. Reduce
time to market. Allow Experiments
• Flexibility & Stability
Reconfigure services. Make new
products. Enable innovation
24
HOW TO REACH THIS FUTURE?
Long-Term Goals:
• Speed and Confidence
Improve product development. Reduce time to
market. Allow Experiments
• Flexibility & Stability
Reconfigure services. Make new products. Enable
innovation
25
Agile transition:
Complex things
via simple steps
26
AGILE AND ARCHITECTURE?
AGILE
Iterative and incremental
Frequent delivery of releases
Small and lightweights requirements
Teams are decisions makers
Decisions could be changed frequently
Short planning (sprint/product backlog)
Value is visible on every release
ARCHITECTURE (MYTHS)
Big up-front design
Longer releases
Massive documentation
Architects are decisions makers
Decisions are hard to change
Long-term design
Low visible value
27
MEET LEAN
29
Lean applied:
changing architecture
30
TRANSITION VIA SMALL STEPS
• Small agile steps toward reference
architecture
• Measure each step and react
• Adjust next steps forward
31
SMALL STEPS EXAMPLE: PRINTING
• External component
• Owns printers
• Rendering via external engine
• Available for other systems via
REST
Steps:
• In-Process component
• In-Process REST API (Loop-Back)
• Out-Of-Process REST API
APP
TCT
(Rendering Engine)
Physical Printers
VM Printing Service
Printers ownership
Batch Printing
...
Other Systems Other Systems Other Systems
32
SMALL STEPS EXAMPLE: PAYMENT
• External component
• Multiple Payment Providers
• Available for other systems via
REST
Steps:
• In-Process component
• In-Process REST API (Loop-Back)
• Out-Of-Process REST API
OUR APP
IPS
(For now Credit Cards
and Bank transfer)
3rd
party Integrations
Payment Service
12+ Methods of payment
Other Systems Other Systems Other Systems
33
SMALL STEPS EXAMPLE: ACCESS CONTROL
• External component
• Unifies AC-systems access
• Available for other systems via
REST?
Similar Steps again and again:
• In-Process component
• Unify AC integration via DB
• In-Process REST API (Loop-Back)
• Out-Of-Process REST API
OUR APP Access Control Service
DB
Inegration
Fortress
Other Systems Other Systems Other Systems
Access Manager
Ski Data
?
35
NEW CAPABILITIES AS STEPS
• Promotions
• Supporters Clubs
• Soccer Schools
• Ticket Resale
• Merchandise sales (e-commerce)
• 3rd party sales via API
• …
• Amazon Alexa integration?
Reference architecture
Application 1
Web
Application 2
Desktop
Application N
Web
TM
Capability #1
(Printing)
Service
Component
1
Service
Component
2
TM
Capability #3
(Payments)
TM
Capability #2
(Mailing)
36
Vision is not enough:
change your processes
37
• Build and Visualize your value stream
Do you have CI/CD pipeline?
• Ensure the steps occur in sequence
Do you skip steps?
• Change process from push to pull
Do you use Feature Flags?
• Measure you process
Do you collect process metrics?
PROCESS CHANGES (TOWARD LEAN)
38
VALUE STREAM IS DEVELOPMENT PIPELINE
Development
Specification
Development
Code Review
Testing
CI
Build
Unit/Integration
Tests
Code Analysis
QA
Auto Tests
Manual Tests
Staging
Integration Tests
Load Tests
Capacity Stress
Tests
UAT
Production
Blue/Green
Deployment
Feature Release
Monitoring
42
Feature Flags
• Disable Feature if it’s not ready
or doesn’t work
• No Roll-Backs
• Let user decide what to Turn On
• Your binaries contain Future features
• UAT in Prod? Possible
• Next step is A/B testing 
https://martinfowler.com/articles/feature-toggles.html
44
OUR STATE AS FOR TODAY
• 100% Code coverage
• AQA coverage for Release -1
• Monthly releases for 30+ team (no excuses)
• Devs are making architectural decisions
• Team got incremental mindset
Room for improvements
• Weekly releases. Bottleneck – 2 weeks for
regression
45
THANK YOU
• PM: Dmitry D.
• Team Leads: Viachaslau L., Alexey A., Vital S. and
their Dev Teams
• BA: Siarhei K. and his BA Team
• QA: Natalia P. and her QA Team
• AQA: Maksim S. and his AQA Team
• DevOps: Timur S. and his DevOps Team
• Tech Leads: Alex Ch., Yauhen K., Kanstantsin H.
• and our Customer who allows all this 
46
SUMMARY
47
AGILE AND ARCHITECTURE!
AGILE
Iterative and incremental
Frequent delivery of releases
Small and lightweights requirements
Teams are decisions makers
Decisions could be changed frequently
Short planning (sprint/product backlog)
Value is visible on every release
ARCHITECTURE (REALITY)
Reasonable up-front design
Incremental design updates
Simplified documentation
Shared decisions
Evolutionary architecture
Incremental design
Value is visible few releases
48
Thank you!
Andrei_Kavaleu@epam.com
andrei.kavaleu
kavaleu.ru

GECon2017_ Lean_architecturemanagement_Andrei Kavaleu

  • 1.
  • 2.
    2 ABOUT ME • 14+years of experience in IT architecture, technical leadership, software development • Main Focus on .NET, cross-language architecture, Architecture Design and Review, Architecture Audit and Governance • SEI certified Architect • Microsoft Competency Center expert, Architecture community leader • Hands-on experience examples: – As Solution Architect: Ticketing platform for Premier League clubs (eCommerce, CRM, CMS, inventory management, AWS migration, millions of users on peeks) – As Architect and Team Lead: Production automation and railway transportation (Integration with ERP, hardware integration, production pipeline management, shop-floor data collection, multi-site environment – 16 factories across EU, thousands of workstations)
  • 3.
    3 • Is ithard to make right architecture? • Case for today: from Darkness to Light • Agile transition: Complex things via simple steps • Lean applied: Changing architecture • Vision is not enough: Channing processes AGENDA
  • 4.
    4 Is it hardto make right architecture?
  • 5.
    5 • What isArchitecture? • Is here someone who creates Architecture as part of his job? • Who implements things according to Architecture? • Who has no Architecture on his project? • Who doesn’t need it? WHAT IS ARCHITECTURE
  • 6.
    6 Architecture is aset of rules and already made decisions on how a system is to be built Good architecture is good decisions and good approach WHAT IS ARCHITECTURE
  • 7.
  • 8.
  • 9.
  • 10.
  • 11.
    12 EXAMPLE: WEB APPLICATIONHOSTING https://epa.ms/aws-ref-arch
  • 12.
    13 EXAMPLE: WORD PRESSHOSTING https://epa.ms/aws-ref-arch
  • 13.
    14 EXPAMPLE: NETFLIX OSSSTACK https://netflix.github.io/
  • 14.
    16 • MapReduce andmore fault tolerance than you need might sound fine, but consider the cost: you might be switching from a mature system—with stuff like transactions, indexes, and query optimizers • Dynamo and Cassandra are distributed databases prioritize write availability. Amazon wanted the “add to cart” action to never fail. This was done by compromising consistency, as well as basically every feature present in a traditional RDBMS • Kafka was designed to handle the throughput of all the analytics events at LinkedIn: to around 1 trillion events per day, with peaks of over 10 million messages per second. • … YOU ARE NOT GOOGLE https://epa.ms/gc-not-google
  • 15.
  • 16.
    18 Case for today: fromDarkness to Light
  • 17.
    19 Problem • 20+ yearsold, 1.5M LoC big legacy system • Hard to add new features and extend existing code. Reached capacity of VB6 • Painful releases: hard to ensure appropriate quality • 100+ clients afraid of new changes Business Drivers/Goals • Get control on updates of clients apps • Decrease operational, infrastructure, license cost • Add new clients easier • Continuous Improvement SYSTEM AS IT WAS
  • 18.
    20 Problem • 20+ yearsold, 1.5M LoC big legacy system • Demand driven development • 400+ forms, 600+ DB tables • 100+ clients afraid of new changes Business Drivers/Goals • Get control on updates of clients apps • Decrease operational, infrastructure, license cost • Add new clients easier • Continuous Improvement SYSTEM AS IT WAS
  • 19.
    21 IS THIS OUREND STATE?
  • 20.
    22 Good architecture isgood decisions and good approach RIGHT ENOUGH DECISIONS UPFRONT • Make good decisions in face of uncertainty and lack of time • Don’t constraint developers • Imagine ideal future
  • 21.
    23 IDEAL FUTURE Long-Term Goals: •Speed and Confidence Improve product development. Reduce time to market. Allow Experiments • Flexibility & Stability Reconfigure services. Make new products. Enable innovation
  • 22.
    24 HOW TO REACHTHIS FUTURE? Long-Term Goals: • Speed and Confidence Improve product development. Reduce time to market. Allow Experiments • Flexibility & Stability Reconfigure services. Make new products. Enable innovation
  • 23.
  • 24.
    26 AGILE AND ARCHITECTURE? AGILE Iterativeand incremental Frequent delivery of releases Small and lightweights requirements Teams are decisions makers Decisions could be changed frequently Short planning (sprint/product backlog) Value is visible on every release ARCHITECTURE (MYTHS) Big up-front design Longer releases Massive documentation Architects are decisions makers Decisions are hard to change Long-term design Low visible value
  • 25.
  • 26.
  • 27.
    30 TRANSITION VIA SMALLSTEPS • Small agile steps toward reference architecture • Measure each step and react • Adjust next steps forward
  • 28.
    31 SMALL STEPS EXAMPLE:PRINTING • External component • Owns printers • Rendering via external engine • Available for other systems via REST Steps: • In-Process component • In-Process REST API (Loop-Back) • Out-Of-Process REST API APP TCT (Rendering Engine) Physical Printers VM Printing Service Printers ownership Batch Printing ... Other Systems Other Systems Other Systems
  • 29.
    32 SMALL STEPS EXAMPLE:PAYMENT • External component • Multiple Payment Providers • Available for other systems via REST Steps: • In-Process component • In-Process REST API (Loop-Back) • Out-Of-Process REST API OUR APP IPS (For now Credit Cards and Bank transfer) 3rd party Integrations Payment Service 12+ Methods of payment Other Systems Other Systems Other Systems
  • 30.
    33 SMALL STEPS EXAMPLE:ACCESS CONTROL • External component • Unifies AC-systems access • Available for other systems via REST? Similar Steps again and again: • In-Process component • Unify AC integration via DB • In-Process REST API (Loop-Back) • Out-Of-Process REST API OUR APP Access Control Service DB Inegration Fortress Other Systems Other Systems Other Systems Access Manager Ski Data ?
  • 31.
    35 NEW CAPABILITIES ASSTEPS • Promotions • Supporters Clubs • Soccer Schools • Ticket Resale • Merchandise sales (e-commerce) • 3rd party sales via API • … • Amazon Alexa integration? Reference architecture Application 1 Web Application 2 Desktop Application N Web TM Capability #1 (Printing) Service Component 1 Service Component 2 TM Capability #3 (Payments) TM Capability #2 (Mailing)
  • 32.
    36 Vision is notenough: change your processes
  • 33.
    37 • Build andVisualize your value stream Do you have CI/CD pipeline? • Ensure the steps occur in sequence Do you skip steps? • Change process from push to pull Do you use Feature Flags? • Measure you process Do you collect process metrics? PROCESS CHANGES (TOWARD LEAN)
  • 34.
    38 VALUE STREAM ISDEVELOPMENT PIPELINE Development Specification Development Code Review Testing CI Build Unit/Integration Tests Code Analysis QA Auto Tests Manual Tests Staging Integration Tests Load Tests Capacity Stress Tests UAT Production Blue/Green Deployment Feature Release Monitoring
  • 35.
    42 Feature Flags • DisableFeature if it’s not ready or doesn’t work • No Roll-Backs • Let user decide what to Turn On • Your binaries contain Future features • UAT in Prod? Possible • Next step is A/B testing  https://martinfowler.com/articles/feature-toggles.html
  • 36.
    44 OUR STATE ASFOR TODAY • 100% Code coverage • AQA coverage for Release -1 • Monthly releases for 30+ team (no excuses) • Devs are making architectural decisions • Team got incremental mindset Room for improvements • Weekly releases. Bottleneck – 2 weeks for regression
  • 37.
    45 THANK YOU • PM:Dmitry D. • Team Leads: Viachaslau L., Alexey A., Vital S. and their Dev Teams • BA: Siarhei K. and his BA Team • QA: Natalia P. and her QA Team • AQA: Maksim S. and his AQA Team • DevOps: Timur S. and his DevOps Team • Tech Leads: Alex Ch., Yauhen K., Kanstantsin H. • and our Customer who allows all this 
  • 38.
  • 39.
    47 AGILE AND ARCHITECTURE! AGILE Iterativeand incremental Frequent delivery of releases Small and lightweights requirements Teams are decisions makers Decisions could be changed frequently Short planning (sprint/product backlog) Value is visible on every release ARCHITECTURE (REALITY) Reasonable up-front design Incremental design updates Simplified documentation Shared decisions Evolutionary architecture Incremental design Value is visible few releases
  • 40.