<= Home
Evolving Architecture and Agile
Recently, we were practicing sizing stories at a client site to come up with a release plan. They were having difficulty because no decisions on the system Architecture had been made yet and all we had were stories at this point. So the question then was posed “When is Architecture decided on when practicing Agile”? I am not one here to be the final word at all (especially not being one of those omnipotent Architects ), but I can comment on experience.
First, it should generally not matter in most cases. I assume that relatively favorable coding conditions and architecture will exist when it comes time to implementing a story. If you have a smart client, SOA, Remoting, or any other “latest trend” will not drastically effect if a story is a small, medium, or large one. If it does, the story is probably to large so send it back to the business.
Second, avoid making concrete architecture decisions up front. Just like the development process, which *architecture* is part of, as it will evolve over time and with iterations. For example, setting up a Messaging or Service Architecture in the first couple iterations is probably being presumptuous, as usually nothing at that point in the development process will have already warranted setting up that infrastructure. (Yes, there are exceptions, but be careful not to assume your case is the exception.) Later stories in iterations may require you to set up a service but defer that to when it is appropriate and it should ultimately (main point) not effect estimating all the other stories.
Another point about evolving architecture…primarily the problem with people that can’t size stories without a concrete architecture (as with this case) is that usually they view systems as a whole process all interdependent on each component. It is much easier to size stories when you view the components of the system that are affected by that story as independent of the other pieces. By this I mean a fully object oriented system with clear separation of responsibilities and proper encapsulation. If you develop in that way it should be easy to isolate pieces (components) of system and evolve the architecture around them as appropriate. (hopefully my point is as clear in here to others as it is in my head).
Some made a joke last architecture meeting. As we sat down one person chimed in that we have to have a domain model and then someone said some Inversion of Control will help along with setting up services in case another application someday needs to integrate with our system – oh and for sure it will need to be a smart client! As developers we like to try out new things and follow the latest trends, I am guilty at times too, but these things should manifest themselves when they have requirements for them, not “just because” of the cool factor.