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.