Diagrams | QualiWare Center of Excellence

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.

Architecture Framework

Purpose: The purpose of the Architecture Framework template, is to provide an overview of the enterprise, and the context for a diagram, showing where in the architecture and repository it belongs. An Architecture Framework shows the overall structure of the architecture and the structure with which it is represented in the repository.

Core concerns: The Architecture Framework template consists of FrameWorkCells, FrameWorkColumns, FrameWorkRows and LineOfBusinesses. You can choose to model the framework to fit the one your organization is using – QualiWare supports a wide range of architecture frameworks out of the box such as Zachman, TOGAF , OIOEA, EA3 Cube, EDGY, QualiWare EA Framework, and many more.

Below, you can see an example of the QualiWare EA Framework:

Below, you can see an example of a TOGAF framework:

Relation to other templates: The Architecture Framework template is used to represent the repository’s architecture in the form of a specific framework. If CXO dashboards are to be created, the Strategy Model should be used instead.

An ArchitectureFramework can be modeled using FrameWorkRows, FrameWorkColumns, and FrameWorkCells

Properties and metadata: The Architecture Framework can for example retain the following information:

A description of the diagram
Link to Architecture principles and project models
Link to the owner of the framework
Link to the one responsible for the framework
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 Architecture Framework 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

Application Functionality Context

Purpose: The purpose of the Application Functionality Context template is to document the in which Activities and/or Business Processes a given Application Functionality is used.

Core concerns: The Application Functionality Context template can be used to create graphical views showing where Application Functionalities are used. The template enables you to model Application Functionalities, Activities and Business Processes. The Business Processes and Activities are connected to Application Functionalities using Functionality Usage.

Below, you can see an example of an Application functionality contest diagram, where the context for the DocCom – Create and Store Document functionality is shown:

The diagram shows which Business Processes use the Application Functionality as well as which Information System delivers it.

Relation to other templates: To map applications hardware, the Application Architecture Diagram or Infrastructure Diagram template should be used. The Application Functionality Context template graphically connects functionalities of Information Systems to the Processes and Activities in which they are used. It offers an additional view to Application Architecture Diagrams, Workflow Diagrams, Business Process Diagrams and Business Process Networks.

Properties and metadata: The Application Functionality Context template can for example retain the following information:

A description 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

The above picture shows the properties dialogue window for the Application Functionality Context template where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Implement Deployment Viewpoint :ArchiMate

Concerns: Structure of application platforms and how they relate to supporting technology
Purpose: Designing, deciding
Scope: Multiple layer/Multiple aspect

The implementation and deployment viewpoint shows how one or more applications are realized on the infrastructure. This comprises the mapping of applications and components onto artifacts, and the mapping of the information used by these applications and components onto the underlying storage infrastructure.

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.

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).

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.

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.

Information Structure Viewpoint : Archimate

Concerns: Structure and dependencies of the used data and information, consistency and completeness
Purpose: Designing
Scope: Multiple layer/Single aspect

The information structure viewpoint is comparable to the traditional information models created in the development of almost any information system. It shows the structure of the information used in the enterprise or in a specific business process or application, in terms of data types or (object-oriented) class structures. Furthermore, it may show how the information at the business level is represented at the application level in the form of the data structures used there, and how these are then mapped onto the underlying technology infrastructure; e.g., by means of a database schema.