Abstract: We'd like to deliver functionality on a regular cadence, but sometimes poor design and technical debt trips us up. Ongoing, sustainable development and delivery of system functionality benefits from explicit attention to architecture. Yet we don't want to slip into old habits, overspecifying things we'll never implement or doing too much design upfront. We need to strike a balance. While being agile, we also want to pay attention to the desired and emergent architecture qualities of our systems. Performance, scalabability, maintainability, or flexibility don't happen by magic.
This session introduces you to several architecture practices that can be picked up individually and adapted to your specific business context. You'll learn about practices for managing architecture work, making it visible, and for incrementally delivering architecture. For example, you might want to want to define a landing zone for key system qualities, giving room to make architectural tradeoffs. Or, you may need to raise awareness of existing architecture debt so that you can plan accordingly. Or you may need to fit in cycles of architecture investigation or innovation in with ongoing delivery of functionality. Or probe your existing system's capabilities through defining quality scenarios for normal and failure/recovery modes.
One set of architecture practices doesn't fit all situations. Come learn some powerful architecture practices that can be independently adopted to address your challenges with architectural complexity, uncertainty, emergent system behavior, and incremental delivery of features and capabilities.
Learning Outcomes: - Appreciate explicit attention to architecture and the utility of independent architecture practices
- Ways to manage and mitigate architecture risk: landing zones, risk reduction backlogs, architecture roadmaps
- Managing architecture investigation: architecture spikes, innovation spikes, bounded reasearch
- Making architecture work and progress visible: coloring the backlog, system quality dashboards, system quality scenarios
- A decision-making framework for "dialing in" explicit architecture practices
Attachments:
