Agile Architecture – It is NOT an Oxymoron!

Many companies adopting agile have a hard time with the architecture and design of their large systems.  They like the concept of agile, but can’t understand how to emerge and meet architectural requirements just in time for the team to be able to proceed.  They get to the point where they believe “agile architecture” is an oxymoron like “jumbo shrimp” or “deafening silence.”  It just doesn’t make sense to them.

The good news is there is finally starting to be some good information available about agile architecture.  The image on the left is one of many which can be found on the Internet when looking for information about this concept.  Finally, the agile community is putting some effort into answering the question which almost always arises during an agile transformation “What about the system architecture?”

First of all, teams need to change a lot of their thinking about architecture.  Instead of “how do all of these pieces and parts fit together nicely”, the thought process needs to revolve around minimizing the cost of change and delivering customer value.  So a good first step is thinking “how do I separate all of these pieces so change is easy” and following that up with “what value can be delivered with small pieces of the overall architecture in place?”  David Bernstein has an excellent post “Who Needs Architecture and Design?” on his blog.  In it he points out 6 major differences between agile projects and traditional projects when it comes to architecture and design:

1. Defer making decisions until they are needed
2. Constantly strive to provide value to the customer from day 1
3. Drive development from acceptance tests and unit tests
4. Use TDD to create “living specifications”
5. Seek to encapsulate as much as possible
6. Know what decisions cannot be easily encapsulated and therefore must be made up front.

It is interesting that all 6 of these items involve more than just an architect.  They involve developers and in some cases testers.  Everyone is involved in making sure the system functions properly as a whole, not just the architects!  All of this is covered in David’s Agile Architecture and Development – Essential Patterns and Practices course.  He is giving the course on June 16-17 in Seattle.  The early-bird discount expires on May 15.  This course WILL sell out, so be sure to sign up early at http://agilearchitecture-agileforall.eventbrite.com/.  Remember, this is a course for more than just architects.  Developers will get a tremendous amount out of this course – in fact, many developers say the course is a defining moment for them in their careers because they finally understand how to efficiently emerge code and designs to meet customer requirements rather than just coding to the requirement of the day.

The point of all this is to explain to everyone the concept of agile architecture is valid and not an oxymoron.  It requires different techniques and skills in order to be done properly.  You are not likely to just “fall into” doing it correctly.  I have done a bit of research on this topic and there are very few courses available to effectively teach these skills and techniques.  That is one of the reasons I recommend David’s course to my clients and now publicly on my blog.

Too many companies are starting down the agile path and ask the difficult question “What about the system architecture?”  The answer recently got a lot simpler: take David’s course and find out what to do and how to do it!  OK, if you can’t do that, then keep a few thoughts in mind and see how far you can get:

1. What can be encapsulated and decided later?
2. How can things be separated to reduce dependencies and the cost of change?
3. How can architecture and design decisions be driven by concentrating on delivering value?  In other words, don’t build architecture or design except as needed to deliver something with tangible value.
4. Which decisions truly need to be made up front in order to drastically reduce waste later?

Numbers 1 and 4 in the list really are two parts of the same thing in many cases.  If you can defer the decision you will likely have to encapsulate it.  If you can’t encapsulate it then you may have to pay a price later for deferring it.  This isn’t always true, but it sometimes helps to think of it this way.  However you think about it, you really need to concentrate on “just enough, just in time” or you will overbuild the architecture or design – which costs extra time and money (and in this economy both are in short supply!).  Number 3 is a key driver for success.  Don’t just build infrastructure, build it only in the context of delivering value.  The infrastructure will then emerge over time and have exactly the right amount to support the state of the delivered system.  Refactoring will be cheaper than overbuilding as long as the cost of change is kept low.  It seems like more work, but will actually be faster in the end!

Until next time I’ll be my clients will emerge their architecture and designs in agile ways in order to be Making Agile a Reality™ for their organizations.