Process | QualiWare Center of Excellence

Data Object

Data Objects provide information about what Activities require to be performed and/or what they produce, Data Objects can represent a singular object or a collection of objects. Data Input and Data Output provide the same information for Processes.

In BPMN, a Data Object is considered an Artifact and not a Flow Object. They are considered an Artifact because they do not have any direct effect on the Sequence Flow or Message Flow of the Process, but they do provide information about what the Process does. That is, how documents, data, and other objects are used and updated during the Process. While the name Data Object may imply an electronic document, they can be used to represent many different types of objects, both electronic and physical.

In general, BPMN will not standardize many modeling Artifacts. These will mainly be up to modelers and modeling tool vendors to create for their own purposes. However, equivalents of the BPMN Data Object are used by Document Management oriented workflow systems and many other process modeling methodologies. Thus, this object is used enough that it is important to standardize its shape and behavior.
As an Artifact, Data Objects generally will be associated with Flow Objects. An Association will be used to make the connection between the Data Object and the Flow Object. This means that the behavior of the Process can be modeled without Data Objects for modelers who want to reduce clutter. The same Process can be modeled with Data Objects for modelers who want to include more information without changing the basic behavior of the Process.
In other cases, the same Data Object will be shown as being an input, then an output of a Process. Directionality added to the Association will show whether the Data Object is an input or an output. Also, the state attribute of the Data Object can change to show the impact of the Process on the Data Object.

State is an optional attribute that indicates the impact the Process has had on the Data Object. Multiple Data Objects with the same name MAY share the same state within one Process. Examples of state could be: initiated, logged, registered.

The Uses Parameter field can be used to define specific parameters, values, or conditions that must exist to permit the DataObject to be created or used as input to a process/activity.

The Required for Start checkbox in QualiWare can specify whether or not the DataObject MUST exist for the Activity to start.

The Produced at Completion checkbox can be checked if the DataObject is output of an Activity and produced at the completion of the work associated with the Activity.

Work Model

Purpose: The purpose of the Work Model template is to document development methods or project models.

Core concerns: The Work Model template enables you to model Project Activities, Milestones, Results, Quality Controls, Document Structures and Business Scopes. These objects are joined by Connections indicating a flow.

The Work Model template can, for example, be used by Enterprise Architects to document the Enterprise Architecture process from start to finish while covering all the project activities, milestones, and results. The Work Model helps ensure a standardized approach.

Below, you can see a few examples of Work Models utilizing a variety of the available objects:

The above model shows a simple project flow enriched with mile stones, results and a quality control.

The above model illustrates another generic model for a software development project – this example has more milestones inserted as well as added document structures containing project deliverable templates.

Relation to other templates: The Work Model template should be used to document project activities – to document business processes and workflows should be documented in Business Process Networks, Workflow Diagrams or Business Process Diagrams.

For a more detailed view of the structure of a project’s results and resources, a Work Breakdown Structure template should be used.

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

Workflow Diagram

Purpose: The purpose of the Workflow Diagram template is to document the Business Processes of an enterprise at the activity level.

Concerns: The Workflow Diagram template should be used to document the Activities, Roles, Business Events, Activity Paths and Workflow Conditions of a Business Process. Available in the default modeling syntax are also Business Objects, External Objects, Information Systems, Database, Inventory, Information Flow and Logistical Flow. The syntax can be easily extended to include more objects such as Requirements, Business Rules and Goals. Below you can see an example of a Workflow Diagram with multiple Roles that are modelled vertically:

Relation to other templates: The Workflow Diagram does not support BPMN, if using that notation, you should model in the Business Process Diagram template. The Workflow Diagram can link to other Workflow Diagrams and are typically linked to by Business Process Networks. In the picture below, you can see another example of a Workflow Diagram. Here the Roles are modelled horizontally and you can see the links to and from other diagrams at two Business Events (‘ECR completed’ and ‘Rework’):

Other functionalities: In QLM, you can control which buttons related to risk management are shown below activities. You can choose to hide or show Risks, Controls and Key Controls. Both Controls and Key Controls are a type of Activity. From the Risk related toolbars (available via the “Actions” tab on the right-hand side of the Canvas in QLM) choose the following button to control what button panels appear on the Activity objects:

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

A description of the diagram
Information on cost and duration of the process
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 Workflow Diagram’s properties dialogue window, where the diagram’s properties can be viewed and edited:

Business Process Network

Purpose: The purpose of the Business Process Network is to at document a mid- to high-level view of Business Processes and their interrelationships.

Core concerns: The Business Process Network template enables the documentation of top to mid-level processes. The core objects available to model with are Business Processes, Business Events, Business Objects, Business Scope, Information Systems, and different types of connections. Below you can see two examples of a Business Process Network modelled in different styles.

