Agile Architecture Anti-Patterns
Tags [ Agile, architecture ]
I have been the solution architect for an enterprise-spanning project which is now getting geared up for its next phase. This project touches more than 10 different development teams across at least three company divisions and involves at least one external ISV. So, you know, a pretty small project.
As I reflect on the process of hashing out all the technical details, I realized I got stretched pretty thin. I really didn’t have time to write much down in any formal fashion this time around, due to the time pressure on the project and the number of other things I was also trying to juggle. I have instead been spending a lot of time drawing stuff on whiteboards for various technical audiences. The things I did have time to write up were only the most general concepts and patterns - i.e. the really high-level architecture.
At least part of the reason I didn’t have time to write anything else down was that I was spending all my time in technical design discussions with all the various groups, hashing out nitty-gritty integration details and then bringing full integration designs back to the development groups to run with. The last time through, this worked out well, because the developers in my home organization are used to agile development and being responsible for their own technical design, so they were able to take my whiteboard sketches, continue to consult with me, and produce solid, working code. It also worked out ok because the last phase was actually the first phase of this project, and I had enough lead time to work out all the details ahead of time.
This time around, the time pressure is pretty high, plus the work-ahead time I would have had in a traditional “up-front” architecture process was actually consumed by helping to get the first phase out the door. So I find I actually don’t have enough time to do the same detailed design that I did the first time around before the development teams are scheduled to start. This would seem to be a major conundrum.
Antipattern 1: waterfall, up-front architecture doesn’t pipeline well if the architecture phase extends concurrently all the way through the development phase.
Corollary: trying to waterfall development and QA doesn’t pipeline well either for exactly the same reason (because developers have to keep working their code to fix bugs).
The other anti-pattern that I was running into was with development teams in some of the other divisions; I would work with the enterprise architects to hash out a pretty detailed design, but when we brought that to the development teams, there was a ton of convincing, resistance, and redesign that ended up happening. Now, I’m not sure exactly which anti-pattern we were running into, but it was one of the following:
Antipattern 2: up-front architecture doesn’t work if the architects aren’t familiar enough with the details of the systems/teams they are designing for, because the designs won’t “fit right”.
Antipattern 3: up-front architecture doesn’t work if the architects haven’t been able to build up sufficient technical cred to sell their designs to the developers.
For sure both of those applied to me with respect to the developers and technical leads of the groups in the other divisions.
I’ve been thinking a lot recently about the right way to approach this, and really enjoyed this essay on Agile Enterprise Architecture by Scott W. Adler. He proposes a much more lightweight, hands-on approach to architecture which can best be described as guiding the agile development teams to develop the right architecture themselves.
Fred Brooks writes in The Mythical Man-Month that a systems’ architecture must proceed from one or a small number of minds in order to be coherent (I can’t find a copy right now, so that’s paraphrased). At the same time, agile development techniques like Extreme Programming (XP) or Scrum suggest that the development teams ought to be responsible for evolving their architecture organically. I’m starting to think that both of these are true, and that they are not mutually exclusive, and it is related to another realization I’ve had (but that I have a hard time remembering):
A solution architect is responsible for seeing that the end-to-end solution hangs together technically. It is not necessary for the architect to produce the whole end-to-end design himself to achieve this.
Going forward, I think I’m going to take the following approach: figure out broadly which development teams are going to need to interact and what their coarse responsibilities are, then immediately get them involved on working out the solution. In true agile fashion, let them work out the details, and just play Product Owner to set high-level (technical) requirements, being on-hand to participate in the design discussions. I think this leverages best the available technical design talent in the development teams, while making sure that someone is tracking it all and fitting it into a coherent mental model to make Mr. Brooks happy.