From a software engineer’s craftsman’s perspective, the term architect is not only negative, its down right skull and bones. Only those who wish to speak up towards management would ever want to be labeled architect. The real demon isn’t necessarily architect in the general sense, its a specific type of architect that we disdain, the kind that adds no value: architecture astronaut, from here on referred to as the non coding architect (NCA).
As Joel Spolsky so eloquently put it, emphasis mine:
When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.
That's one sure tip-off to the fact that you're being assaulted by an Architecture Astronaut: the incredible amount of bombast; the heroic, utopian grandiloquence; the boastfulness; the complete lack of reality.
Lets be clear on something right now, PowerPoint presentations with fancy buzz words add no value. Sure management likes them and sometimes they’re even shiny (management loves shiny stuff), but what value has been added to the product? Again, zero, none, nil. The NCA could create hundreds, thousands of presentations, but still your burn down chart remains unaffected.
The NCA may do more than create PowerPoint slides. Sometimes they create UML models, RUP diagrams, and maybe even state flow diagrams. This kind of stuff is cute, but it still falls into the “useless” category. Very rarely will an engineer on an agile team ever need to reference one of these stale documents.
“The real problem with an NCA trying to dictate technology choices is that there is one critical element missing, something that should painfully obvious to anyone using an agile methodology: there is no feedback loop.”
Some NCA’s may even venture as far as trying to dictate to the development team on how they should build the underlying system architecture. This is a line that should never, ever, ever, ever (just keep repeating that until you get tired) be crossed by an NCA. The real problem with an NCA trying to dictate technology choices is that there is one critical element missing, something that should be painfully obvious to anyone using an agile methodology: there is no feedback loop.
The NCA can choose technology X, because its super cool, has lots of fancy acronyms in it, or is “the standard,” but unless they have skin in the game they don’t suffer from their bad decisions on a daily basis like the rest of the development team. The rest of us would like to focus on the real problems of getting a quality product shipped.
Where do we find these evil NCA’s? Joel continues with this:
It's very hard to get them to write code or design programs, because they won't stop thinking about Architecture. They're astronauts because they are above the oxygen level, I don't know how they're breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don't contribute to the bottom line.
Usually at large corporatized companies, companies with lots of developers, I would imagine a bank. Banks essentially print money (well, the government prints it and then gives it to banks, then sends me the bill). In other words, companies that have money to waste. You would never find an architect on a video game title, they’re too busy trying to make a fun game. Maybe you could make an argument for a NCA at a bank, after all there’s a lot of management overhead and someone has to distract them with shiny things. If you find an NCA and only 5 developers, you’re in a whole heap of trouble, just like them Duke boys.
There is another type of architect, the antithesis of the NCA, the coding architect (CA). Most often the CA is the lead developer on a team, sometimes referred to as the coach on an XP team. The coding architect isn’t focused on shiny things, the CA is focused on the code and how that code fits within the “architecture” of the system. The CA is also focused on the team, providing guidance to junior developers whenever needed. Martin Fowler call this guidance a key to success in his Is Design Dead? essay.
Indeed one of the several games with words that XP makes is that it calls the leading technical figure the "Coach". The meaning is clear: in XP technical leadership is shown by teaching the programmers and helping them make decisions. It's one that requires good people skills as well as good technical skills. Jack Bolles at XP 2000 commented that there is little room now for the lone master. Collaboration and teaching are keys to success.
All this talk of architecture roles brings up a question, what is the “architecture” of a software system. There is no singular answer to this, and depending on the type of system it could be very different things. Ralph Jonhson has one of the better descriptions of software architecture:
…A better definition would be “In most successful software projects, the expert developers working on that project have a shared understanding of the design. This shared understanding is called ‘architecture.’ This understanding includes how the system is divided into components and how the components interact through interfaces. These components are usually composed of smaller components, but the architecture only includes the components and interfaces that are understood by all the developers."
Whether something is part of the architecture is entirely based on whether the developers think it is important. People who build “enterprise applications” tend to think that persistence is crucial. When they start to draw their architecture, they start with three layers. They will mention “and we use Oracle for our database and have our own persistence layer to map objects onto it.” But a medical imaging application might include Oracle without it being considered part of the architecture. That is because most of the complication is in analyzing the images, not in storing them. Fetching and storing images is done by one little part of the application and most of the developers ignore it.
Software is not limited by physics, like buildings are. It is limited by imagination, by design, by organization. In short, it is limited by properties of people, not by properties of the world. “We have met the enemy, and he is us.”
Architecture is the stuff that’s hard to change in a software system, the stuff that’s pervasive everywhere, the building blocks of the application. If architecture is so important, then we want to make sure we put out best people on it and carry the vision forward by coaching the entire development team; there’s no way a NCA could ever hope to do this.