Solution Architects | QualiWare Center of Excellence

Lifecycle Assessment Diagram

Purpose: The purpose of the Life Cycle Assessment Diagram template is to document the relations for an activity or product in a lifecycle context.

Core concerns: The Lifecycle Assessment Diagram concerns itself with modelling elements in a company that interact with the environment. The template enables you to model Environmental Aspects and Objectives for Activities in your organization. This template allows you to model Business Objects, Activities, Performance Indicators, Business Connection, Goals, Policies, Critical Success Factors, Change Requests and Problems. These elements can be grouped into Categories and connected by Impact Quantity, Recycling, Logistical Flows, Information Flows, and Activity Paths.

Below, you can see an example of a Lifecycle Assessment Diagram for a Product, from production to packaging, focusing on reducing unbiodegradable waste:

The elements used in this example are Business Objects as input and output, Activities showing Logistical Flows and Recycle under Process. Under the Environment Category, Environmental Aspects, Impact and Objectives are identified and Policies for reaching the Objectives are also included. The diagram focus on a single Environmental impact: Waste. You can also choose to map out several Environmental impacts that are relevant to a specific activity or product.

Relation to other templates: The Environmental Aspects and Impacts from the Lifecycle Assessment Diagram can be further explored in the Environmental Impact Diagram. The Lifecycle Assessment Diagram is also related to the Business Process Diagram and Workflow Diagram, in the sense that they all are related to detailing aspects of processes. The Lifecycle Assessment Diagram can also be decomposed from the Inventory object shown in, for example, the Production Site template.

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

For more information: You can learn more about Lifecycle Assessment on the US Sustainable Facilities Tool website or turn to ISO standard 14040.

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.

Infrastructure Diagram

Purpose: The purpose of the Infrastructure Diagram template is to document the physical infrastructure of the enterprise, which includes but is not limited to databases, wires, firewalls, computers etc.

Core concerns: The Infrastructure Diagram enables you to model your organizations infrastructure including: Computer Categories, Computers, Firewalls, Printers, Networks, Connection Points, Peripherals, Locations, Information Systems, System Components, Databases, Network Connections, Object Dependencies, Technology Domains, Technology Capabilities and Technology Components.

The models below exemplify how you would construct this type of diagram:

Relation to other templates: The Infrastructure Diagram template should not be used to document logical architecture, as the connections available in an Infrastructure Diagram are predominately geared towards documenting physical information about IT infrastructure. The Infrastructure Diagram can through its components be linked to other architectural diagrams such as the Application Architecture Diagram, and the data they contain. This way, if a firewall is breached, you would be able to very quickly identify what data has been vulnerable.

Properties and metadata: The Infrastructure 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 Infrastructure Diagram, 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:

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

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 Model Diagram

Purpose: The Purpose of the Data Model Diagram template is to model the structure of data entities of an Information System and their relationships. Documenting the structure of information is a very important part of the preliminary analysis before implementing any Information System.

Core concerns: The Data Model Diagram template enables the user to document the structure of the information, that an Information System is supposed to store. The template allows you to model using Data Entities, Subject Area, Data Entity View, Model View and inheritance. The Connection types available are: Data Relation, Inheritance Connection, Complex Relation and Generalization. Below you can see an example of a Data Model Diagram describing the information structure related to an order:

Relation to other templates: The Data Model Diagram template should not be used to document data flows. In that case the Data Flow Diagram template should be used.

Properties and metadata: The Data Model 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.

The above picture shows the properties dialogue window for the Data Model Diagram where you can view and edit the diagram’s properties.

Data Flow Diagram

Purpose: The purpose of the Data Flow Diagram is to document a system’s or part of a system’s data flows; the data input the system (or a process within the system) consumes and the data output the system produces.

Core concerns: The Data Flow Diagram enables you to model Processes, Data Stores, External Entities, Control Processes and Control Stores. These elements can then be connected by either Data Flows or Control Flows.

Graphical representation of the elements:

The Data Flow Diagram can show different levels of processes within a system that exchange data, and illustrate how those exchanges occur. As such, the model can document a system’s functional hierarchies.

Below, you can see an example of a Data Flow Diagram showing the Data Flows between several Data Stores, Processes and External Entities in a Bookshop:

The next example shows the Data Flow between process, Data Stores and External Entities for a Highway Repair Service:

The final example shows the Data Flows between Processes, Datastores and External Entities in an Outlook Mailbox:

