Todd Biske: Outside the Box

One thing that I have noticed over the past few years of my career is that no two companies define the role of the architect the same way. Personally, I view this as neither good nor bad, and this isn’t going to be a post on the whole architect certification efforts that exist out there. While it may make it more challenging to find qualified candidates when the definition of the role changes from company to company, once you’re in a company, clarity of the specific responsibilities at that company are certainly more important than whether or not you’re doing the same work as Joe or Jane Architect down the street. As another aside, I also think that those job responsibilities should serve as a guide, but not a barrier. All organizations require some flexibility in what people do if they expect to get things done versus devolving into a finger-pointing episode of people saying, “That’s not my responsibility.” Which brings us to the first type of role.

The Gluer

In this role, the person with the lucky fortune to have the architect title is expecting to hold everything together from a technical perspective. A typical software development project involves far more technical tasks than just writing code. Servers may need to be built, software installed, routers configured, etc. Put simply, the person playing this role was expected to be the glue that holds everything together from a technical perspective. You’re probably asking, “Isn’t this the job of the technical lead?” Well, the problem with the technical lead is that in most organizations I’ve seen, it was purely a role, and not a job title. Therefore, it was difficult to actually know who the technical leads were in an organization, get coverage across all projects, etc. Titles like senior developer or lead developer don’t cut it, because the emphasis is still on development, and not the other tasks involved with getting something into production. Unfortunately, giving them the title of architect is problematic. While it does allow an organization to establish some clear technical leadership, it’s likely that the individuals with this title will be so consumed with tactical project decisions, that very little of their time will actually be spent on architecture.

The Scheduler

While I never would have guessed this one, I heard it mentioned at two different organizations that architects are supposed to act as project managers for technical activities, normally working in conjunction with the “real” project manager. While I do think that all leaders should have some ability to do basic project management activities. That is, break down a goal into some set of constituent tasks on a timeline. There are certainly ties back to the gluer role, as this essentially takes the technical leadership a step further. In addition to identifying all of the technical activities, the person now has to manage all of them, rather than delegating this back to the project manager. Of all the roles, this one is the least desirable to me because I don’t consider project management a strong point for me. I’m admittedly a big picture thinker. Most good project managers I know are extremely detail-oriented. The best working scenario for me personally, is not to have me be the project manager, but work side-by-side with the project manager.

You’ll notice that both of these roles are very project-specific. If all of the architects in your organization are on project assignments, that’s a problem. Project, or solution, architecture is important, but you also need architects outside of projects, hence the next two roles.

The Decision Maker

This architect is normally not assigned to projects, but is still involved with the decision making process within projects. This person is likely viewed as the top of the technical hierarchy within some organizational or technical domain. If it’s associated with software development, I typically see it following organizational boundaries (e.g. an architect for all solutions developed by one development organizationy), while on some of the other activities, it follows technical domains, such as a Security Technology Architect, a Networking and Communications Technology Architect, etc. Projects go to these architects when decisions need to be made or approved. The challenge I’ve seen with this role is the flood gate, especially when the title is first established. Many organizations don’t have a technical hierarchy in their organization, and as a result, it can be unclear as to who has the technical decision making responsibilities. As a result, when someone is granted the title, the flood gates open, and every technical decision, even those that should be no brainers, wind up coming to those deemed “architects.” The challenge here is that the architect winds up having all their time consuming by decision making, with no time left over for establishing a strategy and direction.

The Strategist/Policy Maker

At the opposite end of the spectrum from the decision maker. Architects acting in this capacity are the legislative branch of the government, focused on established reference architectures, policies, roadmaps, etc. I thought about breaking this into two roles, because there are plenty of architects who don’t do strategy, but in general, the perception of the enterprise is similar. There’s a significant risk of becoming an ivory tower in this role. Just as the decision maker gets sucked back into project activities, the strategist can become disconnected from the reality of projects.

So what’s right? Personally, I think an organization needs gluers, decision makers, and strategists. We already have project managers, and as I previously stated, I don’t think we need to break out “technical” project management as a separate discipline. Should the remaining roles all have the “architect” title? In my mind, there’s really only debate about one role, the gluer. Clearly, not all of the activities associated with technical leadership have something to do with architecture. At the same time, however, if it’s not clear whose responsibility it is, these technical concerns will bubble their way up to the “decision makers.” If it’s necessary to bless that role with a title like “Solution Architect” to avoid this scenario, then do it.

What other roles and responsibilities have others seen with architecture? What’s missing from the list?

7 Responses to “The Roles of the Architect”