How to create an Enterprise Architecture functionSajid Khan Niazi
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.
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
We recommend using an existing enterprise tool such as Jira to create the EA demand management funnel.
Phase three: Documentation of EA
- 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.
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:
- 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.
- 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?
Below, we have set out some of the key EA artefacts.
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.
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)
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:
|Level 1||Level 2||Level 3||Current state||Interim state||Target state|
|Sales quota management||HubSpot||Salesforce|
|Marketing||Campaign management||MailChimp, ActiveCampaign||Salesforce|
|Campaign tracking management||MailChimp, ActiveCampaign||Salesforce|
|Web to case||ServiceNow||Salesforce|
|Email to case||ServiceNow||Salesforce|
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
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:
|Name||Description||Business capabilities||Business unit||Owner||Hosting (On-premise / cloud)||Status (keep, replace / sunset)|
|Salesforce||CRM application||Sales management, Marketing management, Service management||Professional services||John Doe||Cloud||Keep|
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.
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.
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.
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.
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.
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.
What happens to organisational reporting lines in Agile transformations?
Podcast: What are the drivers to delivering successful business change?
Five tips for companies wanting to instil effective change
Capitalising on the benefits of Artificial Intelligence of Things: Opportunities presented by AIOT
Transforming your organisation to succeed with data: Part one