Agile software development and software architecture cam make strange bedfellows. In many instances, “Agilistas” (inflexible people who have adopted Agile methods to the exclusion of others) are loath to embrace the concept of architecture. And old school architects believe that Agile does not embrace rules.

In fact neither viewpoint is correct. Many of the people who signed the Agile Manifesto actually advocate architecture. However, they support an emergent architecture over a big upfront design. The architecture preached by Manifesto signatories such as Kent Beck and Robert Martin features small upfront design with iterative refactoring throughout the development process.

On the other end of the spectrum, many enterprise architects believe they must spend a lot of time defining how developers can develop an application. This usually translates to a lot of documentation that all members of a team are expected to read. In practice, when these documents are large, developers on a deadline aren’t likely to read them over and over. So, enterprise architects need to come up with a way to assist their teams more effectively. This article explains why an emergent architecture strategy is an effective way to do that.

Software Architecture Defined

Architecture is supposed to be a framework that guides developers and allows them to develop the correct features in the best, most scalable way. Here is a definition of a software architecture from the SEI website:

The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.

“Externally visible properties” refers to the assumptions that elements can make about another element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. Let us look at some of the implications of this definition in more detail.

Enterprise Architecture, Meet Emergent Architecture

In many enterprises, putting the software architect role in action means that the architect defines everything, leaving little for developers to learn as they code. But as developers learn more about the application, they should contribute that knowledge to the design of the application as well. The best architects take this into account and include the developers’ emergent findings into their documents. To incorporate that newfound knowledge into the application, good architects continually refine their documentation.

Still, some architects take the stance that the architect’s document is law. This can lead to dysfunction within the team when developer and QA knowledge is discarded because the document is the rule rather than a guideline. Sometimes the enterprise environment fosters the attitude that the document must be produced, whether it has value or not.

Good Enterprise Architecture from Detail Deferment

As Bob Martin points out in his blog post Screaming Architecture (and I paraphrase here), software architecture should be the use case of the application, not a technical framework. As such, architects should focus only on the technical details needed at the time of a particular project decision.

For instance, when a project begins, make estimates of how much time is needed to make decisions on a technical framework. If you are considering using SharePoint, Orchard, or an MVC application with a database application in a .NET environment, for example, estimate how long it would take to set up those environments. Those time estimates should give architects an idea of when the last responsible moment would be for them to choose their environment.

These concepts can be utilized when determining which approach is best for using good architecture in your enterprise. However, the concepts assume willingness by your organization to challenge the current architectural assumptions.

Small Upfront Design

The idea behind a small upfront design is to architect only what is necessary at the beginning of a project. When starting a project, the team probably needs to know only a few things, such as:

• Programming language being used
• Source code repository setup
• Patterns to be used when developing
• Any emergent technical considerations
• A high-level use case for the application

By doing small upfront design, you ensure that there is room for emergent design throughout the project.

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.