Disciplined Agile

Enterprise Architecture Practices

Some methods will choose to prescribe a single approach, such as capturing architectural requirements in the form of epics or pre-building “architectural runways,” but the Disciplined Agile (DA) tool kit promotes an adaptive, context-sensitive strategy. DA does this via its goal-driven approach that indicates the process decision points you need to consider, a range of techniques or strategies for you to address each decision point, and the advantages and disadvantages of each technique. Figure 1 depicts the goal diagram for the Enterprise Architecture process blade.

The following diagram overviews the potential activities associated with Disciplined Agile Enterprise Architecture.

Figure 1. The enterprise architecture goal diagram (click to enlarge)

The process decision points that you need to consider for enterprise architecture are:

  1. Support stakeholders. Enterprise architects will work with their stakeholders on a regular basis to understand their needs and to help them develop a vision for the organization.
  2. Support delivery teams. Enterprise architects will work with solution delivery teams, and ideally be active members of solution delivery teams, on a regular basis. They may guide the teams in the business and technical roadmaps, help them to identify potentially reusable assets, to identify technical debt, and transfer their skills and knowledge to team members.
  3. Negotiate technical dependencies. Like it or not, there are dependencies between the solutions that we create. For example, if your system invokes a web service, or calls an API, provided by another system then you have a dependency on that system. Enterprise architects will often find that they need to negotiate these dependencies with other teams, either at a high-level in their role of Enterprise Architect or sometimes at a detailed level in their role of Architecture Owner on a delivery team.
  4. Explore architectural views. Organizations are complex and as a result they must be understood from a variety of view points. It’s not just a matter of writing “architectural epics” on a collection of index cards. Please refer to the process goal Identify Architecture Strategy for potential artifacts you may wish to consider using to capture these views.
  5. Tailor architectural framework. The enterprise architecture team may choose to adopt, and likely tailor, an existing enterprise architecture framework. These frameworks typically suggest a multi-view collection of artifacts to create and techniques for doing so.
  6. Evolve roadmap(s). An important output of your enterprise architecture effort will be one or more roadmaps describing your business and technology architectural strategies. In agile organizations this roadmapping occurs in a rolling wave approach where the roadmap(s) are updated regularly.
  7. Evolve enterprise architecture. Enterprise architects will collaborate with one another, and with their stakeholders, in a variety of ways. They may choose to hold architecture envisioning/modeling sessions or regular meetings where they share learnings with one another. They will often work together, or with solution delivery teams, to investigate new technologies or identify candidate architecture strategies.
  8. Capture enterprise architecture. There are two broad categories for how enterprise architects can capture their work: as documents or as working/executable examples. High-level models work well for documentation, although sometimes you may find the need for detailed documentation as well. Executable artifacts, such as executable reference architectures or architectural runways, are usually preferred over documentation by delivery teams.
  9. Govern architecture. Architectural activities within your organization should be governed in a lightweight, collaborative manner. This is an important activity for enterprise architects as well as for your governance team.