GOTO Berlin 2019 “Good Enough” Architecture Stefan Tilkov stefan.tilkov@innoq.com @stilkov "Tegel Airport TXL Berlin May 2012 - 19" by andynash is licensed under CC BY-SA 2.0
(Software) Architecture De f initions Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the Whatever the architect principles of its design and considers important enough evolution (ISO 42010) to merit their attention Architecture represents the signi f icant design decisions that shape a system, where signi f icant is measured by cost of change (Grady Booch) @stilkov
Architecture is not an upfront activity performed by somebody in charge of telling everyone else what to do @stilkov
Architecture is a property of a system, not a description of its intended design @stilkov
Pick the best car:
Quality https:/ /iso25000.com/index.php/en/iso-25000-standards/iso-25010 @stilkov
Scaling Dimensions Facebook half of the Net f lix Amazon planet Twitter Insurance Load Policy Management Random CMS a dozen users written in depends on Logic a day German tax law
There is no “good” or “bad” architecture without context; architecture needs to take speci f ic quality attributes into account @stilkov
Cases
Context: • … Observation(s): • … Lesson(s) learned: • … @stilkov
#1: Non-extensible Extensibility
Context • E-Commerce (retail) provider • Global customer base • Catalog/CMS/Shop/Ful f illment • Multi-tenant • Highly customizable @stilkov
(Acceptable) Cost High Large customers (“strategic”) The Solution Small customers (“long tail”) Low Customization (Need) Specific General @stilkov
If your design attempts to satisfy everyone, you’ll likely end up satisfying no one @stilkov
Highly speci f ic code is often preferable to sophisticated con f iguration @stilkov
#2: Perilously f ine-grained
Context • Large-scale B2B food retailer • New company-wide shop and logistics system • >200 developers @stilkov
Team 2 Team 1 Team 3 @stilkov
Checkout Support Ful f illment Billing Order Service @stilkov
Why would you cut up your system into tiny, distributed, hard-to- manage fragments?
Everybody wants to be Net f lix, but nobody is @stilkov
@stilkov
… @stilkov
Checkout Support Ful f illment Billing Order Service @stilkov
Checkout Support Ful f illment Billing Order Service @stilkov
Lessons learned • Small is not always beautiful • Refactoring within team boundaries much easier than globally • Ignore organizational parameters at your own risk @stilkov
#3: Your system WILL be dynamic
Context • Large-scale insurance system • Model-driven development • > 100 developers • 2 Releases/year @stilkov
0 1 2 3 4 5 6 Vision Business Concept Technical Concept Modeling Modeling Implementation Module Test What if you Integration Test miss your slot? Rollout @stilkov
Policy - id * - value - dueDate New Name Release Clause Model Name Description * (Meaning) Introduced - text - validity - taxClass taxClass regionCode … 10.3 regionCode Holder - name … - address - status @stilkov
Lessons learned • Centralized responsibility hurts • Faced with too much rigidity, a way around the rules will be found • Just because you’re used to it doesn’t mean it’s acceptable @stilkov
#4: Free-style architecture
Context • E-Commerce/Online shop (Retail) • 100-120 developers • ~10 self-contained teams @stilkov
strength of decoupling systems μ services components modules methods number of developers @stilkov
From a layered system … UI Module Module Module Logic Data System @stilkov
… to a system of systems UI UI UI Logic Logic Logic Data Data Data System System System @stilkov
In-page Cross-page JavaScript method calls Links & redirects Shared abstractions & frameworks Micro-architecture Common language runtime HTTP HTML 5 JS platform Standard Browser @stilkov
But … • Lack of standardization led to inef f icient UI integration at runtime • Vast differences in API style, formats, documentation created needless extra work • Despite no centralised frontend, a central frontend team created a new bottle neck @stilkov
You cannot decide to not have an architecture; if you don’t actively create it, be prepared to deal with the one that emerges @stilkov
There’s a f ine line between diversity (that adds value) and chaos (that doesn’t) @stilkov
Extremely loose coupling requires very few rules, but they need to be enforced strictly @stilkov
#5: Cancerous Growth
Context • Financial services provider with independent brokers as clients • ~30 developers • 20 years of company history @stilkov
Oracle Forms App Oracle DB @stilkov
Java/JSP Web App Lots of PL/SQL Oracle DB @stilkov
.NET Web .NET Web Service .NET Web Java/JSP Service Service Web App .NET Web Service Lots of PL/SQL Oracle DB @stilkov
Company A Company B .NET Web .NET Web .NET Web Service .NET Web .NET Web Java/JSP Service .NET Web Java/JSP Service Service Service .NET Web Web App Service Web App .NET Web Service Service Lots of Lots of PL/SQL PL/SQL Oracle DB Oracle DB @stilkov
Company A Company B .NET Web .NET Web .NET Web Service .NET Web .NET Web Java/JSP Service .NET Web Java/JSP Service Service Service .NET Web Web App Service Web App .NET Web Service Service Lots of Lots of PL/SQL PL/SQL Oracle DB @stilkov
Company A Company B .NET Web .NET Web .NET Web Service .NET Web .NET Web Java/JSP Service .NET Web Java/JSP Service Service Service .NET Web Web App Service Web App .NET Web Service Service Couch/Pouch Mongo Oracle DB Mongo MySQL @stilkov
Company A Company B C++ Encryption Lib .NET Web .NET Web .NET Web Service .NET Web .NET Web Java/JSP Service .NET Web Java/JSP Service Service Service .NET Web Web App Service Web App .NET Web Service Service Couch/Pouch Mongo Oracle DB Mongo MySQL @stilkov
Lessons learned • Successful systems often end up the worst architecture • Unmanaged evolution will lead to complete chaos • Don’t be afraid of some light architectural governance @stilkov
#6: Improve with less intelligence
Context • Bank with multiple CotS systems • Highly proprietary integration solution phased out by vendor • Project launched to replace commercial product with open source solution @stilkov
Other External Group Partner Company Custom Custom App App Magical Integration CotS Custom Broker App DB CotS External Parent Partner Company @stilkov
Other External Group Partner Magical Integration Broker Company Custom Custom Routing App App Conversion Transformation Magical Integration Transcoding CotS Custom Broker Transport App Error handling Business logic DB CotS … External Parent Partner Company @stilkov
Other External Group Partner Company Custom Custom App App Pub/Sub Messaging CotS Custom App DB CotS External Parent Partner Company @stilkov
Other External Group Partner Company Custom Custom App App Pub Sub Messaging Adapter (Docker Container) Pub/Sub routing Pub/Sub Messaging CotS Custom Transport App Conversion Error handling Transformation Transcoding DB CotS Error handling External Parent Business logic Partner Company @stilkov
Lessons learned • Smart endpoints, dumb pipes (cf. Jim Webber) • Value of speci f ic over generic solutions • Micro architecture with blueprints @stilkov
Takeaways
1. Don’t be afraid of architecture @stilkov
2. Choose the simplest thing that will work @stilkov
3. Create evolvable structures @stilkov
4. Manage your system’s architectural evolution @stilkov
5. Don’t build road blocks – create value and get out of the way @stilkov
@stilkov That’s all I have. Stefan Tilkov @stilkov Thanks for listening! stefan.tilkov@innoq.com Phone: +49 170 471 2625 innoQ Deutschland GmbH innoQ Schweiz GmbH Krischerstr. 100 Ohlauer Straße 43 Ludwigstr. 180E Kreuzstraße 16 Gewerbestr. 11 40789 Monheim am Rhein 10999 Berlin 63067 Offenbach 80331 München CH-6330 Cham Germany Germany Germany Germany Switzerland www.innoq.com Phone: +49 2173 3366-0 Phone: +49 2173 3366-0 Phone: +49 2173 3366-0 Phone: +49 2173 3366-0 Phone: +41 41 743 0116 @stilkov
Recommend
More recommend
