Maturing an Enterprise Architecture Practice

The following figure describes the EA Practice, which is the organizational implementation of EA.

Role definition, skills, and enablement facilitate the following:

• Define the role of Enterprise Architect Profession
• Identify and develop necessary Enterprise Architect skills within the team
• Establish a continuous learning culture within the EA team to stay updated with emerging technologies and methodologies

Organization / Operating Model defines the following:

• Define the role and responsibilities of the EA team in both active operations as well as governance.
• Decide on one of the possible organizational structure (informal, separated, federated, centralized; see the next slide for more details).

Governance defines and establishes the following:

• Establish an Architecture Board (to drive and be responsible for transformation governance, to manage EA decisions, etc.).
• Define and maintain principles, policies and standards for EA within the company.
• Ensure alignment and collaboration with other governance layers (project, process, data).
• Establish a change management process for the EA Practice.

Drive EA Framework Adoption, which shall include Methodology, Content, and Tools enable the following:

• Conduct EA Practice Maturity Assessment (including Target Setting).
• Possibly leverage consulting services to accelerate.
• Adapt the framework to meet company specific needs.
• Create an adoption plan and execute on it.

EA Community helps you to establish the following:

• Establish and Forster an internal EA community.
• Participate in external EA communities (DSAG, conferences,…).
• Position the organization as a thought leader in EA by contributing to industry publications, presenting at conferences, and engaging in collaborative research..

The following figure is an example of possible org-models for Enterprise Architecture.

Informal: There are no dedicated EA teams, but the EA profession and skills are integrated into other roles within the organization.

Pros: In early phases of EA adoption it may make sense to act as an informally collaborating virtual team which helps build a case for a more formal establishment of EA within the organization at a later point in time.

Cons: In the long run the non-existence of an official EA function entails missing out on many of the benefits an EA can have.

Separated: If organizational units operate in a more local mode, then this separated model would be appropriated.

Pros: If divisions are loosely coupled and follow different architectures and different architecture principles (as the division might support quite different business models and/or industries) it can be more effective to run separated architecture practices and teams.

Cons: Often, separated EA function can be leftovers from former acquisitions or just the result of strong leaders who like to run IT separately. In both cases not even establishing a federated collaboration is a miss, as synergies won't be recognized.

Federated/distributed: Each organizational unit establishes an EA role. All "local" EAs build a virtual EA team.

Pros: Compared to centralized models, distributed EA practices/groups have the benefit, that the EA function is closer to the business function they are collaborating with. The federated nature can help avoid redundant methodology and architectural conflicts.

Cons: Federating and distributing an EA function works fine as long there are no collisions of interests. Problems arise when divisions have no clear conflict resolution paths in place. This can lead to competition or even fighting. In such cases the federation will no longer work properly, and the company might relapse into separated working modes.

Centralized: Establish a central EA team responsible for the whole organization.

Pros: If centralized / corporate functions are core elements of a company's culture, running a centralized Enterprise Architecture function in a matrix approach across functions can work very well.

Cons: In very large organization running only ONE centralized architecture function can be a risk as such a team would have a hard time keeping close enough ties to other functions and divisions. Typically, such a team will not be adequately staffed to support many large transformations. And if that team would consequently focus only on governance this could be seen as policing and therefore risk the centralized EA team's acceptance.