This Inception process goal describes how we will identify an architecture strategy, or potential strategies, for producing a solution for our stakeholders. To be effective, we need to consider several important questions:
- What is our overall strategy for producing a solution? Will we buy or build?
- How many architectural strategies should we consider?
- To what level of detail do we need to go to?
- What models, or views, should we produce?
- What will our approach to modeling be?
- How will we investigate legacy assets (for potential reuse)?
Why is This Important?
There are several reasons why this is important:
- It enables effective evolutionary architecture. We can avoid major problems later on in Construction by doing a bit of thinking up front to get going in the right direction while allowing the details to evolve later.
- We want to identify, and hopefully eliminate architectural key risks early. A little bit of up-front modeling goes a long way towards identify critical technical risks early on. We can then mitigate them later through strategies such as proving the architecture with working code early in Construction or via spikes.
- Avoid technical debt. By thinking through critical technical issues before we implement the solution we have the opportunity to avoid a technical strategy that needs to be reworked at a future date. The most effective way to deal with technical debt is to avoid it in the first place.
- Improved DevOps integration. Because DAD teams are enterprise aware they understand the importance of the overall system lifecycle, which includes both development and operations activities. During architecture envisioning DAD teams will work closely with operations staff to ensure that their solution addresses their needs. This potentially includes mundane issues such as backup and restore of data and version control of delivered assets as well as more complex issues such as monitoring instrumentation, feature toggles, and support for A/B testing. DAD teams strive to address DevOps issues throughout the entire lifecycle, starting with initial envisioning efforts.
- Enables us to answer key stakeholder questions. Our teams are being governed, like it or not. It’s very likely that at some point our stakeholders will want to know how we believe we will we build the solution before they will fund the team. Furthermore, our architectural strategy is important input into answering similar questions around how much money we need and how long we think this will take.
- Enhance initial scoping and planning efforts. Our solution architecture will inform our scoping efforts, motivating questions about requirements as well as suggestions for better options. Similarly architecture also affects our plan in that some architecture strategies take longer to implement than others, architectural activities such as proof-of-concept (PoC) efforts may need to be scheduled, and the cost of new architectural assets be taken into account.
The strategies/practices referenced in the goal diagram above are described, including the trade-offs involved and considerations for when (not) to apply them, in the book Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working. If you want to succeed at enterprise agile you need choices, not prescriptions.