Two roles for enterprise-architects

A great discussion yesterday with Mike Turner reminded me that there are two radically different roles for enterprise-architects:

  • the internal enterprise-architect
  • the external enterprise-architect

They’re both focused on ‘the architecture of the enterprise’, but it’s important not to mix them up, because they require different temperaments and different approaches to business-relationships.

The internal enterprise-architect is actively responsible for the ‘enterprise DNA’ of a single organisation. They typically either report direct to the CEO (who has the ultimate authority and responsibility for that ‘DNA’, but in practice probably doesn’t have the time to do much about it), or else are attached to the CEO Office or a senior-level strategy-group.

The key point here is that, to use Kevin Smith‘s term, this enterprise-architect role acts as “the glue between strategy and execution” – which means that they need direct person-to-person relations with people at all levels and in all domains of the organisation and enterprise. Developing these relationships takes time, and a lot of time at that – often ten or more years in a typical large organisation. Hence the best people for this kind of role are those who’ve “come up through the ranks” and built a personal network on the way, or – even better – have grown up with the company, “have been in from the start” or suchlike. (The CEO can and should do the enterprise-architect role for a start-up, but once the organisation grows beyond about a dozen people the role will typically need to be part of someone else’s explicit responsibilities, and once we get past the crucial social-network boundary of Dunbar’s number – roughly a dozen-squared – it needs to be a distinct role in its own right.)

This role is about how the idea of enterprise-architecture – that “things work better when they work together, with efficiency, with elegance, on purpose, in practice” – is expressed throughout this organisation, in terms of this organisation’s business-purpose.

The external enterprise-architect (or consultant enterprise-architect) is actively responsible for promoting the ‘idea’ and practice of enterprise-architecture itself. It’s important that they maintain their independence as much as practicable, though for practical reason many will work via the auspices of a consulting-organisation of some kind. Their person-to-person relations are with other architects – again in many different domains and at all levels, but across many different organisations and enterprise-types.

Their primary role is practice-refresh for in-house enterprise-architects: they help to keep the overall architecture up-to-date on methods, practices, and frameworks, and help to lift the architecture-maturity and architecture-capability of the internal team. They also act as external peer-review, to reduce the risk of an insular and often destructive ‘groupthink’ developing within an organisation. This role too requires many years of experience, but this experience will have been gained across multiple disciplines in multiple organisations and, preferably, multiple industries.

The internal enterprise-architect deals with architecture in depth; the external enterprise-architect deals with architecture in breadth. An organisation’s architecture gains most from an appropriate balance of these two roles – not one or the other, but always some of both.

The worst possible combination of these two roles is unfortunately that which many large consultancies try to promote: full long-term control of an organisation’s enterprise-architecture by an external consultancy. An enterprise-architecture works right at the core of an organisation and enterprise: hence assigning responsibility for the organisation’s DNA to an external party is not a good idea… You Have Been Warned! 🙂

Tagged with: , , , , , , , , , ,
3 comments on “Two roles for enterprise-architects
  1. The other possible scenario is to have only one in place.

    To solely have the internal (depth) enterprise-architect tends to be isolated to the external potential impacts of the extended organization. Too many organizations have a degree of chaos they are not even aware is hurting them because companies become comfortable with the dysfunction (see the degree of internal politics or the this is how we always do it mentality).

    To solely have the external (breadth) enterprise-architect tends to achieve the committment of change. Their vision may be too grand for the potential of the organization at this time. Though they communicate well with the upper management, the external enterprise-architect will not have the ability to break down some dysfunctional processes in place.

    So, for an organization to be able to build an effective enterprise-architecture that spans breadth and dives deep will require both individuals. Two who understand the value of each and can work together to move the mountain.

  2. Rob McKee says:

    A bit like the old adage “inch deep mile wide” versus “inch wide mile deep” both in conjunction will formulate a complete picture of the organization or can be utilised seperately to facilitate a particular view as required.

  3. Dennis Kosse says:

    when I focus on the IT part only:

    How would you define the ‘Enterprise’ Architect that is within a IT-Services organization that falls partly in the internal category, but also not in the external one. It is the role that is needed for aligning the strategy of the IT-services organization (so business) within the IT deliveries/services towards multiple customers. (so IT that is not used within the own organization, but has to meet the business strategy)

    Normally the Enterprise Architect is defining/guiding the IT components (applications, systems, etc) aligned the own strategy. In an IT-services organization this is partly true, as the goals/strategy of the organization itself are different from its customers which use the actual IT components.

    So for example the IT-services organization wants to be flexible with its custom-developed-components on top of systems, so it can use it within multiple customers. This does not reflect in any way the users (customer organizations) goal or strategy.

    Anyone agrees with this view ? (I’m looking for a framework such as TOGAF to support this kind of role)

Leave a Reply

Your email address will not be published. Required fields are marked *

*