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 websites 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 of the tradeoffs…

Another point is that “design” is not some exclusive architect thing. A developer is not a good developer unless she also knows 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 the 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, and limited Resources.

• Size – well, if you are going to have something estimated at 1000 man-years or dozens of teams. It is obvious that you can’t just use something that isn’t made to fit. If anything, there’s a need to divide the work between the teams in a way that makes sense so 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 in line. Personally, I think that it doesn’t have to be a huge project to warrant some architect’s involvement. 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 of 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 ambitious project will not make do with “average” architecture. Size (which  I already mentioned) is also a sign of complexity; while previously, I talked about the size of the project, the size of data, the 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 we want people who can help with that (i.e. architects). For instance, in a project 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 that 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 hindsight, 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 explains 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 from both of these definitions – we can see that an architectural decision is basically a guess. Hopefully, that’s an educated guess, but it is a guess nonetheless. And as Albert Einstein once said, it is hard to make predictions – especially about the future.

This is why architects need to have breadth of knowledge. Another aspect is experience. 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 an MVC pattern) and a design to match it, and that’s it.

Well, actually, not quite, since it is still a guess as I wrote earlier. Remember, an architectural decision (and any design for that matter) is a mirage no matter how beautiful the PowerPoint slide looks (or whiteboard or UML sketch etc.)

Alas, PowerPoint compilers are still being made. This 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 afterward – they need to stick around for the game. This is especially true if you want to have an evolving architecture.

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. within projects rather than companies making the architect the project CTO

Tom Berray has an excellent paper describing four 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 Technologies” – I usually saw this in larger projects, but it is also applicable to 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 a 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.” It makes 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 4 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 who 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’s 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, 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.”
*** Illustration taken from Matrix Reloaded

Related posts:

Evolving Architectures – Part III starting out Evolving Architectures – Part IV – Design mechanics Don’t let your architecture become the new hardware