CEB Blogs


Information Technology

Four IT Architect Types: Which One Are You?

We have a diverse membership in the Enterprise Architecture Executive Council, which keeps us researchers on our toes.  IT enterprise architecture groups are heterogeneous in many ways–mandates, reporting structures, titles used for IT architects, and team sizes all differ so widely that it can be a real challenge to make generalizations or comparisons between member organizations.

It’s not just the structure of EA groups that differ, but their core identities as well. These core identities inform the challenges and priorities as well as the approaches and outcomes for different groups.

Because we don’t have a lot in common, we need a shorthand for identifying different EA group types. Without a typology, we invariably invest significant time just trying to level-set before we can address our individual approaches to common challenges and the relative priority of those challenges. We have come up with four major types of architecture leaders/groups. Which of these IT architect types do you most identify with? Answering that question can provide insight into how you can manage your blind spots, as well as your opportunities.

The Firefighters: They save the day, but may lose the year.
We wrote extensively over the past year or so about how commonly we’re finding members who are being engulfed by project work. For some organizations, as much as 90% of their EA bandwidth is consumed in these engagements. This type of IT  architect is not likely to be accused of being too “ivory tower,” but with their heads down in solution design or in some cases even engineering, they’re unlikely to make inroads toward identifying or roadmapping toward a target state. For firefighters, we recommend taking a hard look at resources allocation and defining a set of core EA services to manage demand, not react to it.

The Governors: They reduce portfolio complexity–and speed-to-market.
This IT architect type is defined by its role in architecture governance. These architects ensure that standards are adopted, exceptions are minimized, and authority is respected. While complexity reduction is surely a key facet of EA, governors run the risk of being perceived as another of EA’s cliches–project police. If governance is your core identify, enlist solution delivery teams in self-governance by providing early education about EA standards, and the benefits of adopting them.

The Planners: They set the menu, but don’t eat.
Planners are focused on the target state IT architecture, but can lack credibility with delivery teams and business partners who see them as too removed from the constraints and context of the “real world.” Planners are IT’s dreamers and enjoy a broad and long-range view of the enterprise. Many consider this identity to be the essence of EA, but planners break faith with their operational counterparts when they attempt to plan too comprehensively, rather than in the areas of greatest change (and therefore, need), and when they are misaligned with demand. Planners will struggle to see their future states realized without a strong commitment to relationship building with key business interfaces. The talent bar for planners is high; they need strong engagement skills and an acute sensitivity to shifts in demand. They then need the will, incentive, and capacity to act on those shifts.

The Testers: They run innovation labs more than IT architecture.
Perhaps the least common of our types, testers are nevertheless a distinct profile we see in the membership. Testers contribute value by formalizing innovation and new technology introduction for the enterprise. The organizations they serve are typically aggressive adopters of technology and place a high premium on gaining competitive advantage and recognition through their advanced use of information technology. The challenge for testers is that traditional methods, while rigorous, cannot anticipate (or frankly, control) the federated nature of experimentation in the world described by the Future of Corporate IT. Testers can’t beat ’em and should instead coopt ’em.


2 Responses

  • sune says:

    Nice post and I guess my type depends on personal bias and background. Furthermore, most of us are probably a little of all with one or two dominating part.

    More importantly, a consequence of the above is that you need to ensure that your team of EAs actually cover all 4 types. Otherwise you may end up just governing, planning, testing or firefighting. Which will get you nowhere :o)

    Thanks for sharing

  • Mark Griffith says:

    Because there can be all of these types within the standard terms used today, I appreciate the terms selected; avoiding terms such as Domain, Solution, enterprise architects.
    In my EA program I have faced all of these challenges and dealt with them by segmenting the group to focus on delivering on all of these capabilities. The reality in EA programs is that we need to perform all of these functions and we cannot allow one to trump the others. Shevtank is correct that projects can overwhelm any EA program; firefighting on production solutions can do so as well. To that end, I broke these functions out into different groups and keep the teams focused on delivering and performing at a high level. The firefighting, testing, and assessments on anything in place go to my IV&V team (Independent Verification & Validation). The governance and planning go to my traditional EA team. And, the project engagements go to project level architects deployed to the project teams. This has worked well for a while now.

Leave a Reply



Recommended For You

What Do CIOs See As The Strategic Direction of IT?

Many of the CIOs we surveyed emphasized that IT will need to contribute to firm-level...