Relation to other templates: The Processes in the Data Flow Diagram can be decomposed into more detailed Data Flow Diagrams to comprise the total functional model. The top level of a Data Flow Diagram is sometimes called a Context Diagram. However, in QLM we use the Data Flow Diagram template for the higher levels as well as the more detailed ones.

The Data Flow Diagram can be a decomposition of an Information System. It can offer a more detailed view of Data Flows than, for example, the Application Architecture Diagram.

An Information System could likewise be decomposed into a Business Process Diagram which offers a complimentary view less concerned with Data Stores and Data Flow, and more concerned with Activity Flow.

Properties and metadata: The Data Flow Diagram template 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 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 Flow Diagram template, 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:

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.

Customer Journey Map

Purpose: The Purpose of the Customer Journey Map template is to document the customer’s journey from awareness to the end of their interaction with an organization, covering possible touch points from the customer’s perspective.

Core Concerns: The Customer Journey Map template allows you to model connections between different Personas, Customer Journey Phases, Touch Points, Goals, Roles, Locations, Channels, Technology and the aspects from a SWOT analysis.

You can choose to model both a current state and a desired future state of the customer journey and use the documentation for process improvement. Below is an example of a current state model and a future state model:

Current state model:

Desired future model:

Other functionalities: The customer’s touchpoints can be elaborated upon with four scores for Customer Satisfaction, Customer Importance, Customer Effort and Net Promoter Score. Particularly vital touchpoints can be designated as a Moment of Truth.

Relation to other templates: The Customer Journey Map can be used as a groundwork for a strategic change, which for example can be modelled in a Work Model, a Business Capability Model and/or a Strategy Model.

Properties and metadata: The Customer Journey Map 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.

The above picture shows the properties dialogue window for the Customer Journey Map, where you can view and edit the diagram’s properties.

For more information: on Customer Journey Mapping, please view our webinar Experience Mapping – Customer Obsession for IT and Digital Professionals with Milan Guenther and Katharina Weber.

CPM Diagram

Purpose: The Purpose of the Critical Path Method Diagram (CPM Diagram) is to reveal the critical path through a project, i.e. the list of activities that needs special attention since a delay in these activities will delay the whole project.

Core concerns: The CPM Diagram enables you to model Project Activities and connect them with Activity Paths. The Project Activities are then enriched with information about latest and earliest dates for start and finish as well as information about duration and slack for each Project Activity.

This makes it possible to calculate the probability of finishing the project within the planned timeframe, and to successively improve and detail the plan.

Below, you can see an example of a CPM Diagram about how to develop an organization to support a strategic change. It concerns the incoming and outgoing flow of employees as well as their training across several locations:

As you can see, the critical path is marked with red.

The following example is of a technology roadmap, where the critical path shows the three most critical project activities for on-time completion:

Other functionalities: A Calendar can be linked to the Property Dialog of the diagram showing holidays for the project.

Relation to other templates: The CPM Diagram template should be used after a project has been broken down into Project Activities. As such, it can be a decomposition of a Project Activity from a Business Canvas, Value Proposition, Work Model, Strategy Model or Innovation Canvas.

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

A description of the diagram
Link to owner
Link to responsible
Link to calendar
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 CPM diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Control Coverage Map

Purpose: The purpose of the Control Coverage Map is to provide an overview of uncovered risks, residual risks and potential cost of the risk occurring.

Core concerns: The Control Coverage Map concerns itself with Financial Risk Management and is created using the Actions tabs in QLM. It can be created based on the information in a Risk Heatmap or by using information from a diagram which contains risks that also have control actions.

Below, you can see an example of a Control Coverage map for four risks related to a Bellhouse, a Pump, a Suction pipe and using Check lists:

The Blue column represents the likelihood of the risk before the control action, the green column represents the likelihood of the risk after the implementation of a control action. The red columns represent the estimated cost if the risk is realized.

Relation to other templates: The Control Coverage Map presents graphical views of information from other diagrams the same as the Heatmap, Business Charts and the Graphical Matrix. It can be used by any diagram containing Activities with attached risks that have control activities.

Properties and metadata: The Control Coverage Map can for example retain the following information:

A description
Link to the owner
Link to the one responsible
Graphical specification for the headers of the X-axis and Y-axis
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 Control Coverage Map

The above picture shows the properties dialogue window for the Control Coverage Map template where you can view and edit the template’s properties in QualiWare Lifecycle Manager.