The 6 Factors to Consider When Building Your EA Organization

Posted by Sarah Glittenberg on July 9, 2018


Enterprise Architecture stakeholders, operating models, and more!

When starting to build your enterprise architecture organization, EA leaders should consider several factors such as EA team size, EA structure, and EA operating Model. We list and explain all necessary factors for you in this blog post.

1. Understand Your EA Stakeholders

The ideal enterprise architecture supports the needs of a diverse set of stakeholders. Before building your EA organization it is beneficial to start identifying your set of stakeholders including new ones, you have not yet worked with (i.e customers).

In general, stakeholders are people who deal with the creation, development, operation or removal of elements of the EA. Typical stakeholders of EA are the CIO, CTO, Solution Architect, Finance Officer, Business Process Manager, IT Program Management, and Developers. Each stakeholder is characterized by different key attributes and has different informational needs that can be solved by enterprise architecture. For example, A CIO’s role is to create business value from technology.

A CIO could have the following questions, including:

  1. What is the application roadmap?
  2. In which applications should we invest, in which applications should we divest?
  3. What is our cost structure?

These questions can be answered with Enterprise Architecture views: 

  1. Application lifecycle map
  2. Application matrix displaying the functional and technical fit of each application
  3. A Heatmap displaying provider cost

An architecture model should pinpoint the stakeholders of an EA and address their informational needs. After five years in the EAM field, we've collected the top questions from each stakeholder and devised ways to answer them by using Enterprise Architecture views.

These viewpoints frame one or more concerns of stakeholders allowing them to concentrate on the topics relevant for themselves. In return, this approach will strengthen managerial support, stakeholder buy-in and stakeholder engagement which is of importance for the success of EAM.


New call-to-action


2. Involve Your EA Stakeholders

Preserving continuous stakeholder support is a critical undertaking. It involves determining who is likely to influence or be affected by EA, and identifying the matters that drive them and guarantee their support. Gartner recommends following four major levels in their stakeholder engagement initiative. These levels may vary, depending on the organization and the scope of its EA program.

  1. “Strategize and Plan: Develop the plan to institute ongoing processes to develop and maintain key stakeholder support.
  2. Assess Current State: Assess the enterprise's history, culture and key stakeholder attributes to enable the identification and institution of appropriate best practices.
  3. Assess Competencies: Use current-state analysis to identify and select appropriate best practices and necessary competencies.
  4. Operate and Evolve: Operate and evolve appropriate best practices and necessary competencies to generate and maintain stakeholder support.”

Source: Gartner 2010 


Enterprise Architecture Success Kit [White Paper]: Everything you need for  quick time-to-value and long-term success through EA. »


3. Choose an Operating Model

After first and second criterion has been accomplished, you are on a good path from organizational silos to an interconnection between all stakeholders. To create an effective EA organizational structure, it is now the time to choose the right operating model, which helps to build the first layer in the foundation for execution in an Enterprise Architecture.

Enterprise Architecture models vary widely. Each type has different pros and cons, depending upon program size, mission, and business drivers. Therefore, we will only highlight the most common one here:

  • Coordination Operating Model:
    This type is characterized by a shared customer, product or supplier data but operationally unique business units that can impact each other’s transactions.  These autonomous business units have a high degree of control over business process design to adapt to its specific operations. 
  • Unification Operating Model: The model underlies a globally integrated set of business processes where customers and suppliers are distributed geographically.  Business units have similar operations where process and data are designed centrally so they can be shared.  Centralized management of these processes typically leverages a matrix approach to keep track of the business unit composition.  Although the business units have distinct operations, high-level business process owners work to standardize business processes across the business units. 
  • Diversification Operating Model: This approach is based on the fact that business units have few, if any, shared customers or suppliers.  These business units also are operationally unique and have transactions that are independent.  There is minimal business process standardization and integration in this model.  Most IT decisions and business process design are made at each business unit.  However, these business units do leverage a common set of shared services that can be integrated into their specific environment.
  • Replication Operating ModelSimilar to above approach this model has only a few, if any, shared customers or suppliers.  The autonomous business units in this model leverage a federated approach to business process integration and standardization.  Business process design is centrally managed as is IT services.  The information architecture is standardized with canonical data definitions but the actual data is locally owned with some aggregation to the enterprise.  From an operations perspective, the business units are very similar in execution.

Source: Sogeti Labs 


4. Define the Structure of Your EA Team

