Agile Zone is brought to you in partnership with:

Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Agile Architecture or Accidental Architecture

05.13.2009
| 12660 views |
  • submit to reddit

Architecture is an overloaded term these days, and one that is not always easy to define. There's also a myth surrounding architecture and agile methods - some feel it isn't necessary. But architecture is a critical component of any software development effort, and the larger the project the more important it is. As Booch states,

Every interesting software-intensive system has an architecture

That architecture is either accidental or intentional. So how should teams treat architecture on agile projects? Like most agile practices - early and often.

I recently offered up my opinion of agile architecture, and established two simple truths surrounding agile architecture:

  • Software architecture is organic. The architectural goals you set to achieve early in the lifecycle differ from those you’ll need to satisfy late in the lifecycle. Agile architecture is not only about what decisions you make, but when you make those decisions.
  • Software architecture is only as good as the source code it’s built upon. Shoddy source yields shoddy architecture. Therefore architecture must emphasize building the highest quality and structurally sound source code possible.

Scott Ambler offers up a detailed explanation of agile architecture, stating that it's "a critical part of scaling agile approaches to meet the real-world needs of modern organizations." He provides some valuable guidance surrounding architecture, including two key nuggets of information - the importance of architecture throughout the lifecycle, and proving architecture with code.

Unfortunately, many teams using agile practices have foregone architecture altogether since many popular methods don't explicitly define any architectural practices. The thought is that architecture and design done "up front" is a Bad Thing.

UncleBob, a guy who knows a thing or two about agile, recently let us know his thoughts surrounding the myth that you shouldn't spend time up front making architectural decisions when he stated pretty bluntly, "Pardon me, but that’s Horse Shit." He was very clear that teams must spend time early dealing with architectural issues, but that the time spent is clearly a product of project size and complexity.

The Agile Architect site also provides a wealth of information surrounding agile architecture, including the role of the agile architect.

Across each of these explanations of agile architecture runs a common theme. Architecture is important. Some architecture must be done up front. Architecture should be proven with code. Architecture will evolve through the life of the project.

Yet there's another aspect to agile architecture, as well. Two aspects, actually. One as a process and another as an entity. Agile architecture is the process of architecting that results in a flexible and malleable software architecture. A lot of discussions focus on agile architecture as a process and less as an entity. In reality, both are critically necessary.

As a process, agile architecture is a technique, or set of practices, that an architect uses to create a software system. It involves making sound and timely decisions throughout the software development lifecycle. In some cases, it means admitting that an architectural mistake was made and that the team needs to modify the architecture.

On the other hand, traditional architecture involves spending significant time early in the project defining the architecture. Once the vision has been established, teams tend to resist architectural changes throughout the lifecycle. Traditional architecture is done up front, whereas agile architecture is done throughout.

But simply because a process is employed that embraces architectural change throughout the software lifecycle does not mean that it's possible to make that change. As an entity, agile architecture emphasizes the structural resiliency of the system so that change is possible. This involves using the right patterns, establishing the right extension points within the system, abstracting away areas of intense complexity, and more. And throughout the course of the project, architectural shifts occur. Sometimes, we anticipate correctly. Sometimes not. Agile architecture is defined by our willingness and ability to embrace architectural change.

Whereas the process aspect of agile architecture demands that the team be flexible, the entity aspect of agile architecture demands that the structure of the system be flexible so that the team is able to quickly make the change. Agile architecture demands both, and the absence of one precludes the presence of the other.

Published at DZone with permission of its author, Kirk Knoernschild.

Comments

Mohamed El-beltagy replied on Wed, 2009/05/13 - 5:29pm

Thank you very much, Kirk, for the post. Although it is simple and small, but it really helped me a lot.

It did two things for me actually:
- It cleared for me a couple of things about agile architecture.
- It summarized and did some thoughts gathering and getting some info straightened up in my head.

INMHO, I think that agile methodology in general is, simply speaking, just a reflect or a reaction to the events that takes place during the project implementation. It's more into reaction to events than planning to events as things used to be before.

I have a comment and sorry for that, but I really do not understand what's the relationship between the title and the post?!

john green green replied on Fri, 2009/11/27 - 12:05pm

Unfortunately, many teams using agile practices have foregone architecture altogether since many popular methods don't explicitly define any architectural practices. The thought is that architecture and design done "up front" is a Bad Thing.
nike china shoes

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.