Agile Software Development Concepts for Enterprise Architects : Page 2

The Case for Emergent Design in Enterprise Architecture

When the design of an application is done in an emergent fashion, developers are given the flexibility to confront unforeseen issues as they appear. Many software projects have requirements that don't account for all the unknowns.

If your team can admit that there are a lot of unknowns at the beginning of the project, then they can rely on an emergent design strategy to assist in developing the ultimate architecture of your application. The checklist in Table 1 shows some of the major steps architecture teams can take to create good emergent architecture designs.

Table 1: Checklist for Enterprise Teams Considering Emergent Design

The following sections provide details for each of the line items in the Table 1 checklist.

1. Plan for Emergent Design Using TDD

When your team has acknowledged that there are unknowns upfront, look into Test Driven Development/Design (TDD) as a way to inform your architecture. By using TDD in a rigorous and disciplined way, your team can design code with minimal upfront design. By always writing code with tests first, you ensure that any changes are informed by your unit tests. And by making minimal changes when coding, the simplest design usually is created using TDD.

2. Use Automated Acceptance Criteria

Automated Acceptance Criteria is another tool that puts testing before coding. Use this to ensure your architecture adheres to business realities. The types of acceptance tests or criteria to use could be fitnesse tests, behavior-driven development (BDD) tools like Cucumber, Raconteur, RSpec, and so on.

When architecture helps the team bake this automation into the development process, it provides a safety net to ensure new features do not adversely affect current architecture. For instance, take an application that has a hierarchical set of objects that can tree out to 7 levels. The stories never go over that level, and it was not necessary to create anything more robust. Later in the application's life, a new request that needs an 8^th level is introduced. Those tests will catch that request assumption and alert architects and the team to the issue. Action can then be taken.

3. Begin Iterative Planning Cycles

Using Iterative Planning helps your team to adjust its architecture to changing realities during your project's development. By having a fixed point every two weeks where all team members validate the current application -- including product people -- you find architecture errors earlier. The architecture can then follow that Agile or Lean loop of plan, do, act.

4. Are There Defects/Changes in the Project Deliverables?

As mentioned in the previous section, you can adjust at the beginning of an iteration. If, as mentioned in the Automated Acceptance Section, a feature requires a change in the architecture, you need to plan for that. That means determining if the new feature is necessary, and if so, determining how to make the architectural changes. If your team has implemented the automated testing methods advocated here, then making these changes is usually doable in small chunks.

5. Retrospective/Lessons Learned Action Items

Use a Retrospective at the end of each iteration to improve the software development process. Use this standard process to make adjustments in how the architecture interacts with this process.

Use Lessons Learned at the end of the project to implement any action items that you have not implemented yet. While lessons learned is not strictly an Agile practice, it can be used in conjunction with retrospectives.

Make Your Architecture Agile

By incorporating these Agile methods in your architecture process, your architecture team can implement an emergent architecture strategy for your projects.