• 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
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 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
5. 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. 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
14. 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. 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
18. 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
20. 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
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 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
24. 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. 30
TRANSITION VIA SMALL STEPS
• 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 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)
33. 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)
34. 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
35. 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
36. 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
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
39. 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
