How to create an Enterprise Architecture function

The aim of this article is to highlight key activities that are required to establish a new Enterprise Architecture function from scratch within a firm.

Big and complex organisations have challenges optimising performance on an ongoing basis due to an inability to understand the bigger picture, as well as changes to macro and micro levels. This can limit their agility and efficiency which reduces effectiveness, profits, and large-scale enterprise transformation success as a result – not to mention a loss of competitive advantage.

Read next: How an enterprise roadmap will help you respond to change in today's technical jungle

Enter Enterprise Architecture

To solve these challenges, firms can leverage Enterprise Architecture (EA). Using EA, they can adopt a method to continually document and model all aspects of the organisation and use the architecture information to support planning and decision making.

Some of the key outcomes of implementing EA include:

• Managing the enterprise as a coherent whole

• Achieving strategic goals that depend on managing change or implementing new business processes and technologies

• Supporting planning and decision making for M&A and business unit consolidations

• Improving business performance by maximising technology alignment and efficiency

• Reducing duplicated resources across the enterprise

An approach to EA implementation

EA implementation consists of the following four phases:

We will now examine each of these stages in more detail.

Phase one: EA programme establishment

Establish the EA programme by identifying the Lead EA / Head of EA and define the implementation and governance approach. It is essential to also identify other key architects (solution, infra, security) who will help with capturing the EA artefacts. At the same time, it is important to establish the scope of EA work – for example, do we capture the architecture for the whole enterprise upfront or gradually develop it starting with certain business segments? Both approaches have pros and cons. Doing everything upfront is time consuming and can take some time before the EA starts to deliver value. In our experience, organisations can start to reap to benefits quickly if they start small and gradually document and develop their EA.

Phase two: Framework & tool selection

During the second phase, the focus lies in:

• Selection of an EA framework

• Agreement of the tools to use for EA repository, diagrams, and EA demand management

As requests for enterprise-wide changes will come from various parts of an organisation, it is important to have a common place to manage demand, create a pipeline of work, and assign change initiatives to different Enterprise Architects to work on them. We recommend using an existing enterprise tool such as Jira to create the EA demand management funnel.

Phase three: Documentation of EA

This involves:

• Identifying any existing architecture for use and creating missing architecture documentation

• For individual change initiatives, creating current / target architecture using the EA change structured format

For documentation, organisations will need an EA repository and to agree on the list of EA artefacts that will be stored there.

EA Repository

All architecture artefacts need a place for storage, sharing, and collaboration, and there are a variety of specialised tools available for this. However, we suggest starting with the tools already available and used by architects in the organisation. The aim is to create ‘live’ architecture documentation that is consistent and kept up to date by different architects including Enterprise, Solution, Technical, Data, and Security. The following are examples of existing enterprise tools that work well for EA:

Confluence:

• Architecture documentation covering all key systems within the enterprise. At a minimum, each architecture documentation should include context, interface, and deployment view

• Architecture principles & standards

• Business capability mapping

• Enterprise reference architecture (10,00 ft of the enterprise)

• ARB members list & their roles

• Architecture Design Decisions (ADD)

SharePoint / Google Docs:

• All EA presentations presented at Architecture Review Board (ARB). This will allow organisations to track all ARB decks in a single place.

Lucid Charts:

• Diagramming tools for creating architecture diagrams (current/target architecture state, context/interface/deployment views, reference architectures, etc.)

• All architecture diagrams should be kept in a single place for ease of access and collaboration

EA change structured format

It is good practice to present enterprise-wide architecture changes in a structured format, giving members of the Architecture Review Board (ARB) the context and drivers needed for change, as well as defining the current/target architecture state. We recommend including the following in an ARB deck:

• Change initiative information: Name, description of change, drivers for change (why now), sponsor, etc.

• High level business requirements: List of key requirements

• Current situation: What exists today in terms of solutions/processes and any challenges faced

• Current architecture: Context view showing existing systems and their high-level interfaces

• Target architecture: Context view showing newly proposed architecture with new/updated systems/interfaces

• Capability mapping: Showing the tabular view of level 1-3 business capabilities along with their current state, optional interim state, and target state

• EA checklist: For example, does the new solution require compliance to a specific law? Is data privacy impact assessment needed?

EA key artefacts

Below, we have set out some of the key EA artefacts.

Architecture principles

