Web-Modeler Enabled Diagram | QualiWare Center of Excellence

Business Ecosystem

Purpose: The purpose of the Business Ecosystem template is to enable an organization to understand itself from an outside-out perspective by modelling the environment in which the organization is embedded.

Core concerns: The Business Ecosystem supplies five elements to model with: Business, People, Things, Business Interaction and Business Moment. The Business Ecosystem template should primarily be used for modeling entities outside the enterprise to identify new business opportunities in the form of Business Moments.

Above you can see a model of a Business Ecosystem. The blue areas are Business Moments, where the interactions between People, Businesses and Things create business opportunities for your enterprise.

Relation to other templates: The Business Ecosystem model is based on the Enterprise Design theories and is as such in the same family as the Customer journey map.

The Business Ecosystem is a strategic model and can be used to document a strategic possibility or track along with for example Business Capability Models, Strategy Models, and Work Models.

Properties and metadata: The Business Ecosystem can for example retain the following information:

A description of the diagram
Link to the owner of the application architecture
Link to the one responsible for the application architecture
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

For more information: If you want to learn more about Enterprise Design, we have a four-part webinar by Milan Guenther available for viewing. You can also visit Milan’s website, where you can learn more about the Enterprise Design framework.

Business Diagram

Purpose: The purpose of a Business Diagram is to show the functional structure and relationships of the whole or part of an organization.

Core concerns: The Business Diagram template enables you to model Business Functions, Information Systems, Inventory, Business Scope, Lines of Business, Information Flow and Logistical Flow. The diagram’s syntax can be extended to also include strategic elements such as Goals, Objectives, Stakeholders and Performance Indicators.

The Business Diagram should be broken down into several levels of recurring Business Diagram templates. In the model below, you can see an example of a high-level Business Diagram showing Business Functions and their Information Flows and Logistical Flows – describing the flow of products and services – in this case for a car rental service.

The Business Functions are placed with the operational functions in the bottom together with the Logistical Flow and with management control at the top of the Business Diagram.

On lower levels (decompositions) of Business Diagrams, Information Systems are placed close to the Business Functions that are responsible for or own the Information Systems.

Relation to other templates: The Business Diagram can be used as an addition to a Business Process Network and Strategy Models, giving a practical view of how the organizations functions fit together, illuminating interdependencies.

Properties and metadata: The Business Diagram can for example retain the following information:

A description of the diagram
Link to the owner of the Diagram
Link to the one responsible for the Diagram
Indication of the diagram portrays an as-is situation or a to-be situation
The Perspective can be defined as either: Holistic, Sub-functional, Process, or IT Focused.
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the Business Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Business Capability Model

Purpose: The purpose of the Business Capability Model template is to provide an overview of the of the state and health of an enterprise in the form of its Capabilities.

Core concerns: The Business Capability Model is a simple template that by default only allows for the modelling of Capabilities with the possibility to add notes if needed. The metadata of the Capabilities – such as status and importance can then be graphically displayed in the business capabilities to create a useful overview.

The stripe on the left side to represent Business Importance and two dots representing Business Maturity and Target Maturity. The new design scales better and provides management with a single view of important strategic capabilities with a plan for improvements. Also it allows the business architect to highlight a set of capabilities by coloring the symbol’s background – a widely used technique.

In the picture above you can see an example of a Business Capability Model. Here the Business Capabilities are grouped in different areas and the status and importance of them are shown by their green, yellow or red colorings.

In this Business Capability Model (shown above), more attributes are shown at the right-hand side of the Capability. This way you can get a more detailed view of the state of your enterprises Capabilities.

Other functionalities: Using the Analysis tool, the information from the Business Capability Model template can generate maturity- and score heat maps, hierarchies, score views, capability contexts, gap analyses, dashboards, and what-if-, impact- and investment analyses.

Relation to other templates: The Business Capability Model is a strategic template and is as such complimentary to for example the Strategy Model and Work Model. It can be used to illustrate a change process going from one set of capabilities to another. A Capability can link to the Business Processes that uses it as well as the resources it employs. This way it can also be analyzed which Business Processes would be affected by the improvement or worsen of a given Capability.

It is easy to update and analyse the capability models via the standard views on the web:

The capabilities in a Business Capability Model can easily be scored and presented in filterable and editable lists via the spreadsheet functionality in e.g. the Properties view

The capabilities can be presented in a Capability heatmap

From the Delivered by view you can analyze and update relations between capabilities and initiatives, processes, applications and information-objects.

Properties and metadata: The Business Capability Model can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the accuracy of the diagram
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

The above picture shows the properties dialogue window for the Business Capability Model where you can edit the diagram’s properties.

Note that the Capabilities’ metadata that are exhibited in the Business Capability Model is not further described here as they belong to the Capability object and not the Business Capability Model template.

