Employees | QualiWare Center of Excellence

Business Operating Model

Purpose: The purpose of the Business Operating Model is to visualize how an organization functions and delivers value to its customers. The model presents a ‘one-page-overview’ of the organization and offers a quick way to communicate an organization’s value structure to different types of stakeholders.

Core concerns: The Business Operating Model can be put together in numerous ways including information on Stakeholders, Business Processes, Products, Projects, Channels, Key Performance Indicators and more. This enables you to create a Business Operating Model that reflects your organization’s specific value chain in detail. Below is an example of a Business Operating Model that shows a business’s suppliers, high-level processes, products & services, channels and customer segments:

Relation to other templates: The Business Operating Model is a strategic model that can be supplied with more detailed models such as a Business Capability Model, Requirement Models, Stakeholder Models and the Business Ecosystem Model.

Properties and metadata: The Business Operating 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
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.

In the picture below you can see the Business Operating Model’s properties dialogue window, where the information can be viewed and edited:

Organization Diagram

Purpose: The purpose of the Organization Diagram template is to document the Organizational structure for a company or part of a company. Below, you can see an example of an Organizational Diagram describing the different departments of a company:

Core Concerns: The Organization Diagram template focuses on the documentation of organization units, positions and their interrelationships. The relationship between units illustrates responsibility. The example below of a regional office illustrates the levels of responsibilities between its different departments:

Relation to other templates: The Organization Units in the Organization Diagram can link to diagrams such as Business Process Networks, Business Process Diagrams, Workflow Diagrams, Business Canvas, Strategy Model and more. You decide what kind of information you want to be accessible through the organization diagram. To model the organization in relation to its environment for strategic purpose, you can use the Business Ecosystem template.

Properties and metadata: The Organization 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 accuracy of 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
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below, you can see the Organization Diagram’s properties dialogue window, where its properties can be viewed and edited:

Organization Viewpoint : Archimate

Concerns: Identification of competencies, authority, and responsibilities
Purpose: Designing, deciding, informing
Scope: Single layer/Single aspect

The organization viewpoint focuses on the (internal) organization of a company, department, network of companies, or of another organizational entity. It is possible to present models in this viewpoint as nested block diagrams, but also in a more traditional way, such as organizational charts. The organization viewpoint is very useful in identifying competencies, authority, and responsibilities in an organization.

Project Viewpoint : Archimate

Concerns: Architecture vision and policies, motivation
Purpose: Deciding, informing
Scope: Implementation and Migration

A project viewpoint is primarily used to model the management of architecture change. The “architecture” of the migration process from an old situation (current state Enterprise Architecture) to a new desired situation (target state Enterprise Architecture) has significant consequences on the medium and long-term growth strategy and the subsequent decision-making process. Some of the issues that should be taken into account by the models designed in this viewpoint are:

Developing a fully-fledged organization-wide Enterprise Architecture is a task that may require several years.
All systems and services must remain operational regardless of the presumed modifications and changes of the Enterprise Architecture during the change process.
The change process may have to deal with immature technology standards (e.g., messaging, security, data, etc.).
The change has serious consequences for the personnel, culture, way of working, and organization.

Furthermore, there are several other governance aspects that might constrain the transformation process, such as internal and external cooperation, project portfolio management, project management (deliverables, goals, etc.), plateau planning, financial and legal aspects, etc.

Migration Viewpoint : Archimate

Concerns: History of models
Purpose: Designing, deciding, informing
Scope: Implementation and Migration

The migration viewpoint entails models and concepts that can be used for specifying the transition from an existing architecture to a desired architecture.

Implement Migration Viewpoint : Archimate

Concerns: Architecture vision and policies, motivation
Purpose: Deciding, informing
Scope: Multiple layer/Multiple aspect

The implementation and migration viewpoint is used to relate programs and projects to the parts of the architecture that they implement. This view allows modeling of the scope of programs, projects, project activities in terms of the plateaus that are realized or the individual architecture elements that are affected. In addition, the way the elements are affected may be indicated by annotating the relationships.

Furthermore, this viewpoint can be used in combination with the programs and projects viewpoint to support portfolio management:

The programs and projects viewpoint is suited to relate business goals to programs and projects. For example, this makes it possible to analyze at a high level whether all business goals are covered sufficiently by the current portfolio(s).
The implementation and migration viewpoint is suited to relate business goals (and requirements) via programs and projects to (parts of) the architecture. For example, this makes it possible to analyze potential overlap between project activities or to analyze the consistency between project dependencies and dependencies among plateaus or architecture elements.