Disciplined Agile

Identify Architecture Strategy

This Inception phase process goal describes how we will identify an architecture strategy, or potential strategies, for producing a solution for our stakeholders. The focus of this process goal is on solution-level architecture, supported by your Enterprise Architecture efforts which focus on organizational-level architecture.

2021 Project Management Institute Identify Architecture Strategy v5.2 Identify a Delivery Strategy Extend existing solution(s) Build from scratch (IT) Build from scratch (Citizen Development) Configure a commercial package Extend a commercial package Select an Architecture Strategy Existing proven architecture Multiple candidate architectures Single candidate architecture Explore the Architecture Discuss Event modeling Hackathon Minimum viable product (MVP) Mob programming Model Open space Proof of concept (PoC) Spike Apply Modeling Strategy(ies) Agile modeling (informal) sessions Interviews Joint application design (JAD) sessions Model-driven development (MDD)/computer-aided software engineering (CASE) Open space What-if discussions Model Technology Architecture Architectural stack diagram Cloud architecture diagram Network diagram Threat model UML component diagram UML deployment diagram UML state chart Model Business Architecture Business process diagram Capability map Data flow diagram (DFD) Domain/conceptual model Event model Logical modules diagram UML component diagram Model User Interface (UI) Architecture UI flow/wireframe diagram UI prototype (high fidelity) UI prototype (low fidelity) Investigate Legacy Assets Collaborate with asset owner(s) Reverse engineer models Run regression test suite Read overview documentation Analyze data sources Read source code Read detailed documentation Level of Detail of Architecture Document High-level overview Executable interface specification Detailed interface specification Detailed specification No document

Figure 1. The Identify Architecture Strategy process goal diagram.

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)? 

Key Points

  • 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.

January 2023