Enterprise Architecture Management
BIC Enterprise Architecture Management is a separate module and license.
What is Enterprise Architecture Management?
Enterprise Architecture Management (EAM) is a strategic approach to the sustainable design, control, and development of a company’s or authority’s IT landscape. A good enterprise architecture considers more than “just” information technology. It provides a holistic view of the strategic, operational, and (information) technological relationships within an organization. Essentially, the following architectural areas are distinguished, which together enable a structured and comprehensive view of an organization:
1. Business Architecture
Business Strategy: Definition of business goals and strategies.
Business Processes: Documentation and optimization of core processes.
Organization: Capture of structure and hierarchy of the organization.
2. Data Architecture
Information Structure: Definition of information structures and their relationships.
Data Management: Capture, storage, management, and use of information / data.
Data Quality and Security: Ensuring the integrity, confidentiality, and availability of
information / data.
3. Application Architecture
Application Portfolio: Management and optimization of corporate applications.
Integration: Capture and management of the integration of various applications.
Lifecycle Management: Development, maintenance, and decommissioning of applications.
4. Technology Architecture
Infrastructure: Hardware, networks, and base software supporting the IT environment.
Technology Standards: Guidelines and standards for the deployed technologies.
Platforms: Operating systems, middleware, and databases required for application operation.
EAM aims to represent the corporate structure and its strategic, professional, and (information)technological perspectives as comprehensively and transparently as possible.
The operational implementation requires these perspectives to be combined into a holistic picture. For this purpose, an enterprise architecture model is designed. An EAM model encompasses the systematic and structured representation of the strategic, professional, and technological relationships within a company or public sector organization. It serves as a comprehensive basis for the planning, analysis, development, and management of the organization in question.
Goals and Benefits of an Enterprise Architecture Model
1. Transparency: Creating a clear overview of strategic, professional, and technological relationships.
2. Efficiency: Identifying redundancies and optimization points across various resources.
3. Flexibility and Agility: Supporting the ability to respond quickly to changes in the market or business requirements.
4. Strategic Alignment: Ensuring that the IT strategy is aligned with business strategies and goals.
5. Risk Management: Identifying and managing risks in the IT infrastructure and business processes.
6. Innovation: Promoting and supporting the implementation of new technologies and innovative solutions.
To create an enterprise architecture model, modeling objects are used to capture different areas of an organization and document their relationships. The resulting network enables analysis and optimization of the entire enterprise architecture, not just IT-related issues. Cross-cutting relationships enable the identification of interrelationships and potential for improvement across the enterprise, as well as the early recognition of impacts on all affected business areas (e.g., for upcoming IT transformations, digitization projects, or AI implementations).
The division into the above-mentioned architecture areas makes it easy to capture content, while at the same time understanding, interpreting and quickly reacting to cross-cutting relationships. Through sophisticated analysis and reporting, an integrated EAM model enables the optimal answer to the tasks and questions of different stakeholders.
Structure (Method)
Layers
The EAM modeling in BIC Process Design follows the general architectural views:
Business Architecture:
The focus of business architecture is the systematic analysis, design, and optimization of a company’s business processes and organizational structures. It aims to translate business strategy and goals into efficient and effective processes to improve corporate or governmental performance. This includes the modeling of processes, the definition of roles and responsibilities, and ensuring that business processes are optimally supported by the IT infrastructure.
Data Architecture:
The focus of data architecture is the structured capture, organization, storage, and management of information within a company or public sector organization. It aims to ensure the integrity, consistency, and availability of data. With the help of data architecture, it is easy to ensure efficient data flow between systems and applications. Strategies for data quality, data integration, and data security are defined to optimize the use of information as a valuable resource.
Application Architecture:
The focus of application architecture is the planning, design, and management of an organization’s software applications. It aims to develop a coherent and efficient application portfolio that optimally supports business processes. This includes the definition of application components, their interactions and integrations, as well as the establishment of standards and guidelines for the development, maintenance, and further development of applications.
Technology Architecture:
The focus of technology architecture is the design and management of a company’s or public sector organization’s technical infrastructure. It includes the hardware, networks, middleware, and fundamental software platforms that form the basis for applications and data management. The goal is to create a stable, scalable, and secure technical environment that efficiently supports business requirements and enables the use of new technologies.
To model the content, various object types are offered. Each object type is clearly assigned to an architectural level. By connecting objects - even across multiple architectural levels - a transparent, cohesive, and complete view of a company’s or public sector organization’s architecture is created.
Special Objects in EAM Modeling
To build the previously described architectural views, BIC EAM provides various catalog object types. The following table gives an overview of these objects along with their corresponding layer and a brief description:
Object Type |
Architectural Layer |
Description |
|---|---|---|
Business Capability |
Business Architecture |
A Business Capability is the ability of a company |
Business Context |
Business Architecture |
A Business Context describes the professional |
Organizational Unit |
Business Architecture |
An Organizational Unit is a specific, structured |
IT Risk |
Business Architecture |
An IT Risk refers to the possibility that an |
Application |
Application Architecture |
An Application is a software application that |
Interface |
Application Architecture |
An Interface is a defined point of interaction |
Data Object |
Data Architecture |
A Data Object is a specific, uniquely identifiable |
IT Component |
Technology Architecture |
An IT Component is a single, self-contained |
Provider |
Technology Architecture |
A Provider is a company or organization that |
A detailed description of the objects can be found here.
Diagrams
The above-listed EAM object types describe individual “building blocks” for modeling an enterprise architecture. To map the relationships between these building blocks, BIC EAM provides various diagram types that contain different content from the respective architectural layers. By linking the object types, a network of - sometimes cross-architectural-layer - content is created. The result is a comprehensive and transparent documentation of the enterprise architecture. The following diagram types are provided by BIC EAM:
Diagram |
Description |
|---|---|
Perspective: |
Business Architecture |
Business Capability Map |
A Business Capability Map is a graphical representation of the |
Perspective: |
Business and Application Architecture |
Business Capability Context Diagram |
A Business Capability Context Diagram is a graphical |
Perspective: |
Business, Application, Data and Technology Architecture |
Application Context Diagram |
An Application Context Diagram is a graphical representation |
Data Object Diagram |
In a Data Object Diagram, the hierarchical relationships |
IT Component Diagram |
An IT Component Diagram is a graphical representation that |
A detailed description of the diagrams can be found here.
Objects
Business Capability
A Business Capability describes an ability that a company must possess to fulfill its business mission. It defines “what” a company does without specifying “how” it is done. The latter is usually described by modeling processes, which are referenced in the EAM modeling via business contexts. Detailed process modeling is typically performed within BIC Process Design.
Business Capabilities are the central element in the business architecture layer, as they represent the business area. Since they generally change infrequently, they describe fundamental areas of responsibility. By linking Business Capabilities with applications, it can be effectively shown which business applications are essential for which business capabilities.
Business Context
A Business Context defines, in abstract terms, “how” a company achieves its various tasks and goals. This description can be done in various ways, such as through a customer journey or traditional process modeling. By linking business contexts with Business Capabilities and applications, the specific relationship between fundamental capabilities, the professional activities required to realize them, and the necessary IT support can be depicted. For example, which application supports which business context, and which business context describes the specific implementation of which Business Capability.
Since BIC Process Design offers the modeling of various process details, it is possible to link existing diagrams with a Business Context object.
Organizational Unit
An Organizational Unit represents different organizational units, geographic regions, or user groups/teams within a company or public sector organization. In EAM modeling, they are linked with applications and Business Capabilities to show which Organizational Unit is involved in realizing a Business Capability or which applications it uses.
For clearer structuring, it is also possible to graphically depict hierarchies of Organizational Units in organizational charts.
Application
Applications are the central link between the architectural views. Through their use in various business contexts, they support the implementation of Business Capabilities. In the operation of (business) applications, data — often in conjunction with other applications — are processed and exchanged via interfaces. Furthermore, the use of applications often requires the availability of additional IT components (e.g., servers, cloud services) and corresponding providers.
In a company, there are various applications with different purposes: standard application software, SaaS, or microservices. Generally, it is advisable to focus on specific applications or use cases within the organization’s EAM modeling.
Interface
The data exchange between applications can be represented through Interfaces. Here, an interface can be provided or used by an application. This allows for the modeling of both providing and consuming interfaces.
In addition to the pure connection between applications, a connection to data objects can also be depicted. This allows for very detailed modeling of individual application information flows, including the basic data operations (CRUD).
Data Object
A Data Object describes data processed by applications or exchanged via interfaces. They represent a data entity such as a customer, offer, or contract. For the corresponding exchange relationship (e.g., in connection with an interface), the data operations (CRUD) can be specified.
Consistent modeling of data objects allows for comprehensive and transparent tracking of individual data objects across various applications and provides targeted decision support for IT transformations or consolidation measures.
IT Component
IT Components are a central element of an IT architecture. They model structures that are necessary for the operation of applications. They are an essential component of IT transformation or IT cloud strategy projects.
Each IT Component can be assigned to a provider, which specifies in more detail who operates or provides an IT component. Generally, a provider does not model the manufacturer (except in the case of cloud services).
Provider
Providers typically model companies that provide or operate an IT component, rarely the actual manufacturer of an IT component. Especially when evaluating business relationships, valuable information can be gained by linking providers with IT components.
Diagrams
Business Capability Map
Business Capabilities are usually modeled within a Business Capability Map. In BIC EAM, the representation is done as a graphical hierarchy: In columns (ideally no more than 10) that each depict the core Business Capabilities such as “HR,” “Order Management,” or “Customer Management” and bundle subordinate Business Capabilities such as “Recruiting,” “Order Negotiation,” or “Contract Management.”
Through the nested modeling of Business Capabilities, an aggregation relationship is implicitly modeled, enabling a hierarchy of Business Capabilities.
The diagram’s symbol palette provides two Business Capability symbols: Business Capability and Business Capability (Lifecycle). While the first symbol represents the standard symbol of a Business Capability, the second symbol contains conditional formatting based on the value of the Business Capability’s “Lifecycle” attribute: Depending on the selected lifecycle phase, the symbol is colored accordingly. This makes the individual lifecycle phases directly visible.
Business Capability Context Diagram
In this diagram, Business Capabilities are linked to applications, business contexts, and Organizational Units. The focus of this diagram is on depicting the relationship between applications and the professional modeling, specifically the relationships with Business Capabilities and business contexts. The modeling of interfaces or IT components is not intended in this diagram type (see Application Context Diagram).
It is generally recommended to use EAM objects with the highest hierarchy level possible to represent the most specific context.
Application Context Diagram
In an Application Context Diagram, the relationships between applications and other EAM objects are modeled for a context or use case defined by the modeler. A context can be, for example, the dedicated use of an application for a selected Business Capability and Organizational Units or the use of an interface for a specific business context. In principle, all EAM objects that are specifically related to each other should be modeled in their own context diagram. This makes it easy to see, for example, which business context supports which Business Capability with which application.
Specifically, applications can be linked with Business Capabilities, business contexts, Organizational Units, interfaces, data, IT components, and risks.
In addition, interfaces can also model other involved applications, as well as the data objects and associated risks used. It is important to note that in an Application Context Diagram, only one application is defined as the central object. Further developed applications are modeled on the respective diagram only to depict the relationship structures of the central application to these secondary applications.
Through appropriate extension attributes on the individual objects, context-specific properties can be set for the modeled context.
It is generally recommended to use EAM objects with the highest hierarchy level possible to represent the most specific context (e.g., SAP S4/HANA instead of ERP system).
IT Component Diagram
This diagram is used to represent relationships between various IT components. Essentially, aggregation relationships are captured, which can be modeled either through graphical nesting or through a corresponding edge relationship. In addition to aggregation, the relationship types composition, serviced, and realization can also be modeled through visual edges.
Data Object Diagram
This diagram is used to represent relationships between various IT components. Essentially, aggregation relationships are captured, which can be modeled either through graphical nesting or through a corresponding edge relationship. In addition to aggregation, the relationship types composition, serviced, and realization can also be modeled through visual edges.
Modeling Guide
What is the general modeling concept in BIC EAM?
BIC EAM combines intuitive modeling in diagrams with traditional EAM objects such as Business Capabilities, applications, or IT components, along with capturing comprehensive detail information through form-like input screens. As is customary with BIC Process Design, EAM objects are created as catalog objects and centrally managed. These elements can be related to each other through various diagrams in different modeling situations.
Essentially, EAM diagrams can be divided into two types:
Context Diagrams:
Business Capability Context Diagram and Application Context Diagram are used to model relationships between various EAM objects in freely definable scenarios (contexts).
Hierarchy Diagrams:
Business Capability Map, IT Component Diagram, Data Object Diagram, and IT Architecture Diagram are used to model hierarchical aggregation relationships for Business Capabilities, IT components, data objects, and applications.
The basic concept in modeling EAM objects and their relationships is context-based modeling. This means that for a specific context or use case, an EAM element is represented in a corresponding context diagram and linked with other artifacts relevant to the respective use case. For example, in a context diagram (e.g., “BIC Usage EMEA Australia”), it can be modeled intuitively that BIC Process Design is already used in the public cloud in the EMEA and Australia Organizational Units, while another system is still used in Canada for supporting Business Capability modeling in a different context diagram (e.g., “Modeling Tool Canada”). In each of these context diagrams, context-sensitive attributes like functional suitability can be set and evaluated.
Context-based modeling allows properties of individual EAM objects (especially for applications, Business Capabilities, IT components, and interfaces) to be specifically defined for each context. Many EAM attributes (e.g., functional or technical suitability, a TIME or 6R classification, or a criticality assessment) are extension attributes. These apply only to the specific extension of an object in a specific context diagram.
How do I start EAM modeling?
At the beginning, it is recommended to add the EAM elements to be modeled to the catalog. Depending on the focus and architectural view, different focal points emerge:
Business Architecture
The central component of business architecture modeling is the Business Capability. It describes the ability a company or public sector organization must have to achieve its goals. It is often helpful to group Business Capabilities by functional areas or departments. With the Business Capability Map diagram, Business Capabilities can be clearly displayed, providing a central view of the company’s capabilities.
In an EAM model with a business focus, Business Capabilities can be linked with business contexts, organizational units, and applications. This creates a Business Capability Context Diagram that shows which business context (usually a process) supports which Business Capability, which Organizational Units are affected, and which applications are required. Depending on the desired level of detail, these relationships can be modeled generally or specifically for individual contexts, e.g., if different Organizational Units use different applications for a Business Capability. It is recommended to draft possible contexts before starting the modeling process.
Application Architecture
The application is at the center of application architecture. Similar to the Business Capability Context Diagram, the Application Context Diagram allows for the modeling of relationships between applications and other EAM objects. Here, an application serves as the link between business architecture and technology architecture. Specifically, this means that an application can be linked with Business Capabilities, business contexts, and Organizational Units, as well as IT components, interfaces, and data objects. Simplified, the Business Capability Context Diagram combines the “upward” view towards professional requirements with the “downward” view towards information technology. As with the Business Capability Context Diagram, the level of detail in the modeling is very flexible.
Data Architecture
Data architecture allows for the structured description of information / data processed within a company or public sector organization or data products that are created or processed within the organization. With the help of data architecture, it is easy to ensure efficient data flow between systems and applications. Strategies for data quality, data integration, and data security are defined to optimize the use of information as a valuable resource. It is recommended to initially capture and detail the essential data objects of the organization in the catalog. A consistent nomenclature is particularly helpful in ensuring the redundancy-free and contradiction-free use of data objects in the EAM model.
Technology Architecture
The IT Component Diagram and IT Architecture Diagram are used for the detailed modeling of existing IT resources. In these diagrams, hierarchies of IT components, data objects, and applications are primarily modeled. Additionally, relationships between IT components can be modeled using composition or association relationships in the IT Component Diagram.
As in many areas of BIC EAM modeling, the object types of technology architecture also have both entity attributes and extension attributes. While the entity attributes always apply to the object in every context, the extension attributes apply only to the specific instance of an object expressed in a diagram. This allows for context-specific attributes, such as the functional suitability of an object, to be defined with different values in different contexts when modeling in a context diagram.
How do I model the lifecycle of an EAM object?
Each EAM object has a lifecycle attribute as an extension attribute. This allows you to define the lifecycle of the respective object individually within the respective context, especially in the two context diagrams. Additionally, for applications, IT components, and providers, it is possible to define specific dates for the individual phases of the lifecycle as entity attributes.
Which hierarchy level should I use in context diagrams?
It is generally recommended to use EAM objects with the highest hierarchy level possible to represent the most specific context.
How do I set the validity of individual context diagrams?
The validity period of a context diagram can be defined through the governance attributes “Valid From” and “Valid To.” These attributes represent the chronological sequence of various context diagrams. Additionally, for Business Capability Context Diagrams and Application Context Diagrams, the “Predecessor” attribute is available, which also allows for the explicit documentation of the sequence of different diagrams.
How do I best manage variants of a context diagram?
There are several ways to manage different variants of a context diagram. Depending on the variety of contexts, different categories like “AS-IS” and “TO-BE” or diagram name prefixes can be used. Additionally, it is also possible to link the respective context diagrams through the “Predecessor” attribute or the variant management.
Hint
Each EAM model is individual, based on the company or public sector organization that created it. For this reason, it is recommended to conduct a best-practice alignment with GBTEC experts before beginning EAM modeling.