EA governance happens against business strategy, architecture principles, and the EA roadmap. Existing principles from an EA Framework such as TOGAF can be adopted and tailored for the enterprise needs.

Architecture standards

An enterprise can adopt architecture standards that any new change initiatives must adhere to. Standards come in the form of policies, guidelines, constraints, or conformance criteria and can be linked to the business, data, application, or technology part of EA. This might include:

• Integration standards: For example, mandating use of ESB for all integrations

• Development standards: For example, Design Patterns, Architecture Patterns, Approved Technologies/Programming languages

• Security standards: This includes required integration with the enterprise’s Security Operations Centre (SOC) for any new systems

• Legal standards: For example, compliance with GDPR (General Data Protection Regulation)

Enterprise reference architecture

This is a high-level view of the whole enterprise, listing business and support divisions. It also shows the level one business capabilities and enterprise systems supporting those capabilities.

Business capability mapping

A business capability is focused on what the business does or can do to achieve an outcome. Business capability mapping allows an organisation to capture the level 1-3 business capabilities and map the relevant current, interim, and target systems to those capabilities. A typical business capability mapping document will appear something like the below:

Value streams

Value stream modelling is a technique used to analyse the main activities required to offer value to either an internal or an external stakeholder. At this point, we should aim to capture all the key value streams within the enterprise.

For example, an insurance value stream appear similar to the below:

Architecture documentation using architecture views

To support enterprise change initiatives, it is important to have the current state architecture defined for all key systems. ARB process can be a good starting point for capturing current architecture context views when there is no existing architecture documentation. A typical architecture documentation for a system should contain the following architecture views:

• Context view: Useful for EA current/target state discussions and presentations

• Other architecture views that can be gradually developed by Solutions Architects: Interface, Design, Deployments, Data, Security, Operational and Non-functional view

Application catalogue

An application catalogue captures the inventory of all the key applications that are owned by the enterprise, whether they are on-premises solutions or SaaS solutions. It will typically capture the following information about the enterprise applications:

EA roadmap

An enterprise architecture roadmap is a strategic blueprint that communicates how a company’s IT plans will help the organisation achieve its business objectives. It can be developed by analysing the current and target EA state and identifying the gaps that must be taken care of to achieve the target state.

Phase 4: Use and maintenance of EA

Once an organisation has put all of the key structures and EA artefacts in place, any new enterprise-wide change initiatives should go through the agreed EA change management process. This process should define how demand will be managed, who will triage the change request, how/what will be presented to ARB, and when the change initiative will receive funding approval.

Architecture governance

At the enterprise level, EA Governance plays an important role. Through governance, an organisation can assess and control enterprise-level change initiatives and decide to approve or reject them if they are not aligned with the business strategy, EA principles, or roadmap.

Role of Architecture Review Board (ARB)

The ARB is central authority which provides enterprise-level governance. It is important that it meets at least a couple of times a month to go through the change initiatives.

ARB stakeholders

It is important to ensure that the ARB has balanced representatives from both the business and technology arms of the organisation. There is no ideal number or split percentage between the two. The important thing is that both sides are well represented in the ARB to provide governance and assurance.

EA Meetings

Several meetings are required to complete and present a change to ARB. These include:

Meetings with business and SMEs

This is where the assigned EA works with the different stakeholders to understand and document the need and drivers for change and captures the current/target state.

Pre-ARB

We recommend having a weekly pre-ARB meeting with the CISO, Data Protection Officer, and Lead Infrastructure Architect to ensure that the proposed change is aligned in terms of legal/compliance/data privacy/security requirements.

ARB meeting

All new enterprise architecture change initiatives need to be presented at the ARB meeting. This ensures that stakeholders are aware of the change initiatives, there is knowledge sharing at the enterprise level, and non-aligned siloed initiatives are brought to the board’s attention for scrutiny. It also presents an opportunity for the approval or rejection of change initiatives to ensure alignment with the business strategy. We have found that ARB meetings are most effective when the key stakeholders regularly join the meeting and ARB presentation material is distributed to them at least a day in advance.

In a nutshell

By creating an EA function, companies can alleviate some of the complex challenges around optimising performance on an ongoing basis and ensure that IT is well aligned with business strategy to achieve its strategic outcomes. If you need help establishing an EA function or EA roadmap to align with business strategy, please get in touch.