Independent consultant • Ex-Chief Engineer at Endava based in London (2015-2025) • 10 years in capital markets - UBS and BGI • 10+ years in products - Bull, Sybase, InterTrust • Academic visitor at Imperial College, London
AT DELIVERING THEIR WORK Team A Team B Team C • Features and testing • Local design changes • Feature performance • Features and testing • Local design changes • Feature performance • Features and testing • Local design changes • Feature performance
SOFTWARE ARCHITECTURE Achieving quality attributes Balancing stakeholder concerns Making complex tradeoffs Achieving cross cutting concerns across many independent parts But architecture now needs to be a continual flow of decisions Cross-Cutting Concerns Tradeoffs Stakeholders Quality Attributes
ARCHITECTURE ”Up Front” Design Incremental Modelling Continuous Architecture Document centric Inhibited agility & adaptation Insights often buried Architect centric Too expensive & slow for fast moving change Few real insights “for free” Team centric Principles, styles, “C4” models, decisions Adaptive & quick(er) Insights often still need “mined”
design build validation completion architectural focus time inception architectural focus time delivery 0 delivery 1 delivery 2 delivery 3 delivery ‘n’ … Peaks of Focus at the Start and the End [Rozanski & Woods – 2011] Continuous Focus
Principle 1: Architect products: evolve from projects to products Principle 2: Focus on quality attributes, not functional requirements Principle 3: Delay design decisions until absolutely necessary Principle 4: Architect for change – leverage the “power of small” Principle 5: Architect for build, test, deploy and operate Principle 6: Model the organisation of your teams after the design of the system www.continuousarchitecture.info Murat Erder & Pierre Pureur, 2015
skill not (just) a role Stream of decisions, not “one off” architecture Principles, styles & patterns over structures Delegate & share wherever possible ”Little and often” (and adapt) Aim for a “shared commons” Architecture Work in the New World
ARTEFACTS Principles 1. We prefer industry protocols, then standard in-house ones, then ad-hoc point-to-point ones 2. Partner specific detail must not pollute domain model … 3. Do not use cloud specific services Principles 1. We prefer industry protocols, then standard in-house ones, then ad-hoc point-to-point ones 2. Partner specific detail must not pollute domain model … 3. Do not use cloud specific services Principles 1. We prefer industry protocols, then standard in-house ones, then ad-hoc point-to-point ones 2. Partner specific detail must not pollute domain model … 3. Avoid cloud specific services Styles & Patterns Principles Decisions Top Down Prescriptive Design Evolving Shared Design
Styles & Patterns: Common solutions to repeating problems Evolving Shared Design Principles 1. We prefer industry protocols, then standard in-house ones, then ad-hoc point-to-point ones 2. Partner specific detail must not pollute domain model … 3. Do not use cloud specific services Principles 1. We prefer industry protocols, then standard in-house ones, then ad-hoc point-to-point ones 2. Partner specific detail must not pollute domain model … 3. Do not use cloud specific services Principles 1. We prefer industry protocols, then standard in-house ones, then ad-hoc point-to-point ones 2. Partner specific detail must not pollute domain model … 3. Avoid cloud specific services Principles: Guidance to achieve aligned design decisions Decisions: Understanding what we did, when and why
Architecture Principle: “a declarative statement made with the intention of guiding architectural design decisions in order to achieve one or more qualities of a system” [Eoin Woods] (Aside: “principle” not “principal”) Architecture Decision: “a pertinent design choice that addresses an architecturally significant requirement, which has system-wide impact and establishes constraints on subsequent design work” [ISO 42010]
API-First Design Description APIs must be treated as products in their own right with clear contracts, versioning strategies, tests and consumer-focused design. Service APIs should be designed, reviewed and documented as early as possible. Rationale • Creates clear contracts and responsibilities for high cohesion and low coupling • Facilitates early feedback on interface design • Supports automated testing and API mocking • Consistency and developer experience Implications • API documentation in OpenAPI is mandatory and must be kept current • API design reviews are part of the development process • API deprecation policies must be established and followed • Breaking changes require new API versions
Adopt Microservices Architecture with Domain-Driven Design Context The need to support rapid feature development, independent team scaling, and varying load patterns across different business capabilities Description We will implement a microservices architecture with • services bounded by domain contexts (Product, Order, Payment, User). • services will be independently deployable • each service has its own database • services communicate via well defined, versioned APIs (via OpenAPI, AsyncAPI) • APIs can be synchronous REST APIs or asynchronous message queues. Consequences Positive: independent scaling; teams can deploy features without coordinating releases; technology choices can vary; failures are isolated to individual services Negative: operational complexity; distributed system complexities; need for sophisticated monitoring and tracing; data separation across services
Provide Leadership Focus on Quality Attributes Drive Architectural Decisions Manage Technical Debt Implement Feedback Loops Leadership not management Technical concerns not budget and time “Technical conscience” of the team System wide concerns Often forgotten in ”dash to features” Tradeoffs and specialist knowledge Ensure good decisions are made Ensure principles understood and followed Ensure decisions are captured & understood Constantly measure Understand the implications Manage intentionally Measure delivery & operation Spot trends and warning levels Use to assess architectural quality Use to focus architectural attention
SOFTWARE ARCHITECTURE Minimal Modelling Styles & Patterns Architecture Decisions Architecture Principles • Capture what is stable & valuable • Represent what is not in the code • Use well defined, consistent notations • Ensure the model and reality match • More than one model will be needed
SOFTWARE ARCHITECTURE Minimal Models Styles & Patterns Architecture Decisions Architecture Principles • Styles provide fundamental structures (client/server vs event-driven vs …) • Patterns provide solutions to recurring problems • Styles and patterns drive alignment while retaining autonomy and empowerment
SOFTWARE ARCHITECTURE Minimal Models Styles & Patterns Architecture Decisions Architecture Principles • Principles make priorities and beliefs clear • Principles provide a frame for decision making • Good principles guide teams to make aligned decisions
SOFTWARE ARCHITECTURE Minimal Models Styles & Patterns Architecture Decisions Architecture Principles • Decisions are the architecture “unit of work” • Align decisions via principles • Decentralise decision making as much as possible (but not more so …)
Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives Software Architecture in Practice, 4th Edition Cover: Designing Software Architectures: A Practical Approach
eoinwoods
sagara
ldf_tech
0nihajim
wm3
tomorrowkey
yama3133
itohiro73
insightx
saka2jp
takuyay0ne
ishikawa_satoru
hirachan
lara
sferik
tenderlove
mza
hannesfritz
sachag
chriscoyier
addyosmani
andyhume
carmenintech
dougneiner
sstephenson