High level process view without business events or connections between processes:

High-level process view where business events and connections indicate a flow between processes, stakeholders and customers:

Relation to other templates: The top-level processes would typically be broken down to one or more levels of mid-level processes. The last level of Business Process Networks can then be broken down to several Workflow Diagrams or Business Process Diagrams detailing the activities contained within the business process

Properties and metadata: The Business Process Network can for example retain the following information:

Description of the diagram
Link to the owner of the diagram
Link to the one responsible for executing the processes in 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

In the picture below you can see the Business Process Network’s properties dialogue window, where the diagrams properties can be viewed and edited:

Business Process Diagram

Purpose: The purpose of the Business Process Diagram template is to enable workflow modelling using the industry standard BPMN (Business Process Modeling Notation).

Core concerns: The Business Process Diagram template supply you with the BPMN icons that enable you to draw a workflow diagram. These icons include different types of events, activities, gateways, connectors, as well as pools, lanes and artifacts such as data objects and messages. The Business Process Diagram is typically used to illustrate business processes and software processes used in requirement documentation. Below is an example of a classic BPMN diagram with swimlanes:

To ensure the right BPMN syntax, the Business Process Diagram template will continuously perform Graphic Syntax Checks while you model. When a graphic syntax error occurs, you will be met with an error message like the one shown below:

Other functionalities: The Business Process Diagram can enable the execution and automation of a process when the diagram is converted into XML type files.

If you don’t wish to have a visible pool in your diagram, you can choose to have a ‘default pool’ that doesn’t have to be graphically represented. You can see an example of a diagram without pool and lanes below:

Relation to other templates: The Business Process Diagram template is exclusively aimed at modeling using the BPMN standard. If the BPMN is not chosen as a mandatory standard, the WorkFlow Diagram template, which has fewer syntax limitations, can be used instead.

The Business Process Diagram is typically linked as a decomposition of a Business Process contained in a Business Process Network template.

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

Description of the diagram
Expression and query language
Link to the owner of the process
Link to the one responsible for executing the process
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

In the picture above you can see the Business Process Diagram’s properties dialogue window, where the diagram’s properties can be viewed and edited:

For more information: about the BPMN standard please visit OMG’s dedicated website.

Business Diagram

Purpose: The purpose of a Business Diagram is to show the functional structure and relationships of the whole or part of an organization.

Core concerns: The Business Diagram template enables you to model Business Functions, Information Systems, Inventory, Business Scope, Lines of Business, Information Flow and Logistical Flow. The diagram’s syntax can be extended to also include strategic elements such as Goals, Objectives, Stakeholders and Performance Indicators.

The Business Diagram should be broken down into several levels of recurring Business Diagram templates. In the model below, you can see an example of a high-level Business Diagram showing Business Functions and their Information Flows and Logistical Flows – describing the flow of products and services – in this case for a car rental service.

The Business Functions are placed with the operational functions in the bottom together with the Logistical Flow and with management control at the top of the Business Diagram.

On lower levels (decompositions) of Business Diagrams, Information Systems are placed close to the Business Functions that are responsible for or own the Information Systems.

Relation to other templates: The Business Diagram can be used as an addition to a Business Process Network and Strategy Models, giving a practical view of how the organizations functions fit together, illuminating interdependencies.

Properties and metadata: The Business 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
Indication of the diagram portrays an as-is situation or a to-be situation
The Perspective can be defined as either: Holistic, Sub-functional, Process, or IT Focused.
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 Business Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Stakeholder Viewpoint : Archimate

Concerns: Architecture mission and strategy, motivation
Purpose: Designing, deciding, informing
Scope: Motivation

The stakeholder viewpoint allows the analyst to model the stakeholders, the internal and external drivers for change, and the assessments (in terms of strengths, weaknesses, opportunities, and threats) of these drivers. Also, the links to the initial (high-level) goals that address these concerns and assessments may be described. These goals form the basis for the requirements engineering process, including goal refinement, contribution and conflict analysis, and the derivation of requirements that realize the goals.

Goal Realization Viewpoint: Archimate

Concerns: Architecture mission, strategy and tactics, motivation
Purpose: Designing, deciding
Scope: Motivation

The goal realization viewpoint allows a designer to model the refinement of (high-level) goals into more tangible goals, and the refinement of tangible goals into requirements or constraints that describe the properties that are needed to realize the goals. The refinement of goals into sub-goals is modeled using the aggregation relationship. The refinement of goals into requirements is modeled using the realization relationship.

In addition, the principles may be modeled that guide the refinement of goals into requirements.

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.