Skip to content

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

Published inAgile ArchitectureBlogFeatured Posts


  1. I’ve always thought the who point of agile was to implement something for which the architecture is well understood. If you’re building a three-tier web-shop, then a metaphor, senior dev, and iterations should be more than enough. You don’t need an architect on the payroll. On the other hand, if you’re building something novel, or which has strong dependancies across the enterprise, then you might want an architect to steer the boat.”Coding architect” makes no sense to me as the two jobs are different enough that you can’t do both at once and still do either justice. Let’s just admit that they’re senior devs and get over this strange instance of labelling anyone senior in development as some type of architect.

  2. Hi Peter,

    I am sorry but I don’t agree. First the need for an architect is orthogonal to methodology. As I said in the post some projects do not need architects. Again, as I said above, I think the need for architect comes from size, complexity and limited resources.
    Also agile is not necessarily for things where the architecture is well understood. In fact If you’re building something novel – it is more likely that Agile will be a better fit, since it embraces change, iterates etc. On  a project where the architecture is well understood it is easier to plan a head and use waterfall
    Whether or not an architect codes comes from the size of the team vs. the number of architects in the project. A single architect on a 60 dev. team will probably not code much… An architect in a 5 dev team better code or be marginalized
  3. Ohh… “Agile for is good for unknown problems” is one of those claims that is often made but never proven. Agile might be good at discovering the details in an implementation of a well understood problem, but even the agile a-list admit that it’s not a good “algorithm design” method.Agile projects to deliver truly novel solutions  have a habit of blowing up, often in a big way. If you want a nice nutshell example, then just check out Peter Norvig’s approach to creating a sudoko solver, compared to the various agile approaches. The TDD approach is a particularly large train wreck. Iteration and change don’t help if you if you don’t actually understand the problem. You need to invest in architecture: you need to spend some time thinking about the problem and possible solutions.On the other hand, agile is good at discovering the details in an instance of a well understood problem. Building an n-tier web shop? Agile is your friend. Pick a metaphor, capture some stories, and start iterating.We also need to kill this idea that “architecture implies waterfall”. Agile does not have a monopoly on iterative, concurrent or incremental methods. Nor does investing in architecture preclude them. Plus, if the architecture is well understood, then why do you need an architect? A few design iterations (i.e. agile) is a better approach.I think this all comes down to the fact that the terms “architect” and “architecture” have been so misused as to now be meaningless in the IT community. Most architects are senior devs who have design responsibility.

  4. When I first saw the title for this post – I thought a comedian had entered the game.After reading the article I realized that it was more than a joke and to a large degree sounded like a way to herd rabbits. As an example a coding architect no… no… an architect that codes (usually called a programmer) OK. I hear that there plenty of office cleaning architects around these days.

  5. You get 10 points for sarcasm  – but what are you trying to say really?

     so you think architects shouldn’t code (I didn’t say they should always code I said it depends on project size vs. number of architects) do you care to support your claim?
  6. I did not intend to be
    sarcastic (not a bad score considering that). Sorry if I offended you.

    I started in IT in 1965 and over the years I have watched with
    amusement how titles change as a person advances up the slippery pole. Having
    been a mercenary since c.1979 I have no need for titles and as long as people
    understand the role I am fulfilling today I just get on with the activities
    that will help the team(s) complete their current part of the project at hand.

    I see architects in a similar way to how they are involved with
    the construction of a building. I just cannot see the word architect in
    everyone’s title on a building site. 

    So as the word was being flung around in this thread willy-nilly
    I thought I would dip my oar in so as to speak. 

    One last note: When I was in Miami on an assignment I suggested
    that no one has a title and a orchestra of squeals floated from the offices
    (that was the end of that idea). 

    In a new start-up I am involved in I call myself the CeO and as
    there are two of us at the moment we are the joint CeOs. A tongue in cheek
    title that most people have to ask, “what does that mean?” 

    You have a good day – Peter from down under. 


    I still code, but these days it is HTML or JavaScript with
    notepad as the editor.

  7. Hi Peter,

    Well I was talking about the role rather than the title. I guess you can say it is in the “fine print” (filled under **) but it is there :) . Anyway, while I only have 20 years of experience in IT, a lot of the  projects that I’ve seen, reviewed or worked on did have a place for an architect role. I think it is important to a lot of types of products and not needed in some which is what I tried to say in this post.

Comments are closed.