Designing and Building Systems that Don’t Suck
Homeland of Linux Edition
Contents
Who is Matt Lancaster and why is he talking to
me?
• Goals
• Patterns
• Components
• Tools
• Delivery
Begin with Goals
4
UNDERSTANDING GOALS
5
• Understand the business goals of what you’re designing• Understand how these relate to technical goals• Quantify success, and ensure that the metric is well understood
UNDERSTANDING GOALS
6
• Define a Minimum Viable Product (MVP) that aligns with business goals• As Technology Architects, you must be involved in design-time activities• Neither creative nor technology are special, both are needed
USE GOALS AS CONSTRAINTS & EARLY DAYS
Establish Vision, Choose Patterns
Vision Quest!
Before you truly begin the design process, take
some time to establish a vision for the whole
system. Take some time to write out a very
high level functional description of the system.
Take a page or two to write it out.
If you immediately knew what this was, you had as much fun as I did in university… or you’re a
botanist.
9
• From the narrative you wrote, pay attention to the verbs, and how you’re describing interaction.• Does it feel Realtime? Asynchronous? Synchronous? Do actions feel like
moments in time? (e.g. Events)?• This will help determine interaction patterns
• Can you group the subjects into components?
VISIONING
10
• DDD is a lost art. Rediscover it• What are your functional domains? How are they grouped?
DOMAIN DRIVEN DESIGN
11
• You’re ready to begin selecting patterns, but be careful! • Don’t get too stuck in the bleeding edge, but also don’t get stuck in the
stone age• Consider constraints before selection• How do your domains interact, based on the above?• What business problems are you solving for?
PATTERNS: BE MODERN, BUT PRAGMATIC
12
Example Biz Problem: Technology Limits User ExperienceCause: Legacy UI technologies, Fragmented UI
Solution Patterns: Client/API, Modular UI
Solution Details (NOT YET!)
Representative technologies
Booking LoyaltyOn-
Prem UIs
Modular UI
Separate SPAs
Common Framework
APIs
Content
13
• Sketch out your high level system on a whiteboard• Use a thick marker… don’t allow yourself to be drawn into the details
WHITEBOARDING
Story Time
Visioning together!
• Be pragmatic
• Vision != Ideology
• Don’t make meaningless compromise
Trumpism of Architecture #1: “IF YOU’RE
GOING TO BE THIKING ANYWAY, THINK
YUUUGE”
Don’t Drink the Kool Aid - Fruit Punch Edition
Drilling Down: Architecture Components
17
• Not tool selection (yet)• Think in big terms (e.g. API, Event Stream, Data source) • Be Minimalist!• Component-based patterns reign supreme (e.g. Microservices)
COMPONENT SELECTION
18
EXAMPLE COMPONENTS
19
EXAMPLE COMPONENT: MICROSERVICE
Story Time
Architecture Astronauts at Work
• DRY!!!!!!!!!!!! … !!!!
• That said, don’t be afraid to build a
better mouse trap
• Don’t be an architecture astronaut!
Trumpism of Architecture #2 “PATTERNS
FIRST!!! PATTERNS FIRST!!!!”
Don’t Drink the Kool Aid – Lime Edition
USE BETTER TOOLS
23
• Select tools based on your components, not the other way around• Prioritize developer productivity• Don’t forget machines!
• Unless you’re doing .NET, trend toward *nix (e.g. Macs)• Remember: if developers have shitty machines, they’re slow
USE BETTER TOOLS: PRINCIPLES
Don’t Just Assemble Packages
• It never ends well!
• Where should you use something off the
shelf vs build?
• Are you solving for a common business
process, or something of unique value to the
business?
• (common example) If you need a few
simple REST APIs, is a full blown API
gateway solution needed?
• Don’t use a Rolls Royce to plow a bean
field (don’t overthink problems)
USE ‘GOLDILOCKS’ TOOLS
26
TLDR; THIS POINT IN THREE TWEETS
27
MICROSERVICE: TOOLS VIEW
Story Time
Queues and Busses
• Deliverability beats Purity
• Don’t be a technology hipster
• Don’t be a fanboy (or fangirl)
• Pick your battles
• Sometimes old things are used because
they’re really good
• Java can usually get it done (more
slowly)
Trumpism of Architecture #3: “SOMETIMES
THE BEST COMPONENTS ARE THE ONES
YOU ELIMINATE… BIGGLY”
Don’t Drink the Kool Aid - Orange Edition
Don’t Forget Delivery
31
• Every software system needs an engineering system• Isolate features, apply full quality definition before merge• DevOps should never be an afterthought• Embrace Behavior Driven Design / Development
DELIVERY PRINCIPLES
32
• What is your vertical slice?• How can you use a vertical slice to improve delivery?
• Instrumentation & Measurement• Measuring waste• Measuring quality
EMBRACE LEAN
33
• Waterfall/Wagile makes most new IT architectures impossible• Bloated teams, project mindset, org model mismatch can make your
lives hell• Be mindful of culture
MAKE SURE THE ORG/PROCESS DOESN’T PRECLUDE NEW ARCHITECTURE
34
• Switch from ’Infantry Divisions’ to ’Special Forces Teams’FIT TEAMS TO ARCHITECTURE AND ENGINEERING SYSTEM
Story Time
Test Complexity: Multiplication vs. Addition
• Tech debt is never paid down
• Culture eats strategy (and delivery) for
breakfast
Trumpism of Architecture #4: “MAKE
ARCHITECTURE GREAT AGAIN!!!”
Don’t Drink the Kool Aid – Grape Edition
Questions?
FINNISH FINISH
