Architects vs. Project Managers: Part 4

This is the fourth installment on the topic of architects and project managers. In this part, I examine "how do you balance and divide the responsibilities between the project manager and the software architect?"

One observation I have is that we are talking about roles, not necessarily people. For instance, in a single project there might be a person with a project manager title who also performs architect roles and vice versa. This is also true for architects vs. developers. For example, on a small enough project, one of the developers can also perform the architect's roles.

On the surface the division seems clear. The project manager is responsible for the schedule and budget and the architect for the technical integrity of the solution. This is looks fine -- until you consider that every technical decision has budget and schedule implications. So now what?

When the project has dedicated architect, I would say that the responsibility of the architect is to provide the the technical and technological aspects for major decisions. But it is up to the project manager to make the decisions. The architect should try to get the best possible solution under the constraints the project manager sets.

What happens when you have a single architect that works with multiple projects?

The way I see it there are two scenarios.

• One is that the architect is sort of like a consultant for multiple project. In this case (which, by the way, I would try to avoid), the architect should be treated like a consultant. In this case, I wouldn't even let the external architect make the final decisions within the constrains set by the project manager. The team that builds the project, which hopefully also includes a dedicated architect, should do that. I guess this type of architect is what is known as "Ivory tower architect."

• The other scenario for an architect who works with multiple projects is to have a product line architect.
  In this case, the architect needs to consider constrains and requirements beyond the scope of any single project. However, for this to be successful, this kind of architect should also come with the budget, schedule, and resources to make these decisions happen. If an organization is serious about a product line, it should finance that extra work which doesn't bring any direct benefit to the project where the initial work takes place. If this precondition is satisfied it is viable for the architect to override the project's manager constraints to get wider scope requirements prioritized. You can think of the architect in this scenario as a technical product owner (in the SCRUM meaning of product owner.
  

There can be variations on this (e.g. a large project where the architect is in charge of sub-projects) but the idea is the same the architect should either be part of the team -- working for the project manager, a consultant that you can opt listening to (but don't have to), or a "technical manager". That's someone who can override the project manger. But to do that, the architect should be backed up with the resources (or at least budget/schedule) to make this change.

What do you think?

Posted by Arnon Rotem-Gal-Oz at 04:28 PM  Permalink