Click the diagram to open the interactive DA Browser, where you can learn more about the decision points and options of this goal.
Why This is 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.
Important Questions to Consider
- 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)?
- We should invest a minimal, yet sufficient, amount of time to consider our architectural strategy.
- We should keep architectural exploration as lightweight and minimal as possible.
- There are many ways to explore architecture opportunities such as modeling, mobbing, and spikes.
- There are various types of architectural models relevant to our context in the areas of technology, business, and user interface (UI).
- Look for opportunities to increase quality and accelerate delivery by leveraging proven architectural assets.