Header image large minimal

EAWheel

Share this blog

The Misplaced Enterprise Architect header

The Misplaced Enterprise Architect

Post date:

The role of the Enterprise Architect is misplaced in many organizations. In nine out of ten cases, the Enterprise Architect is portrayed as an IT Architect. This misalignment has significant consequences for an organization. The primary role of the Enterprise Architect is to help an organization achieve its goals. The Enterprise Architect role is ideally suited for translating organizational strategy into execution. This includes understanding the changes required for the intended transformation and determining their impact on all layers of the architecture.

Multiple mis-positionings

As already mentioned, an Enterprise Architect is (too) often positioned as an IT Architect. Odd, because the word Enterprise seems like a pretty obvious hint that the role extends beyond the confines of an IT department. There are also cases where the Enterprise Architect is incorrectly positioned as a Domain Architect (to support Portfolio), a Project Architect (to support Projects) or a Solution Architect (to support Solution Delivery). Each of these mis-positionings severely impacts the impact an Enterprise Architect has on and within an organization.

The Misplaced Enterprise Architect positionings
Purpose of architecture roles

If Enterprise Architecture is not positioned to support the strategy, it cannot help answer the why-question. In other words, Enterprise Architecture is unable to translate an organization’s strategy into effective execution. A similar problem arises when Enterprise Architecture is deployed to support Portfolio. I.e., this use of architecture can only answer the what-question. Deploying architecture to support Solution Delivery results in a scenario where Enterprise Architecture is limited to answering the how-question. The figure above shows the purpose of the different architecture roles, their interrelationship, the question the roles can (and should) answer, and the positioning that logically belongs to them.

Architecture to support Portfolio

In this situation, architecture supports change initiatives that span multiple functions, phases, and projects. An architecture for this purpose will primarily focus on a single portfolio. In other words, the architect is responsible for a single architecture domain, making the role that of a Domain Architect.

An example of a single portfolio might be migrating the organization to a cloud environment. Within the portfolio, which has a clearly defined scope, multiple projects will require the support of architecture. In this context, architecture is used to interpret and guide projects. The architect in this position ensures the alignment of the projects within the portfolio of the single domain. He or she also manages the coherence of the projects, and steers their execution. Architecture is thus less of an organizational steering function than when it is primarily concerned with strategy execution.

Architecture to support Projects

In the case of supporting projects, the use of architecture is tailored to the project delivery method of the organization. An architecture for this purpose typically covers one project. For example, consider moving an on-premises customer relationship management system to its counterpart in a cloud environment. This migration requires the architect’s involvement not only in the Application Architecture domain, but certainly in the Business and Information Architecture domains as well. So, in the context of supporting projects, architecture is used to clarify the purpose and value of the project, as well as to identify requirements and monitor adherence to architecture governance. In addition, architecture supports integration and alignment across projects.

Architecture to support Solution Delivery

Limiting architecture to support solution delivery results in an architecture that supports solution delivery within a single architecture domain. An architecture used for this purpose typically covers one project or a significant portion of a project. The architecture is used to define how the change will be designed and delivered. Constraints, controls, and architectural requirements for the design are identified as well. The architecture provides a governance framework for the change. Architecture used to support solution delivery is actually similar to Solution Architecture.

Doing it right

To ensure that the role of the Enterprise Architect is not misplaced, it should be positioned high in the organizational hierarchy. The only right place in the organization for an Enterprise Architect is in a department that deals with strategy and management support. This is the level at which the Enterprise Architect’s full potential is realized. It is at this level that the Enterprise Architect can make a real difference in translating strategy into execution. The hierarchical management of an Enterprise Architect should be done by a Board of Directors or senior management in the area of strategy and management support. Placing the Enterprise Architect in this position in the organization ensures that architecture issues can be considered across the organization.

Architecture capability positioning
Positioning of the architecture capability

Enterprise Architecture, governed by a Board of Directors, is used to develop a targeted architecture and create roadmaps that reflect organizational changes within the enterprise over a period of three to ten years. Thus, in this context, Enterprise Architecture is used to support enterprise-wide change requests and multiple projects and programs, and to achieve strategy execution through these projects and programs. There is ample room for Enterprise Architecture to shape strategic aspects such as drivers, goals, objectives, and initiatives. Enterprise Architecture used to support strategy is architecture in its most comprehensive form. Any other positioning introduces limitations and restricts the scope of the Enterprise Architect’s work.

Job Postings

