Who Needs an Architect Anyway?
Not all projects need architects. There, I've said it. Not all projects need architects and I am not talking here just about trivial projects.
There are cases (maybe even many cases) where you can get by with what I call "off-the-shelf" architecture -- maybe with a few adjustments that any master developer (i.e. seasoned and experienced developer) can handle. For instance a lot of web-sites can do pretty well by using Model-View-Controller (or a derivative of that) along with a simple O/R mapper such as active-record. In fact a lot of them do just that, when they use a framework like Rails that made these architectural choices for them*. Another example is the vanilla 3-tier architecture provided by software vendors (such as this one by Microsoft). Yes, when you take something off-the-shelf, the result might not be optimal but that doesn't mean it isn't sufficient. You just have to be aware for the trade-offs...
Another point is that "design" is not some exclusive architect thing. A developer is not a good developer unless she also known about proper design. For that matter "mastery" of just the technical aspects of a language without understanding the wider context of design will just help you code a lot of crap faster. So, again , a good developer knows a thing or two about design and can handle trade offs and variations on a project architecture (especially in cases described above).
This means we need to consider a few issues: When (if at all?) do you need architects? What do they Do? What's their relation and interaction with the developers?
When do you need architects?
It isn't always an obvious choice between a project that can get by with an "off-the-shelf" architecture and one that needs an architect. It would be nice if we could have something like a litmus test that would tell us if architects are needed or not. I don't have one. The closest thing to a litmus test I have is something I call the SCLR test (pronounced scaler). SCLR stands for Size, Complexity & Limited Resources.
- Size - well if you are going to have something estimated at 1000 man-years or dozens of teams. I think it is pretty obvious that you can't just use something which isn't made to fit. If anything there's a need to divide the work between the teams in a way that would make sense so that you wouldn't get a big-ball of mud. There's also a lot of need to coordinate the efforts and keep the big-picture inline. Personally I think that it doesn't have to be a huge project to warrent some architects involvement. Since as Fred Brooks notes the number of interactions grows exponentially as we add more people. In my experience trouble starts even with more modest numbers -- more than four or even three different teams working concurrently is probably a good number to start thinking about architects
- Complexity - There are many signs for complexity in a project. The vision statement can provide a hint. "Let's design the software to support the next mars mission", "best CRM platform ever" - an ambitions project will not make-do with "average" architecture. Size (which I already mentioned) is also a sign of complexity, while previously I talked about size of the project, the size of data,number of concurrent users etc. is also relevant when we're thinking about complexity . A lot of external interfaces is another sign. Integration doesn't seem very complicated, until you actually try to pull it off. When you have to do a lot of that in a project that's complex. And there are many other such signs
- Limited Resources - Naturally every project has limited resources, but limited resources should be considered as a sign for architect involvement if the resources are extreme. When resources are extremely limited the tradeoffs that have to be done are more meaningful, which is why wed want people who can help with that (i.e. architects). For instance in a projects I worked on in the past we had a lot of availability and performance requirements on one hand but only so many "U"s in the rack and even limited electricity to make all this magic happen. This turned something which otherwise was a relatively standard IT project into something a lot more challenging.
Let's assume I convinced you that some projects need architects. Convinced, you go and hire one. Now what?
What do architects do?
Let's start by looking at "architectural decisions" - which is sure sounds like something we'd want an architect to do. I read once (I think that was Martin Fowler) that an architectural decision is a decision that in hindsiight you wished you made right. if we look at a formal definition of software architecture (say from IEEE 1471) we see that the architecture embodies the fundamental decisions about the system its components, their relations and their properties. Using this definition an architectural decision is a fundamental decision about the system (which pretty much explain why we want to make them right etc.)
Well, here are two observations on what I've said thus far. One is that we would want to postpone architectural decision as much as we can, since changing them will cause us a lot of headache. The problem is that in order to postpone an architectural decision we need to build flexibility into the system which is an architectural quality in itself -- which might not be the top of the list if we prioritize it vs. other architectural qualities we need.
The second observation is that if we "refactor" the pretty language out from both of these definition -- we can see that an architectural decision is basically a guess, hopefully that's an educated guess but it is a guess none-the-less. and as Albert Einstein once said it is hard to make predictions -- especially about the future.
This is why architects breadth of knowledge -- which helps explain the architect training program I posted about a few weeks ago (see Architect training program Part I and Architect training program Part II). Another aspect is experience. And to get a wider perspective it can be helpful if this experience includes other roles besides developer such as project manager or business analyst etc. Another important component is domain knowledge and understanding of the business.
Using all these you (as an architect) may come up with a reasonable architectural decision (e.g. use MVC pattern) and a design to match it and that's it.
Well, actually, not quite since as I said earlier it is still a guess. Remember an architectural decision (and any design for that matter) is a mirage no matter how beautiful the power point slide looks (or white board or UML sketch etc.)
Alas, power point compilers are still in the making. Which means that as an architect, you must be able to prove your point in writing -- that is coding. While you are at it, you also need to know a thing or two about the technology you are using because it too has an architecture, features etc. which may (and usually do) have a significant effect on the end result. (You can read a little bit more on this in the "Architecture Deployment" paper I published a while ago).
The result of trying to postpone architectural decisions coupled with ever changing requirements and with adding details as we unfold the architectural abstraction level to a working system, is that the architect can't just appear at the inception of a project and disappear afterwards -- they need to stick around for the game. This is especially true if you want to have an [intlink id="evolving-architectures-part-whats-software-architecture" type="post"]evolving architecture[/intlink].
The architect's role goes beyond making architectural decisions. In effect the role shares some of the CTO roles -though on a smaller scale i.e. withing projects rather than companies making the architect the project CTO.
Tom Berray has an excellent paper describing 4 models for the role of a CTO. 3 of them can be applied to software architects (within their projects):
- "Big Thinker" - This is somewhat akin to the role discussed in the previous post.
- "External Facing Technologiest" - I usually saw this in larger projects, but it is also applicable for smaller ones. There are many occasions where the technical capabilities of the project have to be presented and/or negotiated with external stakeholders. Architects are in a good position to perform this as they should have good understanding of both the business and the technology. Additionally making architectural decisions already requires the architect to understand the different stakeholders' needs
The third model is called "Technology Visionary and Operations Manager" -- Making sure that technology works to deliver business goals. But how is that done?
In their book on organizational patterns, Jim Coplien and Neil Harrison, talk about the "Quattro Pro for Windows" (QPW) development team. According to the case study, Borland had a team of four architects who worked together to produce what the authors call "prototypes"*. Six months later these architects were joined by additional developers to produce the product. During the development the architects kept meeting on a daily basis to coordinate their efforts (sort of like a daily stand-up in a scrum of scrums).
The situation in the QPW is probably close to the ideal architect involvement in a project -- coding architects that work closely with the team, while driving technical and architectural decisions. The availability of multiple architects (but not too many, to prevent the "design by committee" effect) also enhances the overall quality of the solution.
Another aspect of the architect work is to act as a coach/mentor. It isn't enough for the architect to "know best". We already know that architect must also be able to reason about their recommendations/decisions, but that's just part of the story. Helping other team members get better in what they do means that they'd be able to do their job better, they'd be able to come up with their own ideas (and get more fresh ideas into the discussions) and produce better software. Since the architect is ultimately responsible for the quality of the solution, making others perform better should be a top priority for the architect. Being considered as a source of knowledge will help an architect perform his/her role, even when they don't have an architect title.
[This post is an edited version of several posts I wrote in 2007 and are (IMHO) worth reprinting]
* Rails has more than just MVC and Active-Record but that isn't an important point for this discussion ** In this post "Architect" means someone doing software architecture work (role) and not necessarily someone with the job title "architect"