As organizations decide to establish their own EA practices, one of the most frequently asked questions is about how to structure the EA team. The determined structure will in the future significantly contribute to the effectiveness and success of the enterprise architecture practice in the future. Certain decisions made in the beginning of an EA practice will make it easier to receive organizational buy-in and perform the role at a strategic level.

According to Forrester, EA team structures vary widely. EAs get pressured by their organization to implement powerful, strategic technology programs using restricted resources.

However, most EA leaders have a small team, limited budgets, and little decision-making power. To cope with these challenges, EA leaders create organizational structures in all shapes and sizes - centralized, federated, hybrids, and various composites of all three. The EA team structure outlines how EAs will be distributed between assigned across one or more leaders as they search for the best format to drive EA success.


The Enterprise Architect of Tomorrow [White Paper]: Practical insights on how  to become data-driven, agile-minded, and forward thinking. »


EA leaders can decide to centralize EA practices, with all architects based in one department, or spread various autonomous architecture groups (decentralized), each reporting to a different manager. There is also the option to create a hybrid of both, as described in the table below. The federated approach, as it is called,  allows to have a centralized architecture group and architects in other technology management areas with dotted line responsibility to the central group (Source: Bainstitute). As a result, no two EA teams look alike. The key to success is not a specific team size or organizational placement but how the team spreads its resources by collaborating with, and leveraging others throughout the organization (Source: Forrester). 


Enterprise Architecture Team Structure

Source: Bainstitute  


Whether you should manage your team centrally or decentral depends on your organization's maturity level. Try to look at best practices and determine what works best for your organization. 


5. Build Your EA Ecosystem

As explained in section 1, a successful EA practice involves the buy-in from various stakeholders. For this reason, it’s important not to only focus on the core EA team, but also on how it works with the wider team.


The Core EA Team

The center of the team is comprised of a group of enterprise architects who own the overall EA structure, define the standards, and develop the business-aligned strategy. According to Marcus Blosch, research vice president at Gartner, “Organizations no longer want their enterprise architecture (EA) practice to solely focus on standards, structure and control. (…). They want an EA practice that is focused on driving business outcomes, working in a flexible and creative way to help define the future and how to get there.” He believes the EA practice must overcome its business-outcome-driven architecture to include a new group of talents, which support digital business and digital transformation. 

Therefore, it is essential to have these 5 traits in your EA team:

  1. “Architect the possible: A talent for developing business strategy
  2. Design the new: A talent for designing new services and experiences
  3. Do it differently: A talent for innovation
  4. Enable collaboration: A talent for orchestrating collaboration across the organization
  5. Guide the journey: A talent for navigating to the future” (Source: Gartner)
New call-to-action

The Wider Team

While technical skills are essential for your core team, EAs should not lose the ability to deal with numerous other stakeholders in a changing and sometimes chaotic environment. These other architects of the IT ecosystem (i.e. solution architect, technical architects, business architect, PMO, etc.) act as an extension to the core team. Close collaboration is essential to ensure a free exchange of ideas and information between the parties.

5. Size Teams Correctly 

When asking an IT consultant what is the best size of an enterprise architecture team for an organization, you will probably hear the answer: “it depends”. Well, his answer is correct! The correct question needs to be: “What are the factors used to determine size of an EA team in an organization?” There are some simple guidelines EA leaders may follow to determine the appropriate size for their team:

Here is a checklist of factors used to determine the size of an EA team.

  • Number of products/services provided by the organization
  • Revenue of the organization
  • Profit of the organization
  • Business process maturity of the organization
  • Finance & controlling maturity level

Followed by the technical IT factors used to determine the size of an enterprise architecture team.

  • Number of people (including employees, contractors, consultants, out sourced) and their ratio
  • IT budget and Finance management controls
  • IT Process and system maturity level
  • Enterprise architecture adaption rate (or EA maturity assessment)

Based on the above factors the EA team can be classified as large, medium and small. Large teams consist of 50+, medium teams are of a size between 15-50, and small teams have less than 20 architects. (Source: 2008)

In Conclusion:

When starting to build your EA team, factors like stakeholder buy-in, different EA operating models/structures as well as team size need to be considered. Many of those factors are depending on your organization's maturity level, an EA leader's budget and decision-making power.

We suggest you to look at best practices, speak with other EA leaders within your industry and determine what works best for your organization. You will continue to progress and grow over time in ways that meet the needs of both the team and the organization.

You have been through this process already? Tell us about it in the comment field!


Enterprise Architecture Success Kit