Integration View

Purpose: The purpose of the Integration View template is to document the routing of integrations between systems.

Core concerns: The Integration View template enables you to model Information Systems, System Components and External Entities (a source to or a receiver of information from a system), and connect them using Integration Flows.

Below is an example of an Integration View concerning the flow of test data:

Relation to other templates: The Integration View belongs to the Application layer of the architecture and is as such related to the Application Architecture Diagram, the Data Flow Diagram and the Component Diagram.

Properties and metadata: The Integration View template can for example retain the following information:

  • A description of the model
  • 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 Integration View template where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

Innovation Canvas

Purpose: The Purpose of the Innovation Canvas is to model ideas for Innovation detailing their goals and ideas for action.

Core concerns: The Innovation Canvas allows you to model an innovation detailing the ideas that exist in relation to it. In the example below, the goals of the innovation have also been defined and attached. Goals, vision, mission and many more strategic objects are available in the default extended syntax for the diagram, enabling you to model your ideas for innovation in as much detail as you prefer.

Relation to other templates: The Innovation Canvas is a strategic template and the elements modelled in it can easily be connected to other strategic templates such as a Strategy Model, Enterprise Investment Portfolio, Business Canvas or Business Capability Model.

Properties and metadata: The Innovation Canvas 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 Innovation Canvas’ properties dialogue window, where the properties can be viewed and edited:

Hierarchy View

Purpose: The purpose of the Hierarchy View template is to show the hierarchy of objects related to a chosen root object.

Core concerns: The root object in the hierarchy View can for example be a Capability or a Business Process. The view is not modeled as a diagram, but generated based on information specified in the template’s property dialog, making the scope of the view flexible. Below, you can see an examples of a Hierarchy View for the Capability “Market Objects”:

Relation to other templates: The Hierarchy View is not directly connected to any single template but is not unlike a Context View. The Hierarchy View is, compared to a Context View, usually filtered to only show certain types of relations amongst certain types of objects and not as a default connected to diagram templates:

Properties and metadata: The Hierarchy View template can for example retain the following information:

  • A description of the diagram
  • Link to the owner of the Hierarchy View
  • Link to the one responsible for the Hierarchy View
  • Audits (auto generated information regarding its current state and access rights)
  • Specifications (definition of root object and other inclusion criteria)
  • Adjust (specification of templates that should be removed from the view)
  • 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 Hierarchy View template where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

The HierachyView can be used in relation to the Standard Tree View in the HTMLPublisher, to establish a hierarchy for the network of process models in a repository.

Graphical Matrix

Purpose: The purpose of the Graphical Matrix template is to compare the states or scores of objects, such as for example Capabilities or Information Systems.

Core concerns: The Graphical Matrix is generated based on information inserted into its property dialog where input, x-axis and y-axis are defined. Below, you can see an example of a Graphical Matrix for capabilities, scoring their quality and timeliness:

GraphicalMatrix_1

Relation to other templates: When scoring risks and visualizing residual risks, you can use a Heatmap.

Properties and metadata: The Graphical Matrix template can for example retain the following information:

  • A description
  • Link to the source of the input
  • Coordinate definitions of the Graphical Matrix
  • Audits (auto generated information regarding its current state and access rights)
  • Associated documents, diagrams and other objects

The above picture shows the properties dialogue window for the Graphical Matrix, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager. Below, you can see the tab for Coordinate Definition:

Generic Query

Purpose: The Purpose of the Generic Query template is to provide datasets for QualiWare System templates.

Core concerns: The Generic Query template is an auxiliary template. The Generic Query can be created using a Query Design template which enables you to easily structure the query for creating reports. When creating a Report for a diagram, the Generic Query created using the Query Design should be used as a Data Set in the Report Definition.

A Generic Query can also be generated using its Property Dialog, where you can link to Data Source and filter the data selection using a wizard – see example of the property dialog below:

The Generic Query can, for example, take the form of data sheets:

GenericQuery_2

The Generic Query template can also execute a command using the Advanced Query tab:

Relation to other templates: Generic Queries are automatically created when creating a Query Design. Generic Queries are used in the following templates: HTML Template Definitions, HTML Embedded content, HTML Publisher and HTML Content tab.

Properties and Metadata: The Generic Query can for example rentain the following information:

  • A description
  • Audits (auto generated information regarding its current state and access rights)
  • Query Filter, including a wizard for filter options
  • Attribute Definition
  • Advanced Query
  • Matrix Behavior

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

 

 

Deployment Diagram

Purpose: The purpose of the Deployment Diagram is to document the configuration of run-time processing nodes and the components they contain.

Core concerns: The Deployment Diagram template is structural UML diagram that enables you to model Packages, Components, Artifacts, Instance Specifications, Properties, Nodes, Devices, Execution Environments, Deployment Specifications, Objects, Classes, Interfaces, and Annotations. They can then be connected through Association, Dependency, Generalization, Deployment or Manifestation.

The Deployment Diagram models how the different hardware component and software components are connected. Below you can see an example of a Deployment Diagram for a booking service:

