Stakeholder: Operations Managers

Business Canvas

Purpose: The Business Canvas, is a strategic management and entrepreneurial template. It allows you to describe, design, challenge, invent, and pivot your business model.

Core Concerns: The core elements of the business canvas are framework cells that define a strategic or organizational entities and, if needed, connections between them. The Business Model can be structured any way you wish. The most well know structure of a business model is Alexander Osterwalder’s Business Model Canvas.

BusinessCanvas_1

The above picture shows a blank Business Model Canvas where each area is represented by a framework cell.

The strategic or organizational entities can then be enriched with an extended portfolio of strategic symbols such as vision, mission, goals, stakeholders, information systems and business processes.

Full content list of the extended portfolio:

  • Vision
  • Mission
  • Business Object
  • Market
  • Competitive Advantage
  • Technology
  • Competence
  • Capability
  • Performance Indicator
  • Business Function
  • Business Process
  • Organization Unit
  • Stakeholder
  • Information System
  • External Entity
  • Location
  • Channel
  • Goal
  • Opportunity
  • Threat
  • Trend
  • Material Asset
  • Intellectual Capital Asset
  • Business Rule
  • Key Performance Indicator

 

 

 

 

 

 

 

The picture below shows a Business Model Canvas that is filled out with symbols from the extended portfolio.

BusinessCanvas_2

Relation to other templates: The Business Canvas can link to multiple related templates detailing the businesses capabilities, business processes, strategy and more.

Properties and metadata: The Business Canvas Diagram 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

 

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:

BalancedScoracardDiagram_1

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

ApplicationUsageViewpoint_1

Technology Viewpoint : Archimate

Concerns: Stability, security, dependencies, costs of the infrastructure
Purpose: Designing
Scope: Single layer/Multiple aspect

The technology viewpoint contains the software and hardware technology elements supporting the Application Layer, such as physical devices, networks, or system software (e.g., operating systems, databases, and middleware).

Technology Usage Viewpoint : Archimate

Concerns: Dependencies, performance, scalability
Purpose: Designing
Scope: Multiple layer/Multiple aspect

The technology usage viewpoint shows how applications are supported by the software and hardware technology: the technology services are delivered by the devices; system software and networks are provided to the applications. This viewpoint plays an important role in the analysis of performance and scalability, since it relates the physical infrastructure to the logical world of applications. It is very useful in determining the performance and quality requirements on the infrastructure based on the demands of the various applications that use it.

Service Realization Viewpoint : Archimate

Concerns: Added-value of business processes, consistency and completeness, responsibilities
Purpose: Designing, deciding
Scope: Multiple layer/Multiple aspect

The service realization viewpoint is used to show how one or more business services are realized by the underlying processes (and sometimes by application components). Thus, it forms the bridge between the business products viewpoint and the business process view. It provides a “view from the outside” on one or more business processes.

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.

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.

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.