Being an Agile Architect
I told Steve today that I had been really agonizing over this post and had started it many times but wasn't sure I could word it in ways that I could express what I would like people to understand and take from this post. So here goes and maybe it will make some sense-).
I asked a rhetorical question back in a previous post where I said, "Also, I ponder whether Agile or Extreme Programing development and "Continuous Architecture" and relentless continuous delivery of business value functionality every single week ever really allows time to build adequate framework level stuff like this (logging, etc)."
It was a rhetorical question because I already know the answer having been there when we came up Extreme Programming in the 90's. As someone pointed out in my comments, that dogmatic answer is the canonical "Infrastructure Phase" at the "beginning" of the XP project and to a lesser extent, the mystical "System Metaphor" that we deempasize these days. My experience in the 90's with the XP community was that they were not the world's biggest fans of Architecture and most notably Software Architects. These topics realize perhaps a bias especially with topics like ArchitectsDontCode. At first glance, we got that right. You have to remember that a lot of us were reacting strongly against debacles like CMM and ISO9000 that threatened to take down further software projects in a sea of bindered documentation and hierarchical organizations with the uber ChiefArchitect. For the most part, we were all right about this as, after all, The Source Code Is the Design, not those huge UML Rational Rose diagrams that we churning out that produced zero value but were check-off items in some big process list. Models have no use unless they are essentially are Code Is Model. I learned, kicking and screaming at first, to let go of all those useless things I could not explain why I was doing and focusing on delivering business value not process. Architects were just another big process bump in the road in a lot of places.
Then of course in the Microsoft community, many were just slinging VB1-6 code at the walls with wizards and calling "Architecture" something that either Microsoft told them it was or just what stayed up for a while before crashing. In this scenario, someone just become an "Architect" when they had survived being a developer for a year or 3. In many cases, however, the same kind of biases developed towards architecture leading to lines like Don's immortal definition, "Over 40 and Over confident."
In both cases, biases were developed because of bad experiences people had because of process rather than worth skilled and trained Architects brought to the table. I want to take on my Agile community though because you get this misguided "infrastructure phase" nonsense whenever you raise the issues. Since we don't have very much knowledge at the beginning of a project, Agile, rightfully says, we don't do Big Design Up Front. And we do a great job of that in code. But then we're saying, wait, we are omniscient up front in that architecture stuff and we can just make a platform and then go. Don't get me wrong, we preach the values of Refactoring, Continuous Design and by extension Continuous Architecture and JIT Architecture. I agree with my good friend James Shore with his thoughts on Continuous Design and there is a world of things we can do to keep a design simple, refactored and adaptable to change. That's what we do on our team to a very good level of success.
But it's not enough. We found that a year down the road that there was still a lot missing. Too many "infrastructure" or "framework" things were blowing by in this delirious rush to crunch out 100% business functionality every week no matter what. Someone with Architecture experience needs to perform explicitly the role of Agile Architect and restore these capabilities to a team. It's kind of foolish to say that it was supposed to have been done in the "Infrastructure" phase. I wasn't even at the company then and the infrastructure laid was, well, far from complete to base a real world-class scalable product architecture on. What had we as a team missed in the last 39 week rush? Oh just tiny things like Exceptions, Logging, Security, Service-Oriented Design, Workflow, Scaling to server farms, fail-over, etc. You get the idea. A lot of "cross-cutting" concerns that are like totally essential. The answer is NOT a BDUF Architect coming down from the mount with the stone tablets!! The answer is an Agile Architect. "What's that Jethro? Is that like that X-M-L thang I hear about and all?" Well, Scott Ambler, as well as people like myself, have been trying to educate people on the very real differences with being an Agile Architect. These are our Principles. Look at number one; "Deliver Working Solutions." And if most of that is code, well that means that us Agile Architects CODE ALL THE TIME and SIT WITH THE WHOLE TEAM and not on the mount. We use Agile Modeling. We use Simple Models with Sketches, Whiteboards, Pair Programming rather than Rational Rose UML models because the value-add is the business value we generate in code (Software Is Your Primary Goal) not some UML diagram. I am an Agile Architect.
So Agile teams don't be afraid of us. After all we're guides on the same journey.
Hey, I finally made the Carnival of Agilists!!
My good pal and Agile stir up the masses man, Scott Bellware as usual expresses brilliantly a lot of what I meant better than I could and clarifies a lot of things. I agree.