Johanna Rothman received a variety of responses to her recent writing on agile architecture. In this article, she attempts to clarify her case for having an architect on some–but not all–agile programs, depending on a number of factors.
I’ve been blogging about agile architecture, and the responses have been fascinating. Some people are totally against the idea of an agile architect, regardless of the size of the program. Others are ready to give me the benefit of the doubt. In this column, let me clarify the case for (or against) the job-titled agile architect.
As with all interesting questions, the only correct answer is “It depends.” It depends on the size of your program, how architecturally complex the product is, the desired speed of release, how long you have been practicing agile, how much technical debt you have, and how distributed your program is.
Programs Are Different from Projects
A project is a unique and novel effort, characterized by risk. It has a beginning and an end. A program is the organizational coordination of several projects’ results into one deliverable, which has value to the organization. So, while each project has its own risk, the program has the strategic risk for the organization.
Programs may continue for several releases of the product or system. Programs are large, and one thing we know about software is that it does not linearly scale. What works for a small project or for one team does not work for eight, twenty-five, or forty-two teams.
Program Size Is a Factor
One factor in considering whether you need a formal architecture role on your program is the program size. How many total people do you have? The reason to consider the total number of people is because of the communication paths in the teams and among the teams.
Assume you have seven-person teams. We know that the communication paths inside a team are (N*N-N)/2 which works out to twenty-one paths for a seven-person team. If you have two or three teams, the teams may still be able to build informal communication paths among themselves to share architectural knowledge.
Once you have four to seven teams, you are at the hairy edge of what teams can do informally. I have seen several programs work successfully without a formal architect role and one spectacular failure. I have seen two programs work successfully with three architects participating on feature teams and as architects on the programs. Clearly, your mileage will vary.
On programs with eight teams or more, I strongly suggest you have an architect team, who participate both as part of the feature teams and as architects. Agile architects write code, test, and look ahead just a little to smooth the way for the feature teams.
How Complex Is Your Product
Organizations normally use programs to create “complex” products in the sense that the technical team has more or less opportunity to refactor as they develop the product. (Product complexity might not be the right term here, but it’s the best term I have right now. Let me know what term you would use in the comments below.) Within that notion, there are more-complex and less-complex products. That complexity allows you to make architectural decisions more often or less often.
Figure 1 shows one way you might think about product complexity and product type.
Figure 1: Product complexity and opportunity to rearchitect and refactor
You have the opportunity to make many more architectural decisions and refactor much more often when you have a software-as-a-service product than when you have hardware as part of the product. Can you still change the architecture with hardware or mechanical systems? Of course you can. Do you have to coordinate with many more people? Yes. Do you have longer feedback loops? It’s much more likely that you do. Does that mean