I read a good blog post that basically tries to re-define the common ‘Architect’ role for agile development methodologies. I do agree with his premise, but have a few extra qualifiers I would throw into his statements.
The agile software development methodologies are based more on light planning and a constant amount of course correcting based on user feedback during the development cycle – basically the iterations can be measured in days, or even hours. Other more traditional iterative methodologies have iterations that are measured in weeks or months and require far more up front design and planning since you are not re-evaluating the overall product as regularly. Personally, I like the agile development methodologies much more. Unfortunately, as a consultant, many times I have to use a client’s methodology which may not be in line with the agile development methodology. Even then I try to infuse as many of the agile principles that I can into the development process.
So, as I said, I do agree with his basic premise and I think we’re probably saying the same thing, but I want to be just a bit more explicit in my definition. Titles dont matter to me so we can keep the name he gave. 🙂 But I would definitely say that there are design decisions that need to be made at a high level before the team is even a team. For instance “We are going to implement an enterprise service bus to call the CICS programs”. Instead of doing the ‘simplest thing’ which may be to simply use a CICS transaction gateway that is already in place, having foresight for a company so as to make more options architecturally viable in the future would definitely be advantageous. To me, the role-formerly-known-as-architect would be responsible for these kind of decisions and mandates.
Notice above that I said these decisions were made before the team was a team. Maybe a way to bring what I’m thinking and what the original author is thinking is to compromise on the fact that there are non-functional design decisions that an architect has to make up front. If I couple that with saying that the architect may actually have to make similar decisions mid-cycle and may have to arbitrate less high-level design issues along the way then I am satisfied with the concept the original author presents.
To me, agile development helps immensely in keeping the development car on the road. Users and their requirements are the destination to which the car is heading. I envision the architect as the team member who makes sure you have the right kind of car with the right setup – it’d be harder (if not impossible) to get to the top of a mountain with a compact car, so the architect should be the one responsible for making sure you start out with a 4×4 with the ability to upgrade the shocks, etc. OK, its a cheesy analogy, but hopefully you get my point.