Architecture Essays
A Standard Template to Define Your EA & Technology Strategy
Enterprise Architecture
Constant, well-managed change is the lifeblood of enterprise success. So, everything in the EA Practice leads to this — the Enterprise’s Architecture and Technology Strategy and Plan, the EATSP.
(Although this template is tailored for commercial businesses, it can be easily used for government and non-profit organisations by changing the inputs to be the motivations and plans of such organisations.)
The actual artefact is a Microsoft Word document, but I’ve extracted its contents here so you can study it directly. (Only the Title Page and Table of Contents are images.)
You can get the document file from here: https://quality-thinking.com/product-category/it-architecture-materials/
1 About This Document
1.1 Purpose
This Enterprise Architecture and Technology Strategy & Plan (EATSP) document is the core deliverable of the Enterprise Architecture function. It defines IT Architecture and Technology by studying business plans and analysing how to enable them with new or modified Information Technology.
The systematic approach of this artefact is indispensable for optimising the fitness and cost-effectiveness of IT for the enterprise. Wherever IT plays a big part in its products, services, and internal workings, the EATSP can be the difference between business success and failure.
The Enterprise Architecture & Technology Strategy & Plan provides the following to different users.
· Business Owners — The assurance that IT will back up their aspirations for the market and internal efficiency.
· IT Leadership — A clear roadmap for delivering what it needs, with the requisite business support, funding, and time.
1.2 Document Scope
In landscape terms, this document covers all enterprise domains and actors.
In time terms, the strategy and planning are typically done for one-, two-, and three-year windows. However, the periods can be reduced or increased per business needs.
In EA method terms, this document is the over-arching document for the EA’s Strategy and Planning.
Please see this article for the overall EA Practice Method, of which this is an integral part: How to Practise Enterprise Architecture.
But it depends on the following separate documents. Please see Appendix C for templates, etc.
1. The Enterprise Business Plan Document
2. The current Enterprise Architecture & Technology Document (EATD)
3. The EA Guidelines Document (EAGD)
4. The Fit-Gap Analysis Spreadsheet template
5. Previous editions of this EATSP
6. Various other sources of information, such as those for running projects and programs, business trends, technology trends, etc.
1.3 Audience
The following personnel in organisations and their business and IT partners should use this document:
· MDs, CEOs, CIOs, CTOs, other CxOs
· Chief Enterprise Architects
· Discipline Architects
· Business Analysts
· IT Managers
· Program and Project Managers
· Infrastructure Managers
· Operations Managers
1.4 Associated Documents
Please see section 3 and list the external documents used in creating this EATSP.
1.5 How to Create, Update, and Use this Document
Blue text (other than hyperlinks) throughout is guidance to be deleted before publishing the document.
Use MS Word, Excel, and Visio or Draw.io for the EATSP’s whole and parts. PPTs are deprecated. So is the use of specialised EA modelling tools as they take too much time, add little value, and are hard to circulate to the broad audience of the EATSP. Simple tools will deliver if your architectural thinking is good.
1.5.1 Pre-requisites to Create the EATSP
You must have these in place to create an effective EATSP.
1. A competent Enterprise Architecture Practice with the requisite people, processes and artefacts (Please see this resource: How to Set Up Enterprise Architecture for Your Organisation)
2. An understanding of Domain-Driven Architecture Design (Please see this resource: Domain-Driven Architecture Design for Excellent IT Systems-II-Primer)
1.5.2 What to do
Enable and boost business by taking these steps:
1. Study the plans and needs of the business over one, two, and three years.
2. Look at the current state of IT and identify the required capability changes in the three timeframes.
3. Apply Architectural Thinking to design the target state for those time frames.
4. Create a transition plan in the form of IT transformation projects that are cohesive (similar things are done together), loosely coupled (inter-dependencies are minimised), and right-sized (not too large or small).
5. Create business cases for each project so they can be prioritised and approved or set aside.
1.5.3 When to do it
This analysis and planning will take two to three months for a large enterprise with a sufficiently mature EA practice.
1. Start at the beginning of the last quarter of every year (calendar or financial, whichever is suitable) to create the strategic plan.
2. Present the plan programs with their business cases at least three weeks before year end to the stakeholders.
3. Have a list of approved programs for implementation by the new year, especially those slated for the upcoming year.
1.5.4 Who should do it
The team that does the above should comprise the following.
1. Chief Enterprise Architect (leader and coordinator)
2. Associate EAs
3. CIO and CTO
4. CxOs
5. IT Delivery Program Head
1.5.5 How to do it (Read This)
Architecture and technology are meant to serve the business. So, we must start from the top, i.e., the business, to provide it with the most fitting and efficient IT solutions. Domain-Driven Architecture Design (DDAD) follows this approach and is the recommended method for designing the EA Strategy. Three of its foundational conceptual constructs are:
1. Business Domains (and Sub-domains) in a Business Domains Model
2. A Ubiquitous Language (UL) across business, architecture, and technology
3. Use Cases (UCs) as the basic units of business requirements
(Please see the following articles to understand this approach in depth: Domain-Driven Architecture Design for Excellent IT Systems-I-Introduction and Domain-Driven Architecture Design for Excellent IT Systems-II-Primer)
Applying DDAD at the EA level, the steps for creating the EA Strategy and plan are as follows.
Step #1. Capture Business Model (changes) and Use Cases
a. Capture the Business Domains Model (BDM) — Assemble the cross-functional team defined above. Then, for every business domain, work with the business experts to draw and name the core domain, sub-domains, and supporting domains using Ubiquitous Language. If this has already been done, capture the required changes for the new business capabilities. It is the enterprise’s required Business Domains Model (BDM) (change).
b. Convert or map it to the Business Architecture Model (changes) — Map the business domains and sub-domains to three critical enterprise life-cycle layers: Design, Build, Run, and Manage. It is the enterprise’s required Business Architecture Model (BAM) (change).
c. Identify New and Problem Use Cases — Capture the functional needs and qualities for every core, sub and supporting domain. These should be expressed as use cases. Ideally, end users should provide their needs and wants directly, but if that’s impractical, then business experts or analysts should faithfully represent them. If there is existing material, use it, but ensure it’s in the DDD format.
In the BAM, get the business experts to identify opportunities and issues. Mark these as hot spots using UL nouns, attribute nouns, verbs and quantified adjectives (qualities). E.g., ‘New Use Case: When the retail customer searches for a spare part, there should be a drop-down in the eCommerce Portal that allows entering the product image, and the possible spares should be found using image recognition and presented within 5 seconds at most. E.g.’ Problem Use Case: Capacity is insufficient in South-East Asia for video streaming, causing customer churn out to competitors. We must be able to service 250,000 simultaneous sessions in the region.’
Capture the outcomes in Chapter 2.
Step #2. Perform Fit-Gap Analysis to define the Target EA
It is the heart of the Enterprise Architecture practice. The EA performs the following four steps with the help of discipline architects and technology experts.
#2.1 Map the hot spot use cases to the Current IT Systems using the Enterprise Architecture & Technology Document (EATD). See Activity 4 below for more on this baseline artefact. You can get the EATD template from here →Store.
#2.2 Identify the functional and quality gaps in the current architecture and technology (software, hardware, integrations, operations, etc).
#2.3 Make architecture and technology decisions to close the gaps. It is the most critical step of the process. Every architecture and technology decision (AD and TD) should have a clear problem statement, solution options comparison, and a rational decision. A record must be kept of each AD and TD. (This article elaborates on this core skill: The 3 Most Powerful Architecture Decisions.)
#2.4 Capture the target-state architecture and technology for each business domain and sub-domain affected by the use cases.
You can get the fit-gap analysis template from here →Store.
(Please see this article for details of this step in the case of problematic use cases: How To Do EA Fit Gap Analysis To Fix Problematic IT Systems. The analysis steps are broadly the same for new use cases.)
Capture the outcomes in Chapter 3.
Step #3. Define Projects and Business Cases
Gather information on the enterprise’s funds, time, and other constraints. Then, define projects to make the required software, hardware, integration, and operations changes. The projects should be cohesive, loosely coupled and right-sized. Define the project sequences and inter-dependencies.
Work out the quantified monetary benefit and cost for each project and how quickly the cost will be recovered. If it is too long, go back to the decisions of Step 3 and change the architecture and technology to cheaper options until an acceptable payback period is achieved.
Capture the outcomes in Chapter 4.
Step #4. Get Approvals and make the Final Strategic Plan
Present the planned transformation projects with their business cases to the stakeholders. The business owners and finance managers will approve and prioritise the projects. It becomes the final EA Strategy and plan.
The picture below represents the above steps.
Capture the outcomes in Chapter 5.
(Beyond this, each solution project will further detail the IT Architecture and solution, which will be examined in the design stage of the Delivery Life Cycle by the Solution Review Board (see Activity 3 below) for its soundness before it is built or bought. These steps are elaborated on in the article Domain-Driven Architecture Design for Excellent IT Systems-II-Primer.)
1.6 Critical Success Factors & Dependencies
Creating an effective EATSP depends on the maturity of the EA practice and its artefacts. It also requires the involvement and cooperation of all essential information providers from business and IT.
The necessity and vitality of the EATSP need to be supported in the top-down delivery of the EA practice, allied with adroit management by the EA team.
2 Business Capabilities Plan
Business needs must drive the Information Technology of the enterprise. Gather information about the plans and needs of business in one, two, and three years and capture them here in a technology-agnostic manner.
2.1 Enterprise Capability Strategy
As the Enterprise Architect, gather information from the business plan documents or by interviewing business owners and summarise the changes they are planning in the following three sections.
The tables below have some example entries.
2.1.1 Revenue/Market Share Strategy
The drivers here can be:
1. Business Growth
2. Revenue Market Share (RMS) Growth
3. RMS maintenance
· Marketing and Sales Strategy
· Product Strategy
2.1.2 Profitability Plan
· Pricing Strategy
· Costing Strategy
2.1.3 Regulatory & Risk-Related Strategy
2.1.4 Business Domains Model (Changes)
Based on the changes captured in section 2.1, draw the pictorial models of the business domains and mark the ones with critical changes, year by year.
Please see the example image below of BDMs, with changes highlighted. Replace them with your own and delete this note.
· Year 1
Similar for each new or changed domain.
· Year 2
Similar
· Year 3
Similar
2.1.5 Business Architecture Model (Changes)
Please see the example image below of a BAM with hot spots highlighted. Replace it with your own and delete this note.
· Year 1
· Year 2
Similar
· Year 3
Similar
2.2 Domain-wise Use Cases
Next, for each business domain, gather use cases from the business plans (or by interviewing the business owners) for the new or modified business functionality or capacity/performance/availability/etc. We don’t know which business use case may have an IT impact (but increasingly, more and more of them will). So, put down all the business use cases here, agnostic of technology. Many, but not necessarily all, will have an IT impact, which is the separate discovery exercise that will be done in Chapter 3.
(In a large enterprise, you may have about 4 business plans x 8 domains x 3 sub-domains x 5 use cases = 480 use cases for each plan year. With the right team (and prioritisation, if required), it can be captured and used effectively for business and IT planning.)
2.3 Domain — Marketing
A few examples are entered in the use case table below. Study these carefully to understand the way and fill in the rest here and for the following business domains.
Year 1
Year 2
Similar
Year 3
Similar
2.4 Domain — Sales and Service
From the business plan and interviews with business owners, capture the changes the business requires in the coming Years 1, 2 and 3 in the standardised format of Use Cases (see more about this in the resources listed in Appendix B).
The tables below follow the example of the plan to launch a new electric vehicle line. One example is given for each domain. Replace them with all the use cases required for all the domains for your business plans.
Year 1
Year 2
Similar
Year 3
Similar
2.5 Domain — Finance
Year 1
Year 2
Similar
Year 3
Similar
2.6 Domain — Human Resources
Year 1
Year 2
Similar
Year 3
Similar
2.7 Domain — Information Technology
Year 1
Year 2
Similar
Year 3
Similar
2.8 Domain — Operations
Year 1
Year 2
Similar
Year 3
Similar
2.9 Domain — Risk & Regulatory
Year 1
Year 2
Similar
Year 3
Similar
2.10 Domain — R&D (aka Product Development)
Year 1
Year 2
Similar
Year 3
Similar
3 IT Fit-Gap Analysis
Architecture and Technology must not be ideological or done for their own sake.
3.1 Overall Fit-Gap Analysis
Having understood business needs over one, two, and three years, do the following for each business domain or sub-domain.
1. Identify the business use case functional and non-functional changes required in the 1-, 2-, and 3-year time frames.
2. Consider the existing architecture and technology supporting each use case.
3. Identify the critical architecture and technology problems.
4. Make architectural decisions for them.
5. Capture the resulting end state for the domains in the corresponding time frames.
6. Elaborate on the architecture and technology changes in the sections below, one for each domain/sub-domain. A couple of examples are provided.
The picture below shows the fit-gap analysis sheet with a couple of examples filled in. You can get the template from here: Store.
3.2 Domain — Marketing
Change Use Cases and Architecture and Technology changes required.
Year 1
Year 2
Similar
Year 3
Similar
3.3 Domain — Sales and Service
Change Use Cases and Architecture and Technology changes required.
Year 1
Year 2
Similar
Year 3
Similar
3.4 Domain — Finance
Similar
3.5 Domain — Human Resources
Similar
3.6 Domain — Information Technology
Similar
3.7 Domain — Operations
Similar
3.8 Domain — Risk & Regulatory
Similar
3.9 Domain — R&D (aka Product & Service Development)
Similar
4 IT Programs and Projects Proposed
4.1 Projects Formulation
After you identify all the architecture technology changes, club the related ones together into cohesive projects that are neither too small nor too large and don’t have major dependencies on each other.
4.2 Business Cases Working Out
Capture the costs of any software, hardware, and effort involved in the architecture and technology changes. This will give you the estimated capital expenses and running costs of the solution. Compare it with the profit that will accrue per month due to the solution. This will tell you how long it will take to recover the spending, i.e., the Return on Investment period.
4.3 Summary Table
From the projects defined further in this chapter, make this summary table for easy comprehension and discussion.
A few examples are provided. Please understand the method and replace them with your project information.
4.4 Year 1
4.4.1 Project 1 — Electric Vehicle Line IT
4.4.2 Project 2 — Open-Source DB Project
4.4.3 Project 3 — Marketing System Cloud Migration
4.4.4 Project 4 — Smart Car and Smart City Integrated Service
4.5 Year 2
Similar
4.6 Year 3
Similar
5 Final IT Plan
5.1 Projects’ Prioritisation, Limiting, and Approval
There will always be constraints of money, time, and technology. These will restrict the number of projects and their scope.
The EA and business owners will submit the recommended projects to the company’s CxOs and Directors, who will decide which ones can go ahead, whether they should be cut down, and the order in which they should be delivered.
From the above outcomes, list the approved IT Programs and Projects in summary and details in the sections below. The detailed project documents can be referenced here or created subsequently.
5.2 Overview Table & Mapping Diagram
Summarise the approved projects defined further in this chapter in this table for easy comprehension and discussion.
A few examples are provided. Please understand the method and replace them with your project information.
The example picture below shows the main business architecture parts that each project will most support. It helps with understanding and discussion. Draw a similar picture for your projects, and BAM.
5.3 Year 1
5.3.1 Project 1 — Electric Vehicle IT
5.3.2 Project 2 — Open-Source DB Project
5.3.3 Project 3— Marketing System Cloud Migration
1.1 Year 2
Similar
1.2 Year 3
Similar
Appendix A. Business and Technology Trends
Business Trends
Capture the current global and local trends relevant to your business. Knowing these will help you proactively shape the IT architecture and technologies and serve the business better.
A couple of examples are below.
Trend 1
Vehicle sales are shifting online.
Citation 1: https://www.imarcgroup.com/online-car-buying-market
Citation 2: https://explodingtopics.com/blog/auto-industry-trends
Trend 2
Electric Vehicle sales are increasing exponentially.
Citation 1: https://www.virta.global/en/global-electric-vehicle-market
Citation 2: https://evchargingsummit.com/blog/ev-trends/
IT Trends
Capture the current global and local trends relevant to your IT systems. Knowing these will help you proactively shape the IT architecture and technologies and serve the business better.
A couple of examples are below.
Trend 1
Public cloud is being avoided or repatriated to private data centre cloud.
Citation 2: https://datacentremagazine.com/articles/the-factors-driving-the-cloud-repatriation-trend
Trend 2
There’s a rapid increase in the adoption of modern code-deployment pipelines and automated code generation, testing, refactoring, and translation.
Citation 1: https://www.forrester.com/blogs/the-next-generation-of-modern-software-development-is-here/
Citation 2: https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/the-top-trends-in-tech#tech-trends-2023
Appendix B. Enterprise Architecture Resources
IT Architecture and Enterprise Architecture (one of its disciplines) are vast subjects. I have created resources for their methods and artefacts that you can explore and learn from my website below. You will find articles, books, templates, litmus tests, curated websites and references, and lots more that you can use for your architecture delivery.
You can also engage me from there for EA training or EA strategy & planning.
Document Page Images
