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.

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.

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.