Many job postings for an Enterprise Architect assume the role of an IT Architect. This is largely due to the fact that for decades, organizations have held on to the idea that the field of architecture is exclusively associated with IT. This narrow and limited view of the field keeps pushing the Enterprise Architect back into a box where the role does not belong.

Recently, for the first time in a long time, I saw a ray of hope. A Dutch organization put the following text in a job posting looking for an Enterprise Architect.

As an Enterprise Architect, you will work in the Governance and Strategy Department. This department is part of the Directorate of Strategy and Operations and is responsible for the vision, strategy and policy-making of the organization. At the strategic level, the department provides direction for the continuity and evolution of the organization. The department advises and supports management in strategic decision-making.

There is hope

As the years go by and the awareness grows that Enterprise Architecture is not limited to IT alone, there will be a growing understanding within organizations. This realization will make organizations aware that an Enterprise Architect in the right place in the organization can add much more value than the role is currently portrayed. As organizations move towards leveraging the full capabilities of the Enterprise Architect, the translation from strategy to execution will become faster and more effective. Organizations will gain more and more control over their operations. Until then, unfortunately, they will continue to struggle.

Do you agree (or disagree) with my take on the fact that the role of an Enterprise Architect is often misplaced within an organization? Please let me know by commenting in the comments section below.

Share this blog

3 responses to “The Misplaced Enterprise Architect”

  1. Michiel Jeuken Avatar
    Michiel Jeuken

    Post date:

    Your findings make sense, there is one thing that may confuse people “single architecture domain, making the role that of a Domain Architect” . I follow TOGAF (https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap03.html#tag_03_11), A-domains are used to organize expertise within an architecture team, these are NOT the domains of the portfolio you refer to. I would rename “architecture domain” to e.g. “portfolio domain” to prevent confusion. A portfolio could be any grouping that make sense, many times it is business related around a group of applications that need to work together to implement a capability.


  2. Eric Jager Avatar
    Eric Jager

    Post date:

    Thank you for your comment. I always appreciate feedback!

    I try to follow the latest edition of the TOGAF Standard, in this case the 10th Edition.
    As for the definition of an Architecture Domain (https://pubs.opengroup.org/togaf-standard/introduction/chap04.html#tag_04_12), it’s almost identical to the one you refer to.
    A Portfolio is “a collection of programs, projects, and/or operations managed as a group to achieve strategic objectives.” (https://pubs.opengroup.org/togaf-standard/introduction/apdxb.html#tag_06_30).

    According to the above definitions, an architectural domain is “the architectural area that is being considered“, i.e. all the elements and concepts that reside in that one area/domain. Thus, when a Domain Architect (DA) performs activities for a particular portfolio, he/she does so within the context of that domain. Should the portfolio require input from multiple domains, then multiple DAs would need to perform activities within the same portfolio.

    For example, if an organization were to create a portfolio in which it would move its information, applications, and technology services to the cloud, then multiple DAs would need to be part of that portfolio (a DA for the business domain (because processes will need to be adapted), a DA for the information domain, a DA for the application domain, and a DA for the technology domain).

    I am a strong believer in not creating new (non-existent) terms like “portfolio domain“. I think this only adds to the confusion that already exists in the profession.


    1. Michiel Jeuken Avatar
      Michiel Jeuken

      Post date:

      The following URL is in Dutch: https://academy.capgemini.nl/thema/de-rol-van-domain-architect
      Indeed creating a new term is not the right way, leave the term “Domain Architect” for the expertise area and consider “Segment Architect” in the portfolio context when required (most likely only for a large enterprise).


Leave a Reply

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

Subscribe to the newsletter

Want to be notified the minute a new blog is posted? Then subscribe to the newsletter.

You will only receive an email whenever a new blog gets posted.


Popular posts

The Misplaced Enterprise Architect header

The Misplaced Enterprise Architect

(2k views | 3 comments)

The role of the Enterprise Architect is misplaced in many organizations. In nine out of ten cases, the Enterprise Architect is portrayed as an IT Architect. This misalignment has significant consequences for an organization. The … (Read more)

Architecture Roadmapping header

Architecture Roadmapping

(1.6k views | 0 comments)

Architecture Roadmapping is an important part of Enterprise Architecture. The creation of a roadmap enables an organization to develop initiatives that are in line with defined goals and corresponding objectives. In effect, a roadmap represents … (Read more)

The TOGAF Standard is Awesome header

The TOGAF Standard is Awesome

(776 views | 0 comments)

We are probably all familiar with the TOGAF® Standard. Or just TOGAF, for friends and foes. An Enterprise Architecture framework pur sang and a very complete one if you ask me. The framework covers all … (Read more)