Enterprise Architecture Techniques
I was involved in a company acquisition as an integration architect and a merger of two large telecoms as an enterprise architect. They were among the most exciting and challenging IT architecture engagements of my career. The former ran for a year and the latter for two years.
Every M&A is different, but there are common themes in approaching the design of the merger, and formulating a method is worthwhile.
I condensed my massive learnings into this primer to help you if you are engaged in an M&A IT consolidation project. It became the 10-step method below. The phrase “as applicable” is present silently in all sections.
A note on documentation
Documentation is essential for a practical design and efficient merger. Capture the details in every step and sub-step below. If you belong to a large IT services company, your architecture practice will be mature, and you will have templates for the required artefacts. If not, use the guidance from The Open Group at the link below to create your own. In each step, I’ve indicated the critical information required.
Open Group Architectural Artifacts
#1 Step — Understand the business aims of the merger
Businesses merge for various reasons. While we cannot study this extensively here, it is critical for the Enterprise Architect to know the merger’s or acquisition’s aims as it informs the requirements and shapes the solution.
Here are some common reasons for mergers and acquisitions, with implications for the EA in brief.
For economies of scale
Understand the expected reduction in technology, operation and investment costs. It will guide the EA policies, guidelines, and solution constraints.
For diversification of services
Understand the portfolio required after the M&A for the necessary business functions and to remove redundant ones.
For capability enhancement
Understand the capability that’s being added and how the merged company will use it. Integrate it with the systems of the business domains it influences.
For R&D competency
Understand the changes required for using the R&D technology and team and applying research outcomes for the merged company.
For financial advantages
M&A for financial reasons related to enabling larger loans, tax savings, and higher revenue profile advantages. Irrespective of the reason, it could still involve the physical merger of the IT systems of the two companies and require all the following steps. Understand how the M&A’s financial benefits support the quality of the end-state solution.
Note: Across all the types above, understand if any new business services need to be created or old ones to be dropped, with the reasons.
#2 Step — Lay down IT principles, policies, and guidelines
The combination of business aims, architecture best practices and technology trends provide the principles (must be followed), policies (should be followed), and guidelines (may be followed). Here are some examples in each area.
Architecture
Principles — The TMForum Open Digital Architecture will be used as the reference architecture for the end state.
Policies — No new system or commercial product will be used unless existing systems are at the end of their life.
Guidelines — Look for opportunities to simplify the end-state architecture, especially for information and integration architecture.
Technology
Principles — Commodity hardware must be given preference.
Policies — Open source software shall be preferred. Systems supporting standard APIs and protocols shall be chosen.
Guidelines — All systems should be upgraded to the latest or next-to-latest version.
Partners/Vendors
Principles — A cohesive set of systems shall be selected from each large vendor/partner.
Policies — The billing system shall be X from vendor Y.
Guidelines — Keep the overall number of IT partners to less than ten.
#3 Step — Study the existing landscape
Use existing information in the two company’s asset management systems, Configuration Management DB (CMDB), and documents such as Business Process Document (BPD), Use Case Document (UCD), Business Requirement Specifications (BRS), Architecture Overview (AO), High-Level Design (HLD), Low-Level Design (LLD), Operations & Management (O&M), and Standard Operating Procedures (SOPs).
If you are lucky, both companies will have mature IT organisations with the above information. If not, gather the essential information in custom artefacts (usually diagrams and spreadsheets) by interviewing the proper personnel.
This step will take a while, but it is indispensable for a controlled merger that meets the enterprise’s time, cost and capability expectations. Collect technical and cost information for the selection steps #4 and #5 below.
A. Technical Information
Collect the following information and more for both companies:
- Business processes and sub-processes list by domain for planning, delivery and operation layers.
- Business use cases (aka user journeys or business services) list with actors, locations, description, load, response time, and error handling.
- Business use case (or service) to application mapping.
- Application list with infrastructure details such as the OS, number of instances, per instance virtual cores, RAM, storage, IOPS, network bandwidth, supplier, and API list.
- Public cloud service list, with type, sizing, configuration, access information, and provider.
- Interface list with the upstream system, downstream system, API calls, protocol, sync/async, average and peak TPS, response time, and errors list.
- Physical servers list with the count, make, model, year of manufacture, year of purchase, supplier, firmware version, DC/cloud locations, capacity, load, end-of-support, and end-of-life dates.
- Software list for applications, middleware, operations tools and business tools with details such as make, name, version, latest version, licence count, location, user types and locations.
- Network equipment list and connectivity diagrams numbers, make, model, version, supplier, capacity, load, and performance.
- Storage systems list with details on the make, model, version, raw capacity, usable capacity, connected applications, allocation, compression, encryption, HA design, and network details.
- Datacentre details such as locations, floor space, rack and row diagrams, hardware locations
- Cover development and test environments in items 3–10
- Operations dashboards and processes
- Operations management organisation with roles and responsibilities
- Service Level Objectives and Agreements (SLOs and SLAs)
- Business dashboards, processes
- Business continuity and disaster recovery solution and process details
- List of issues and root causes for business services
- List of in-flight and planned projects with the solution and delivery plan details
B. Cost information
For each item in items 3–11 above:
- Annual subscription or licence cost
- Annual maintenance cost
- Annual operations cost (e.g., power cost, personnel cost)
- Residual value
#4 Step — Select the best applications/systems
Applications and systems provide logically discrete and cohesive sets of business functions. Examples are the company’s Web Portal, Mobile App, CRM system, Billing system, Payment system, etc.
They are commercial off-the-shelf products (COTS) or custom (aka bespoke) systems built by application development and management (ADM) vendors/partners.
(Sometimes, the term software is used interchangeably with the term application. Although deprecated in this context, it is acceptable when referenced as a functionally discrete business application.)
Cover three situations of system/application selection.
- When the application exists in only one company — adopt and scale it up to meet the merged use cases and business load.
- When the same application exists in both companies and the COTS product and version are about the same — retain the larger one.
- When the same application exists in both companies, but they are different COTS products or custom applications — use the following parameters to choose the one to retain. Score them in a spreadsheet and select the higher-scoring application.
COTS/Custom — 20% (typically COTS preferred)
Ranking against peers — 10%
Feature richness — 10%
Operations mgt maturity — 10%
Future Roadmap — 10%
Issues History — 5%
Inbuilt HA and resilience — 10%
Support organisation strength — 5%
Cost — 20%
Also, check if there are legacy systems that you have to retain. What are the reasons, implications, and post-merger transformation plan?
Describe the selection in a High-Level Design (HLD).
#5 Step — Select the best Data Centre/Cloud and Middleware Platforms
DC and Cloud Selection
Study the data centre (DC) and cloud-related technical and cost information in Step #3 above. Consider the total DC or cloud infrastructure requirement and answer these questions:
- Which DCs and Clouds are more modern? Which are most cost-effective?
- Where are most users and partner systems located? How does the choice of DC/cloud affect the network cost, user experience, and integration architecture complexity?
- Should we keep all the data centres/clouds and expand and redistribute the selected applications on them?
- Or should we keep only one large primary DC/cloud and a DR DC/cloud?
- Should any DC infrastructure or services move to public cloud versions?
- Should any public cloud infrastructure or services move to private DC versions?
- Are there legacy systems that you have to retain? What are the reasons, implications, and post-merger transformation plan?
Answer the above and allied questions for the preliminary selection of the data centres and public clouds for the merged company’s IT systems.
Middleware selection
Middleware comprises the HTTP servers, Web application servers, hypervisors, cloud management suites, automation systems, orchestration systems, operations management systems, container platforms, service meshes, and EAI systems for queueing, brokering, business process management, workflow management, and API gateways. In some cases, databases are also considered middleware, although it is often taken as a part of applications.
Cover three situations for the middleware selection:
- When the middleware exists in only one company — adopt and scale it up to meet the merged business load.
- When the same middleware exists in both companies and the COTS product and version are about the same — retain the larger system.
- When the same middleware exists in both companies, but they are different COTS products or custom applications — use the following parameters to choose the one to retain. Score them in a spreadsheet and select the higher-scoring middleware.
Issues History — 20%
Operations mgt maturity — 10%
Ranking against peers — 10%
Feature richness — 10%
Future Roadmap — 10%
Inbuilt HA and resilience — 10%
Support organisation strength — 10%
Cost — 20%
Describe the selection in a High-Level Design (HLD).
#6 Step — Define the end state architecture
Create the architecture and high-level design for the merged end state.
(In a merger, there will be less low-level design, coding, unit testing and system testing than for a new IT system, but there will be more focus on the functional architecture, technology architecture, integration testing, performance testing and operations design. Create low-level designs and test cases during project delivery.)
Deliver the main architecture models A-J below by reusing and extending existing architecture artefacts or creating new ones.
A. Business service solution architecture
- For the business use cases, create sequence diagrams through the underlying IT systems/applications.
- Identify functional gaps that need enhancements to existing systems/applications or a new system/application.
- Define the required APIs and microservices and map them to existing ones.
- Deliver the High-Level Design (HLD)
B. Information architecture
This is a critical part of the design phase. Carry out the following steps.
- For the business use cases, identify the information required and its sources.
- Refactor the information architecture if the data is not sufficiently cohesive and decoupled between the selected systems/applications. Apply a litmus test to decide when to source data from the original system and when to copy it to another system for local access.
- Define which data from unselected systems you need to retain and to which system/application you will transfer them.
- Define any changes required to the information in Systems of Engagement (SoEs)
- Define any changes required to the information in Systems of Record (SoRs). Examples are Operational Data Sources (ODSs), Reporting Data Marts (RDMs), Management Information Systems (MISs), and Log Repositories.
- Define any changes required to the information in Systems of Analytics (SoAs). Examples are Big Data repositories and Business Intelligence systems.
- Define the changes in purging, backup, and archiving requirements.
- Deliver the High-Level Design (HLD)
C. Applications architecture
For COTS products
- Define the end state specification, configuration, interfaces, and data changes to meet the functional and non-functional requirements.
- Perform version upgrades if necessary
- Define the deployment model
For custom applications
- Define the functional component model. Create sequence diagrams through the components for the Use Case sections transiting through the application.
- Define each component’s responsibilities and interfaces.
- Define any architecture changes required for changes in functionality or non-functional requirements such as capacity, performance, availability, scalability, security, and operability.
- Define the deployment model
For new COTS products or custom applications
- Deliver the requirements gathering and architecture definition phases of the software delivery life cycle (SDLC). (Leave the detailed design to the delivery project.)
- Define the functional model
- Define the deployment model
D. Integration architecture
Design for three types of information architecture.
- UI integration — Consider which user interfaces of the selected applications need to be integrated into web portals and mobile applications.
- Information integration — From the information architecture in Step 2, design the data synchronisation and copying architecture.
- Functional integration — From the use case to application sequence diagrams of Step 1, design the integration of systems and applications.
- For each integration, apply a litmus test to decide if it will be direct integration or through an EAI system.
Deliver the High-Level Design (HLD).
E. Middleware architecture
The requirements of the hosted systems and applications decide the architecture of the middleware selected in Step #5.
(Remember that the middleware comprises the HTTP servers, Web application servers, hypervisors, cloud management suites, automation systems, orchestration systems, operations management systems, container platforms, service meshes, and EAI systems for queueing, brokering, business process management, workflow management, and API gateways. In some cases, databases are also considered middleware, although it is more often taken as a part of applications.)
Application-dedicated middleware is relatively easy for architecture design. Shared and centralised middleware needs careful consideration. Ask yourself these questions.
- Which middleware is shared or centralised, and how much will its load increase?
- Which shared or centralised middleware needs to move to a new location?
- How will you ensure the middleware’s capacity, response, availability, resilience, scalability and operability?
- How will you balance the load across middleware clusters?
Deliver the High-Level Design (HLD) covering all middleware, with software information, counts, sizes, locations, and application mapping.
F. Compute, storage, and network design
The needs of the applications, middleware and operations tools will drive the design of the compute, storage and network required for their functions, capacity, performance, availability and other non-functional requirements.
With the information captured in step #3 (current details) and step #5 (DC and cloud end-state) above, ask yourself the following questions.
- How will you size the compute, storage read/write speeds and network bandwidth for the software deployment units of the systems/applications? Are there sizing methods you can use, or do you need to extrapolate the sizing?
- What will be the server, storage and network layout required to achieve the required capacity, performance, availability, resilience, scalability, and operability?
- What systems will be on bare-metal operating systems, virtual servers and docker? What networks do you need between data centres and clouds?
- What infrastructure is required to support the operations requirements of step H below? Which tools do you need for monitoring, alerting, logging, backup, restoring, automation, and security?
- What will be the design and process for disaster recovery? How will the required Recovery Point Objective (RPO) and Recovery Time Objective (RTO) be achieved?
With answers for the above, deliver the High-Level Design.
G. Security architecture
Compare the security architecture and implementation of the two companies. Carry out the following steps with a security architect or expert.
- What will be reference security architectures for data centre and public cloud users, services, data, and systems/applications?
- Are there any architectural gaps, and how will you close them?
- How will you cover the following four security areas— Identity and Access Management, Infrastructure and Network, Data and Application, and Customer Access?
- How will you cover the following three security aspects — Secure and Protect, Detect and Defend, Investigate and Respond?
- How will you test the end-state security architecture for static and dynamic security?
With answers for the above, deliver the High-Level Design.
H. Operations architecture
Once the end state merged solution is built, operating it well is crucial for delivering the business services. Adopt the more mature operations framework and processes between the two companies or the best elements from both. Extend and improve them as necessary.
Cover these aspects in the operations architecture.
- Service Level Objectives and Agreements (SLOs and SLAs)
- A complete and robust asset management system with configuration information (aka CMDB — Configuration Management Database). It should cover all hardware and software in the merged end state and discover new assets.
- Business service monitoring
- Application Performance Monitoring
- Hardware and middleware monitoring
- Event monitoring
- Event and service ticket monitoring
- Automate build, takedown, defect fixing, ticket creation, ticket closure, and reporting to the extent possible.
- Provide descriptive, forensic, predictive, and prescriptive analytics to the extent possible.
- Currency of all hardware and software
- Notifications, alarms, and escalations
- Operations organisation and processes
- Dashboards for items 1–8
Deliver the High-Level Design (HLD).
I. Migration sequence
This is one of the most critical architecture designs. It should be given sufficient time and thought. Involve all the architects — application, integration, information, technology, and business. Consult any required Subject Matter Experts (SMEs).
Here are the key questions to ask yourself.
- What hardware or cloud capacity do you need to migrate from the original to new locations?
- What middleware needs do you need to migrate from the original to new locations?
- Which applications do you need to migrate from the original to new locations?
- Will any users be migrating to new locations, especially staff of the two companies?
- What are the dependencies in the migration?
With answers for the above, deliver the High-Level Design for the migration sequence covering all the elements of the merged ecosystem.
J. Architecture governance design
This can be taken as a part of Step #10 below — ‘Govern’. But the detailed definition of this element is the responsibility of the Enterprise Architect, and an outline is provided here. It is also critical for the design of the end state.
If an IT solution governance framework exists in either organisation or both, use the best elements to:
- Define an Architecture Review Board (ARB) with responsibilities, members, chairs, and the review process.
- Define a Project Design Authority (DA) with responsibilities, members, chairs, and the review process.
- Put the above in motion to oversee items 1–7 above and steps #7 to #9 below.
#7 Step — Define the merger program and projects
As the enterprise architect, guide and shape the following steps:
- Divide the entire solution into projects as cohesive and decoupled as possible
- Prioritise the projects based on business criticality
- Define the dependencies of and between the projects in terms of sequencing, resources, skills, and financing.
- Create individual project plans
- Create the overall program plan
- Identify the risks and possible mitigations for the projects and program
#8 Step — Execute the IT merger
The essential steps in the delivery of the merger are below. Support, guide, and govern as an EA in each stage and update the business on any emerging risks and changes required.
- Establish the governance framework and process (see step #10 below)
- Create the Program or Project Management Office
- Review the architecture solution of every launched project
- Interlock with the stakeholders and take any environmental changes into account that impact the merger solution
- Continuously adjust the architecture during the program’s lifetime
#9 Step — Provide critical care after the merger
You will have monitored the success of each project in meeting its aims. But once the holistic end state has been delivered, watch it closely for three to six months for the following indicators.
- How well every use case of the merged business is performing its function
- New capabilities (if any) are working as expected for the combined business
- Business processes and the merged IT solutions are aligned
- All unwanted systems have been decommissioned and removed completely
- The operations organisation and process are working well
- Recurrent problems and their root causes
- Static and dynamic security is tested repeatedly, covering user and company data at flow and rest, and denial of service.
- Business continuity and disaster recovery are working
- Change management process and governance are working well
- The business aims of the merger as they translate to IT are met
#10 Step — Govern
Merger programs need a governance structure across all domains — business, finance, strategy, solution design, delivery, and operations.
Governance is also required for each step above in the merger process and continues after the merger.
It is beyond the scope of this primer to elaborate on the governance organisation and process. But guidance is available at the link below.
Project Governance and Project Management Office
End note
Mergers often result in large and complex projects. A systematic approach will ensure we deliver the end-state business support systems (BSS) and operations support systems (OSS) in the least amount of time possible, are functionally fit, of high quality, and cost-efficient.
Adopt this primer or encourage its adoption if you are fortunate enough to lead or be a part of an IT merger project as an architect.
I’ll improve this primer, and constructive suggestions are welcome.