DeploymentDiagram_1

In the next example, you can see how Packages and Components would be included in a Deployment Diagram:

DeploymentDiagram_2

Relation to other templates: The Deployment Diagram is, as a component model, part of the application domain on the operational level. As such, it offers a complimentary view to those of the Application Architecture Diagram, Class Diagram, Component Diagram, Data Flow Diagram, Data Mapping Diagram, Data Replication Diagram, Sequence Diagram, State Event Diagram, Structure Chart, and Use Case Diagram.

Properties and metadata: The Deployment 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
  • Links to extensions such as Stereotypes and Constraints
  • 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 Deployment Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

 

 

 

 

Data Mapping Diagram

Purpose: The purpose of the Data Mapping Diagram is to map data’s sources.

Core concerns: The Data Mapping Diagram template enables you to model Data Entities, Classes, Tables, Records and Mapping Algorithms. These are connected by Data Mappings. The Data Mapping Diagram is sometimes called Entity Mapping Diagram.

Below, you can see an example of a Data Mapping Diagram where data is moved from one table to another transforming from ‘customer data’ into ‘client data’:

DataMappingDiagram_1

The following very simple diagram illustrates the relations between Records and their elements:

DataMappingDiagram_2

Relation to other templates: The Data Mapping Diagram is, through the object Data Transformation, related to the Data Replication Diagram. Data Transformation is contained in the Data Replication Diagram and has a mapping which is described in the Data Mapping Diagram.

Properties and metadata: The Data Mapping Diagram 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 Data Mapping Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

 

 

 

Dashboard

Purpose: The purpose of the Dashboard template is to publish selections of Business Charts targeting different stakeholders. It should be used to gather a series of relevant or connected Business Charts to provide a dashboard-like overview.

Core concerns: The Dashboard template enables you to gather Business Charts, Key Performance Indicators, Performance Indicators and General Concepts to create stakeholder specific views of analyzed data. For example, an Enterprise Architect could find a Dashboard containing Business Charts relevant to the usage and governance of the Enterprise Architecture useful.

Below, you can see examples of different Dashboards presenting an array of Business Charts:

Dashboard_1

 

Dashboard_2

Relation to other templates: The Dashboard template is closely connected to the Business Chart template, as the Dashboard publishes the charts the Business Chart template generates.

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

  • A description of the Dashboard
  • Link to the owner of the Dashboard
  • Link to the one responsible for the Dashboard
  • 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 Dashboard template where you can view and edit the dashboard’s properties in QualiWare Lifecycle Manager.

Concept Model

Purpose: The purpose of a Concept Model is to organize an enterprise’s vocabulary to support cPonsistent and unambiguous communication about specific problem domains across business units.

Core concerns: The Concept Model template enables you to model Concepts, Specialization Aspects and Subject Areas. They can be linked by Concept Associations, Concept Aggregations, Concept Generalizations, Type Relationships, and Relationship Constraints.

You are also able to link the diagram to its area of usage through the model’s property dialogue. This area of usage can by default be set to be either an Organization Unit, Role, Actor or External Entity.

Below you can see some examples of Concept Models from a healthcare domain:

The model above shows the concepts related to the healthcare activity ‘knee arthroplasty’. The model below shows the concepts related to a signature in the healthcare domain:

ConceptModel_1

The model above shows the concepts related to the healthcare activity ‘knee arthroplasty’.

The model below shows the concepts related to a signature in the healthcare domain:

ConceptModel_2

Relation to other templates: A Concept Model should enable the identification of the right terms to use in communications where high precision is needed. This is useful when creating large sets of business rules or processes that need to fit together without ambiguity and when creating complex Data Models. As such, it could be advantageous to link to a concept model from the affected Business Process Networks, Workflow Diagrams, Requirements Models and Regulation Diagrams.

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

  • A description of the diagram
  • Link to the owner of the model
  • Link to the one responsible for the model
  • Link to view of area of usage
  • 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 Concept Model, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: to learn more about Concept Models, you can read the following article:

Ronald G. Ross , “What Is a Concept Model?” Business Rules Journal Vol. 15, No. 10, (Oct. 2014). URL: http://www.brcommunity.com/a2014/b779.html

Component Diagram

Purpose: The purpose of the Component Diagram is to specify the structure of and dependencies among the different components that make up a system.

Core concerns: The Component Diagram template enables you to model a system’s Components, Classes, Interfaces, Packages, Artifacts and Ports. They can be connected by Dependency, Interface Realization, Component Realization, Usage, Generalization or a generic Connector. Below, you can see an example of a simple Component Diagram consisting of Components connected by Dependencies.

ComponentDiagram

Using the properties dialogue, you can identify extensions such as Stereotype, Constraints and Tagged values:

Relation to other templates: The Component Diagram is part of the Application domain and shows how a system is structured. To model how users interact with a system you should use a Use Case Diagram, to model how interactions with the system through processes you should use the Sequence Diagram template. To model the structure of an application landscape you should use the Application Architecture Diagram.

Properties and metadata: The Component 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 Component Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.