Adaptive Leadership for Technical Projects
The best way to reach out is via e-mail.
Notes: “Good Enough” Architecture
by Stefan Tilkov
Abstract: In this session, we’ll take a look at some of the ways we can determine whether the development efforts we’re undertaking suffer from too much or too little focus on architecture. We’ll examine a number of real-world examples that are intended to inspire either admiration or terror, and try to find some recipes of how we can get more of the former and less of the latter in our own projects.
Definitions of Architecture
Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change
Whatever the architect considers important enough to merit their attention
Different organizations and applications will require different architectures, and those architectures will change over time
#1 Non-Extensible Extensibility
Highly customizable multi-tenant e-commerce solution with lots of features, which has to balance between large customers with specific needs and small customers with generic needs
- If you attempt to design something that satisfies everybody, you will satisfy nobody.
- Highly specific is often preferable to generic
#2 Perilously fine-grained
Large-scale B2B food retailer building a new logistics system, hired >200 developers to build a microservice-based system. Each developer “owned” a microservice, which was hell to scale. Eventually moved away from ‘EntityService’ pattern
- Everybody wants to be Netflix but nobody is
- Small is not always beautiful
- Refactoring within team boundaries much easier than globally
- Ignore organizational parameters at your own risk
#3 Your system WILL be dynamic
Large-scale insurance system with >100 developers. 2 releases / year with 2-week modeling period What if you miss this slot?
- Centralized responsibility hurts
- Faces with too much rigidity, a way around the rules will be found
- Just because you’re used to it doesn’t make it acceptable
#4 Free-style Architecture
A small E-Commerce / Online shop which grew fast to 100-120 developers over ~10 self-contained teams
- Avoid increasing the numbers of developers if you can
- Move to system of systems
- If you don’t actively create an architecture, be prepared to deal with the one that emerges.
- Loose coupling requires very few rules, but they need to be enforced strictly
#5 Cancerous Growth
Financial services provider with independent brokers as clients, 20 years of company history. Spun off new company and just copied system and then shared the database. Also implemented own encryption in Borland C++ and noticed bug after encryption own database
- Successful systems often end up with the worst architecture
- Unmanaged evolution will lead to complete chaos
- Don’t be afraid of some light architectural governance
#6 Improve with less intelligence
Bank with multiple CotS systems, phased out proprietary solution to replace with OSS. Replaced “Magical Integration Broker” with much more simple dockerized pubsub solution.
- Smart endpoints, dumb pipes AKA never put too much logic or intelligence into infrastructure
- Valuespecific over generic solutions
- Don’t be afraid of architecture
- Choose the simplest thing that will work
- Create evolvable structures
- Manage your system’s architectural evolution
- Don’t create road blocks - create value and get out of the way
Have a talk you want to see notes on? E-mail firstname.lastname@example.org