Balanced Scorecard Diagram

Purpose: The purpose of the Balanced Scorecard Diagram is to model Balanced Scorecards, as described by Robert Kaplan and David Norton in 1992.

Core concern: Usually, a Balanced Scorecard Diagram template measures the state of the enterprise via Key Performance Indicators that are categorized into four different perspectives using Business Scopes. Aside from this, the template enables you to model general concepts and cause/effect.

Below, you can see an example of a Balanced Scorecard Diagram:

Relation to other templates: The Balanced Scorecard Diagram can be used to create a Performance Evaluation Model or a Strategic Management Diagram the Key Performance Indicators it contains can be broken down into Performance Diagrams offering a detailed view of how the organization performs. If CXO dashboards are to be created, the Strategy Model should be used instead.

Properties and metadata: The Balanced Scorecard Diagram can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram.

The above picture shows the properties dialogue window for the Balanced Scorecard Diagram, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Application Usage Viewpoint : Archimate

Purpose: Designing, deciding

Concerns: Consistency and completeness, reduction of complexity

Scope: Multiple layer/Multiple aspect

The application usage viewpoint describes how applications are used to support one or more business processes, and how they are used by other applications. It can be used in designing an application by identifying the services needed by business processes and other applications, or in designing business processes by describing the services that are available. Furthermore, since it identifies the dependencies of business processes upon applications, it may be useful to operational managers responsible for these processes.

Abstraction Level
Coherence

Layer
Business and application layers

Aspects
Behavior, active structure, passive structure

Physical Viewpoint : Archimate

Concerns: Relationships and dependencies of the physical environment and how this relates to IT infrastructure
Purpose: Designing
Scope: Multiple layer/Multiple aspect

The physical viewpoint contains equipment (one or more physical machines, tools, or instruments) that can create, use, store, move, or transform materials, how the equipment is connected via the distribution network, and what other active elements are assigned to the equipment.

Layered Viewpoint : Archimate

Concerns: Consistency, reduction of complexity, impact of change, flexibility
Purpose: Designing, deciding, informing
Scope: Multiple layer/Multiple aspect

The layered viewpoint pictures several layers and aspects of an Enterprise Architecture in one diagram. There are two categories of layers, namely dedicated layers and service layers. The layers are the result of the use of the “grouping” relationship for a natural partitioning of the entire set of objects and relationships that belong to a model. The technology, application, process, and actor/role layers belong to the first category. The structural principle behind a fully layered viewpoint is that each dedicated layer exposes, by means of the “realization” relationship, a layer of services, which are further on “serving” the next dedicated layer. Thus, we can easily separate the internal structure and organization of a dedicated layer from its externally observable behavior expressed as the service layer that the dedicated layer realizes. The order, number, or nature of these layers are not fixed, but in general a (more or less) complete and natural layering of an ArchiMate model should contain the succession of layers depicted in the example given below. However, this example is by no means intended to be prescriptive. The main goal of the layered viewpoint is to provide an overview in one diagram. Furthermore, this viewpoint can be used as support for impact of change analysis and performance analysis or for extending the service portfolio.

All core elements and all relationships are permitted in this viewpoint.

Stakeholder Viewpoint : Archimate

Concerns: Architecture mission and strategy, motivation
Purpose: Designing, deciding, informing
Scope: Motivation

The stakeholder viewpoint allows the analyst to model the stakeholders, the internal and external drivers for change, and the assessments (in terms of strengths, weaknesses, opportunities, and threats) of these drivers. Also, the links to the initial (high-level) goals that address these concerns and assessments may be described. These goals form the basis for the requirements engineering process, including goal refinement, contribution and conflict analysis, and the derivation of requirements that realize the goals.

Goal Realization Viewpoint: Archimate

Concerns: Architecture mission, strategy and tactics, motivation
Purpose: Designing, deciding
Scope: Motivation

The goal realization viewpoint allows a designer to model the refinement of (high-level) goals into more tangible goals, and the refinement of tangible goals into requirements or constraints that describe the properties that are needed to realize the goals. The refinement of goals into sub-goals is modeled using the aggregation relationship. The refinement of goals into requirements is modeled using the realization relationship.

In addition, the principles may be modeled that guide the refinement of goals into requirements.

Requirements Realization Viewpoint : Archimate

Concerns: Architecture strategy and tactics, motivation
Purpose: Designing, deciding, informing
Scope: Motivation

The requirements realization viewpoint allows the designer to model the realization of requirements by the core elements, such as business actors, business services, business processes, application services, application components, etc. Typically, the requirements result from the goal refinement viewpoint.

In addition, this viewpoint can be used to refine requirements into more detailed requirements. The aggregation relationship is used for this purpose.