The Roles of the Architect

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”

  • Great list Todd. I think my role files under the last heading, plus another component. I work for a company with almost 100,000 employees, hundreds of applications, and dozens of simultaneous projects. Therefore, a big part of my role as an architect is just making sure we know what systems are running, and making sure they can talk to each other.

  • Rob Eamon:

    I found this web site very interesting when read in the context of your blog entry:

    I’ve always found it interesting that we tend to have a hierarchy of folks–all with the architect title. The technically-focused folks probably aren’t “architects” at all but are closer to engineers.

    Another comparison of titles that is interesting to explore comes from the entertainment industry. Producers, directors, production managers, etc.

    Why does it seem that IT roles and titles are fuzzy and continually change when other industries seem to have it settled down?

  • Great dialog! I’m glad to see the discussion, as its an indicator the profession of architecture is evolving/maturing. I believe the role of the architect (and architecture teams), becomes more defined as a company’s IT organization matures, regardless of the size of the organization.

    Good architects tend to be good leaders, hence the natural adoption of the PM roles as they try to get the portfolio of work done. I agree with Todd, I think project management and architecture are completely separate roles. I think Architects should not manage the project, but provide the valuable input to the project approach, activities, and in some cases the tasks that must be accomplished. At this level I don’t think we should even give the architecture title, as they are more like solution engineers. Solution Architects, or engineers if you buy thoughts, probably should be considered an advisor to the Project/Program Manager. Having great PMs are absolutely critical to implementing architectural vision, but should not be the architects/engineers themselves :o)

    Rob’s comment about engineers is important. The architects should be providing the guidance from the big picture perspective, as well as corporate strategy, and policy. The engineers are on the ground implementing the architecture. In many organizations the two roles Architect/Engineer are merged into a single position/title. As the disciples mature I see the separation of roles represented in IT organization positions to become more pervasive.

    My observations for an IT organization:

    Solution Engineer – is responsible for technical leadership for an entire solution, orchestrating all the technical aspects of the solution together.

    Infrastructure, Application, Information, Security, Architects responsible for thier areas of expertise, and have corresponding Engineers for each.

    Then Enterprise Architecture which is a combination of technology and business strategy.

    Chief Architect/CTO



  • Rob Eamon:

    Like the term SOA, architect is overloaded and ambiguous. As Todd points out, noone defines architect the same way, so why in the world do we keep using the term? Shouldn’t we use terms/titles that are well understood?

  • […] previous post discussed how no two organizations seem to define the role of the architect the same way. It just […]

  • What We Collectively Bring to the Table…

    Joe McKendrick uses my sometimes testy (and I agree) dialog with certain enterprise architects (cough cough…) to ask the question of who should own and lead SOA efforts in organizations. He also quotes extensively from an article by ZapThink’s Ron…

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.