“Enterprise Architecture is a hot topic amongst CIOs in 2024, with 49% of respondents from Gartner’s annual CIO Survey stating this as a key investment area, second only to AI.” – Gartner
What is Enterprise Architecture Modeling?
Architects are in high demand, because they are uniquely able to provide an “end-to-end” view of the business, from strategic operation models, projects and programs, through to the processes and technology stack which underpins these many systems.
They do this by building out enterprise architecture models. Many other professionals also use modeling; for instance:
- Financial modeling brings together data to provide clarity around revenues, expenses, cash flows, and profitability. These help businesses make informed decisions about investments, budgeting, and strategy.
- Risk modeling assesses the potential impact of market volatility, regulatory changes, or operational disruptions.
- Supply chain modeling focusses on managing and improving inventory, transportation logistics and production scheduling.
Architects use models to think logically about how best to support teams as they manage and improve the business and technology.
Architecture modeling considers people, processes and technology. So, models are often underpinned by technology and infrastructure, linked through to applications, then the business capabilities and functions they support as well as the company organization chart. Architecture models are increasingly incorporating financial and risk analysis, providing a more holistic view of the impact a proposed solution will have on the organization.
A well accepted way to develop an enterprise architecture model is to use enterprise architecture domains. This means integrating Business Architecture Models, Application Architecture Models, Information Architecture Models, Data Architecture Models, Security Architecture Models.
This structure – often called a “metamodel” defines how to capture information across multiple different domains. It might also cover how to build out business processes, and design technical deployment views using AWS or Azure libraries.
All of these views of the business can hang together in a single enterprise architecture model.
The guide below covers the key elements in explaining the value of enterprise architecture modeling.
- Types of Enterprise Architecture Models
- Connecting Enterprise Architecture Models
- Top Tools for Architecture Modeling
- Enterprise Architecture Modeling: Current State and Future State
- Presenting Enterprise Architecture Models, Diagrams and Deliverables
- Choosing an Enterprise Architecture Modeling Framework
- Governance of Enterprise Architecture Models
- Advantages of Enterprise Architecture Modeling
Types of enterprise architecture models
Let’s take a look at how a range of architecture professionals might work together to provide a properly connected and integrated “super-model” which captures the key aspects of the enterprise architecture, whilst still being manageable for each professional.
Business Capability Models and Value Streams
Chief Architect Alex has been asked to evaluate a core business capability at a large global multinational.
Looking at the Customer Acquisition Strategy capability, Alex realizes that despite this capability having a high impact on business outcomes, the onboarding process is overly complex and slow, and needs to be improved.
Business Process Models
Alex asked a business process analyst to document the existing onboarding process. To do this, the analyst chooses to use the standard BPMN notation.
The analyst sets out the departments or individuals involved in the onboarding process: sales, marketing, customer service, and IT. They create swim lanes in the BPMN diagram to represent each’s roles and responsibilities.
- The analyst maps out the major steps involved in onboarding a customer: account creation, product information delivery, and training.
- They arrange these activities in the order they will be performed, using standard symbols to represent each activity.
- They connect activities with sequence flow arrows to show the process flow and use gateways (diamond shapes) to represent decision points, with different paths depending on the customer’s choices or other factors.
- The analyst checks that events (circles) represent the start and end of the process or any significant events within it, such as receiving customer information or completing a step.
- The analyst adds properties for the time it takes to complete each activity and whether the tasks are manual or automated.
- Finally, the analyst heatmaps the process to identify any bottlenecks to make it easier for others to read.
The model is then ready to share with Alex and other colleagues for review and feedback.
Application Architecture Modeling
One of these colleagues, an Application Manager, can build on the components in the process model to show how applications are used at each stage of the process. The Application Manager edits the diagram to add connections to the applications used in the onboarding process, such as the CRM (Customer Relationship Management) system, e-commerce platform, and document management system. The application architect also maps the data flows between the process and the applications involved. This adds details of the data exchanged and the systems responsible for storing and managing it to the model.
Technology & Cloud Architect Modeling
The Technology or Cloud Architect then assesses what infrastructure components support the applications used in the process.
Cloud architecture modeling involves mapping out the structure and relationships between components such as virtual machines, containers, storage systems, and networking configurations.
Architects consider scalability, reliability, security, and cost trade-offs within cloud environments. By creating and analyzing these architectural models, organizations can make informed decisions about their cloud infrastructure design, deployment strategies, and ongoing management.
Solution Architecture Modeling
Solution Architects translate business requirements into technical solutions. For example, the Solution Architect in Alex’s team might prepare a design for a new customer acquisition strategy and onboarding process, with applications and technology reworked to improve processes, simplify the application stack and ensure quicker and more secure data flows. They will understand the business context and gather stakeholder input. Once the solution requirements are defined, the architect develops a model of the solution, outlining desired functionalities and performance expectations. This also includes system components, data flows, interactions, and deployment strategies. The solution architecture model supports clear communication throughout the development and implementation of this new solution.
Software Architecture Modeling
If the solution involves designing a new application or software, this may involve software architects and developers, who design the software application, including its components, modules, interfaces, and relationships. Software architecture models can take various forms, such as UML diagrams, entity-relationship diagrams, or basic flowcharts. Another approach is using the C4 model as a lightweight method to visualize software architecture. This enables clearer communication by creating maps of the software at various levels of detail.
Connecting Enterprise Architecture Models
As we’ve seen, architects and modelers create views of different domains, including business, process, applications, infrastructure, and technology views. Each of these elements needs to be connected-up and down the model so architects can identify dependencies and map out scenarios.
Capabilities are made up of Processes, Processes require applications, applications are hosted on servers, and different architects want to drill down through different levels.
Ultimately Alex and other architects can cascade understanding and analysis across their models and use this information to communicate about both current states, future states and impacts of change.
Enterprise Architecture Modeling Tools
Benefits of Architecture Modeling Tools
The benefit of an architecture modeling tool is that architects can not only create these models and designs from scratch, but also link elements easily across domains. They can re-use and connect existing component types and connection types already available in the model. This builds consistency and efficiency into the modeling process.
For instance, an architect can find and select an existing ERP system and add it in to a model they are building. All the ERP systems’ incoming and outgoing connections across the model will then remain linked. The ERP system is a single object that is present in many different diagrams and views in the model, including solution diagrams. So, updating the name, properties or connections of the ERP system will automatically update across all of the other views.
In designing a solution the architect can connect an application to a new server, or to an existing server. This data might be coming from external sources as well, pulled in from ServiceNow or via an API in the enterprise architecture tool.
This connected architecture model offers some huge advantages. When a business considers retiring an application, the architect can use the tool to quickly identify other parts of the architecture that rely on the soon-to-be-retired application. This includes any processes, systems, or data flows that interact with the application. Architects can use this information to plan for data migration to alternative solutions, implement workarounds to ensure continuity in dependent processes, and communicate about potential disruptions to colleagues.
Traditional diagramming tools like Visio lack automatic updates. This means architects must manually find and update related elements across different diagrams whenever a change is made. This is time-consuming, very difficult to maintain and prone to errors. Enterprise architecture tools solve this issue
Enterprise Architecture Drawing & Diagramming Tools
When architects talk about “modeling tools” what they often mean is they want a drawing and diagramming tool which can be used to design architectures with context and consistency. A diagramming canvas where pre-built elements can be dragged from a stencil and dropped on to the workspace as part of the design process is particularly important for the work of solution architects and cloud architects.
Cloud architecture modeling with AWS icons in ABACUS
It’s worth noting that not all enterprise architecture tools provide this style of freeform drawing functionality. Some tools offer only automatic drawing, where a table view is rendered in a diagram. This can be frustrating for architects who want to adjust or reposition elements, and change attributes such as size, color, text labels etc. to make sure they accurately represent the existing or planned architecture.
Some toolsets also “outsource” this drawing functionality to a diagramming tool, but the limitations of this is that the elements and components of the diagram aren’t properly integrated with the enterprise architecture repository, and updates don’t flow through automatically.
Enterprise Architecture Modeling: Current and Future State
The next phase in implementing the solution is for Alex to build a roadmap to move from the current state architecture to the chosen future state.
Alex considers alternative “what-if” scenarios to make sure the team chooses the best future state solution based on factors like speed and cost. The team can also analyze the model to provide insights on cost, complexity, reliability of systems, customer satisfaction scores across processes and value streams. Analyzing these metrics is a key part of designing a strong solution. To do this architects and analysts can use algorithms and simulations.
Solution architects often want to use specific notations such as cloud architecture notations. There are also other aspects to be considered around process optimization. So, as architects are designing specific processes or solutions, they might be starting from a relatively technical view, looking at applications and infrastructure, building specific solutions for those. And then they can move into the actual process level. At this stage, the team can look at what steps are executed as part of a process, such as “Request for information access process”. They need to both provide a view of what today looks like, and also model out the proposed future state.
For example, the current process uses legacy platforms, with relatively classical integrations happening behind the scenes. Alex’s team needs to assess a move to a more modern SaaS platform where they can have API calls. Often, a good way to do this is to model multiple future states and run a trade-off analysis to determine the best solution. For example, Solution A may bring us closer to reducing costs but will increase the pain points in a particular process, while Solution B significantly increases our customer satisfaction scores and reduces the number of manual tasks in a process but incurs a higher cost as a trade-off.
Presenting Enterprise Architecture Models, Diagrams and Deliverables
There are two ways we often see architecture teams sharing information with technical and business teams.
Firstly, they can build live, interactive views. For instance, a live web-based dashboarding environment, which can be used to bring together relevant portfolios, diagrams, charts and analysis, which teams can interact with as they require.
The alternative, which teams do often still want to produce, are more formal static views – PDFs or PowerPoint documents, providing snapshots of the architecture or repository. These often have more specific purposes, such as reports which provide a final, documented state of the architecture for approval purposes.
Choosing an Enterprise Architecture Modeling Framework
Guided by the organization’s business requirements, frameworks can provide structures and standards which help architects to align the business and IT strategy and accelerate their work.
Frameworks provide a set of assets and templates which allow architects to get started quickly. They help to set best-practice and standards for governance, and a common language for collaboration and communication between architects.
Frameworks like TOGAF (a comprehensive, standardized approach to enterprise architecture) and CMMI (a process improvement framework) are also often used to guide the implementation and maintenance of IT and business architectures.
Choosing the right framework depends on the specific needs and goals of the project and the organization’s existing practices. Often, the most effective approach involves combining elements from multiple frameworks to tailor a solution that best suits your specific context.
Notations can also be used in a range of ways. They define standard approaches to representing system elements and interactions: UML (Unified Modeling Language) for visualizing software systems, BPMN for business processes, ArchiMate for architecture, and the C4 model for software architecture. Specific notations and icons are also used for modeling cloud-based systems, including AWS, Azure and GCP icons.
Governance of Enterprise Architecture Models
Governance and standardization are key drivers for using an enterprise architecture tool, as they allow organizations to ensure consistency and data accuracy by setting up rules within the model.
Drawing tools which don’t have an integrated architecture repository often lead to poor data quality due to lack of standardization. Enterprise architecture tools offer centralized management of user roles, enabling control over who can view and modify content. With an in-built permission system, access to architecture data and diagrams can be tailored based on user roles, locations, departments, and responsibilities.
For instance, read-only users can view and interact with defined sets of information, while editor users can be set up to modify designated datasets, and modeler users can design or edit diagrams. Administrators have full access and can manage permissions for other users.
Standardization is crucial for CIOs in large enterprises who need to ensure efficient management and governance of the enterprise architecture.
Advantages of Enterprise Architecture Modeling
Enterprise architecture modeling isn’t just about creating diagrams, although diagrams are often a useful step in modeling out systems and processes. It can bring together a wide range of business and IT context needed to guide decision making and focus resources effectively.