It is difficult to explain architectural concepts and outcomes in simple language. When tell stakeholders that "the system needs five-nines availability" or "we need Amazon level scability" their eyes tend to glaze over. Abstract architectural language doesn't mean a lot to people who don't build and operate systems. This can make it really difficult to get buy-in for the things we really need to do: improve our security, fix our scalability, improve our resilience or improve our user experience.
This talk (re)introduces a proven, but underused, technique, using specific scenarios - short, structured stories - to bring architectural aspects of a system to life, particularly for less technical stakeholders. Instead of abstract discussions about "resilience" I'll explain how to tell stories about "what happens when a database fails at 4am on Black Friday with 5000 online customers".
We'll explore what makes a good architectural scenario, how to construct scenarios that expose the right trade-offs, and how to use them to communicate architectural implications to non-technical stakeholders. You'll see how scenarios help you investigate whether your architecture will actually meet stakeholder needs, prioritize conflicting quality requirements, and turn vague statements like "must be scalable" into concrete, measurable targets.
Using realistic examples from finance, e-commerce and other domains, we'll see how scenarios can transform architectural conversations from frustratingly ambigous debates to precise discussions where everyone understands what is at stake and the trade-offs that they're accepting.
Whether you're building a new system, looking at a challenging extension, finding budget for technical improvement or grappling with a legacy application, architectural scenarios give you an approach to bring quality attribute discussions to life and ensure that everyone understands the importance of your next architectural decision.
This talk (re)introduces a proven, but underused, technique, using specific scenarios - short, structured stories - to bring architectural aspects of a system to life, particularly for less technical stakeholders. Instead of abstract discussions about "resilience" I'll explain how to tell stories about "what happens when a database fails at 4am on Black Friday with 5000 online customers".
We'll explore what makes a good architectural scenario, how to construct scenarios that expose the right trade-offs, and how to use them to communicate architectural implications to non-technical stakeholders. You'll see how scenarios help you investigate whether your architecture will actually meet stakeholder needs, prioritize conflicting quality requirements, and turn vague statements like "must be scalable" into concrete, measurable targets.
Using realistic examples from finance, e-commerce and other domains, we'll see how scenarios can transform architectural conversations from frustratingly ambigous debates to precise discussions where everyone understands what is at stake and the trade-offs that they're accepting.
Whether you're building a new system, looking at a challenging extension, finding budget for technical improvement or grappling with a legacy application, architectural scenarios give you an approach to bring quality attribute discussions to life and ensure that everyone understands the importance of your next architectural decision.
Eoin Woods
Artechra
Eoin Woods is an independent consultant in the fields of software architecture, green software and software engineering. He is formerly the CTO of Endava, where he was responsible for software engineering and capability development for over 10,000 delivery staff across the world. Prior to Endava he has developed databases, created security software and designed way too many systems to move money around. He is a regular conference speaker and has co-authored three books on software architecture. His web site is www.eoinwoods.info.