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.