ARIS Standards and Conventions Manual

57 Pages·2014·1.83 MB·English

CSU Enterprise Workflow Project (EWP) Phase 1

ARIS Standards and Conventions Manual

Date: 23 June 2014
Version: 1.0

Software AG
ARIS Modelling Standards and Conventions Manual 17 June 2014

Document Control

Document History
Date Version Authors Comments/Description of Change
10-Jun-2014 0.1 Luke Audie Initial Version for Client review
13-Jun-2014 0.2 Luke Audie Changes incorporating review comments
17-Jun-2014 0.3 Luke Audie Further Changes based on discussions with CSU
23-Jun-2014 0.4 Luke Audie Further Changes based on CSU feedback received
23-Jun-2014 1.0 Bruce Crawford V1.0 release based on approval of V0.4 draft.

Reviewers
Organization Role Name Review Date
Software AG Project Manager Raviprasad S Cadambi 06-Jun-2014
Project Manager and BPM
CSU – IT Team Bruce Crawford 19/06/2014
Lead
CSU – Business Business Analyst Sophie Dewar 19/06/2014
CSU – IT Team Business Analyst Marian Wolmarans 19/06/2014
CSU – IT Team System Administrator Scott Barlow 19/06/2014

Approvers
Organization Role Name Date
Director, Enterprise
CSU – IT Team Diane Ireland 25/06/2014
Architecture
Geoff Honey
CSU – Steering
Project Sponsor (Executive Director, Division of N/A
Committee
Student Administration)

©2014 Software AG. All rights reserved. Page 2 of 57
ARIS Modelling Standards and Conventions Manual 17 June 2014

Table of Contents

1.0 Introduction 7
1.1 Purpose 7
1.2 Intended Audience 7
1.3 Background 7
1.4 Conventions Definition 7
1.5 Why Adopt a Common Approach to Conventions? 8
1 ARIS Overview 9
1.6 ARIS Methodology 9
1.7 ARIS Framework / Views 9
2 ARIS Database Framework 10
1.8 Database Naming Conventions 10
1.9 Database Folder Structure 11
1.10 Artefact Libraries 12
1.11 Definition and Occurrence Objects 12
1.12 User Access and Authorisation 13
2 ARIS Modelling Design Standards 16
2.1 Filter 16
2.2 Template 17
2.3 Basic ARIS Client settings 18
3 ARIS Governance 19
3.1 Content Release Cycle Management 19
3.2 Modelling Governance Process 20
3.2.1 Change Request and Assessment 20
3.2.2 Model Design 21
3.2.3 Audit Trail 21
4 Model-to-Execute 22
5 CSU Enterprise Framework 23
5.1 Navigation / Entry Models 23
5.1.1 CSU Entry Model 23
5.1.2 Project Entry Model 24
5.2 Organisational Modelling 25
5.3 Process Modelling 26
5.3.1 Value-added Chain Diagram (Level 1 and 2) 27
©2014 Software AG. All rights reserved. Page 3 of 57
ARIS Modelling Standards and Conventions Manual 17 June 2014

5.3.2 BPMN Collaboration Diagram (Levels 3 – 5) 28
5.3.3 Function Allocation Diagram (Supporting all levels) 30
5.4 Information Modelling 33
5.4.1 Level 1 - IE Data Model (Business Objects) 33
5.4.2 Level 2 - IE Data Model (Entities) 34
5.4.3 Level 3 - eERM Attribute Allocation Diagram (Attributes) 34
5.5 Application Modelling 36
5.5.1 Application Domain Model 36
5.5.2 Application Communication Model / Interfaces 37
5.5.3 Application Screens 39
5.5.4 Report Catalogue 42
5.6 Project Requirements Modelling 43
5.7 Capability and Service Modelling 43
5.7.1 Business Capability Model 43
5.7.2 Business Service Model 44
5.8 Common Attributes 48
5.8.1 Common Model Attributes 48
5.8.2 Common Object Attributes 49
3 Modelling Standards 50
5.9 General Modelling Guidelines 50
5.10 BPMN Modelling Guidelines 51
5.11 Model and Object Naming 51
5.12 Model Naming 51
4 ARIS Reports and Macros 54
5.13 Standard Reports and Macros 54
5.14 Custom Reports and Macros 55
5.15 ARIS Competency Centre (Proposed Future State) 56
5 Glossary 57

©2014 Software AG. All rights reserved. Page 4 of 57
ARIS Modelling Standards and Conventions Manual 17 June 2014

Table of Figures

Figure 1: CSU Process Hierarchy 9
Figure 2: ARIS House representing the Views of an Organisation 9
Figure 3: CSU Enterprise Repository Folder Structure 11
Figure 4: Example Library Folder Structure 12
Figure 5: Occurrence Copy Illustration 13
Figure 6: ARIS Identifiers 13
Figure 7: Example Folder Permissions 14
Figure 8: User Groups Defined in Central User Management 15
Figure 9: Example Attributes Maintained in Standards DB 16
Figure 10: Steps to Update CSU Filter 16
Figure 11: CSU Modelling Template 17
Figure 12: CSU Header Model Location 17
Figure 13: CSU Header 17
Figure 14: Model Status List 19
Figure 15: Object Status List 19
Figure 16: Model Design Governance Process 20
Figure 17: Change Request and Assessment Process 20
Figure 18: Governance Process for Controlling Modelling Activities 21
Figure 19: Changes Stored in Model Attributes 21
Figure 20: Documenting Process Design 21
Figure 21: Model-to-Execute Lifecycle 22
Figure 22: CSU Entry Model 23
Figure 23: Example Organisation Chart 25
Figure 24: CSU Process Hierarchy 26
Figure 25: Example Level 1 Enterprise Map Diagram 27
Figure 26: Example Level 2 Main Process Diagram 27
Figure 27: Example Level 3 BPMN Diagram 28
Figure 28: Example Level 4 / 5 BPMN Diagram 28
Figure 29: BPMN Connection Attributes 30
Figure 30: Example Level 2 – 4 Process FAD 31
Figure 31: Example Manual Task FAD Diagram 31
©2014 Software AG. All rights reserved. Page 5 of 57
ARIS Modelling Standards and Conventions Manual 17 June 2014

Figure 32: Example Automated Task FAD Diagram 31
Figure 33: Example User Task FAD Diagram 32
Figure 34: Example Level 1 - IE Data Model (Business Objects) Diagram 33
Figure 35: Example Level 2 - IE Data Model (Entities) Diagram 34
Figure 36: Level 3 – Example eERM Attribute Allocation Diagram (Attributes) 35
Figure 37: Example Level 1 - Application Domains Diagram 36
Figure 38: Level 2 - Example Application Modules Diagram 37
Figure 39: Example Level 1 - Overall Interface Diagram 38
Figure 40: Example Level 2 - Interface Description Diagram 38
Figure 41: Example Level 1 - Screen Catalogue Diagram 39
Figure 42: Example Level 2 - Screen Design Diagram 40
Figure 43: Example Level 2 - Screen Diagram 41
Figure 44: Example Report Catalogue Diagram 42
Figure 45: Example Project Requirements Diagram 43
Figure 46: Example Business Capability Model 44
Figure 47: Example Level 1 - Enterprise Business Service Map 44
Figure 48: Example Level 2 – Business Service Allocation 45
Figure 49: Example Level 1 - Enterprise Software Service Map 46
Figure 50: Example Level 2 – Software Service Allocation 47
Figure 51: Hiding ARIS Reports 54
Figure 52: ARIS Competency Centre 56

©2014 Software AG. All rights reserved. Page 6 of 57
ARIS Modelling Standards and Conventions Manual 17 June 2014

1.0 Introduction
1.1 Purpose
This manual is designed to provide guidance in the use of conventions for creating and describing CSU’s
Enterprise Model including; process, application, technology, information, service, organisational and
requirement models using the ARIS toolset and assumes the audience has had prior training before reading this
manual. The reader will note that process design is emphasised in this manual, but the solution also provides
an approach and methodology for enterprise architecture management, work flow, and application processing.

1.2 Intended Audience
This guide is intended as a key reference for those using the ARIS tool-set to support the review, modelling,
analysis, design and in general, improvement of content, within the ARIS Enterprise Repository, as part of
defined projects or discrete assignments. It is also intended for those specifically involved in developing and
maintaining defined architectural models. In the main it is expected that the primary users of this manual will
include:
 Business Analysts
 Process Owners
 Solution Architects / Process Engineers
 Process Developers
 Enterprise Architects

1.3 Background
The ARIS Enterprise Repository will provide an abstract view of the complex structures of the organisational
processes and enterprise architectures. The diagrams within the repository are used to document, analyse,
and communicate the state of how the organisation operates and the associated consumed resources. This
requires a standard way of capturing the state of information in a manner that will enable different viewers of
the diagrams to interpret it in the same way with minimal variations.

For this reason, ARIS mapping conventions define the allowed elements and their meaning. Following
prescribed modelling conventions will allow for efficient, collaborative business process and enterprise
architect management across CSU’s boundaries and disciplines.

1.4 Conventions Definition
Conventions are a collection of elements, protocols and rules, which when applied consistently, result in a set
of process and associated diagrams and documents constructed in a logical and standardised way. Business
diagrams inform the user and the viewer about the contents and value of each document, and the usage of the
document in a concise manner. Conventions assist users to achieve an efficient use and reuse of information
while maximising understanding of information both within and outside each organisational unit.

©2014 Software AG. All rights reserved. Page 7 of 57
ARIS Modelling Standards and Conventions Manual 17 June 2014

1.5 Why Adopt a Common Approach to Conventions?
A variety of conventions are used for enterprise modelling. However, these are generally used in a non-
uniform manner and are subject to wide interpretation. A shared understanding of the organisation will be
developed through the use of a common language for depicting and describing processes.

As CSU organisational users become more familiar with how their organisational information and processes are
modelled using a standard modelling notation (conventions), they will become better at articulating their
knowledge. Not only will well described enterprise documentation greatly assist in identifying opportunities to
business improvement, they also develop a shared understanding of processes and their performance.

CSU organisation units applying conventions to enterprise documentation will be provided with consistent,
logical models and will be able to distinguish similar documents and process diagrams from one another at a
glance. In addition, applying conventions will also facilitate the storage and retrieval of documents, which will
enable users to browse files more effectively and efficiently. Documents created according to agreed
conventions should also make file naming easier for users because they will not have to “reinvent” the process
each time, as reusable process content may already exist.

The effective use of conventions ensures and promotes the flow of information across Divisional boundaries
within CSU. Additionally, common use of conventions can improve the following:

 Enterprise Architecture • Compliance and Risk Management
 Process Improvement • Knowledge Management and Training
 Process Cost Analysis • Increased productivity
 Workflow and Document Management • Process Simulation
©2014 Software AG. All rights reserved. Page 8 of 57
ARIS Modelling Standards and Conventions Manual 17 June 2014

1 ARIS Overview
1.6 ARIS Methodology
The ARchitecture of Integrated Information Systems (ARIS) is a framework not only as a business process
modelling tool but as a concept to support the:

 Documentation of business processes in a
structured, integrated manner that supports the
L1Model
design, analysis, optimization and Enterprise Map L2Object EWP Enterprise Map
implementation of business processes
 Documentation of the Enterprise Architecture L2Model
Main Process L3Object Student Administration
 Ease the collaboration on design of new CSU
capabilities
L3Model
Business Process Admissions Processing
L4Object
 Quickly build out solutions without costly and
time-intensive development
L4Model Assess Admission Eligibility
 Automation of business process document Sub-Process L5Object and Credit
generation:
o As a single point repository for business Task Diagram L5Model Perform Initial Eligibility
L6Object Assessment
process document artefacts for

consistency and document control Figure 1: CSU Process Hierarchy
o Reducing time and cost to create documents manually by generating pre-developed documents
from ARIS content, generating new Business and/or Enterprise opportunity Blueprints, Role
based authorisation, etc.

1.7 ARIS Framework / Views
ARIS is a framework of methods for modelling CSU’s architectures and
content. The basic concept behind ARIS is to break down the
organisation into different views for the purpose of reducing
complexity. The organisation can thus be viewed from:

 Organisation: Organisational structure; Balanced Scorecards
 Process/Control: Business processes
 Data: Data structures; Risks Overview; Business terminology
 Functions: Overview and structure of application systems
Figure 2: ARIS House representing
 Product / Service: Product and/or Service portfolio the Views of an Organisation

The advantage of setting up views in ARIS is its great clarity in presenting complex facts, but it also allows a
systematic approach to analysis. Depending on the information of interest, different modelling methods are
used which serve to describe the views presented.
©2014 Software AG. All rights reserved. Page 9 of 57
ARIS Modelling Standards and Conventions Manual 17 June 2014

2 ARIS Database Framework
1.8 Database Naming Conventions
The CSU ARIS Modelling Conventions and Methodology relating to the ARIS Database framework, administration,
have been implemented as part of the CSU Standards creation.

Currently, one central ARIS Database for CSU Standards is created to design, test and store all CSU Standards
Business Processes. For each release, a copy of this database will be released based on agreed Release Cycle
Management standards (see chapter on Release Cycle Management for further details).

The following database naming convention has been defined for the primary CSU enterprise database:

[Company] [Purpose] [Version No.] [WIP / REL / Prod]
Examples: CSU Enterprise Repository V1.0 WIP
CSU Standards and Conventions V1.0 REL
Item Description
Company Self-explanatory
Purpose For example, “Enterprise Repository” or “Standards and Conventions”
Release Status WIP – Work in Progress
REL – Released for build
Prod – production – post build, deployment and publication

The CSU Enterprise Repository database will be a multi-project Work in Progress (WIP) environment. Each CSU
project will have a separate folder to store their enterprise content. The folder naming should be brief yet
specific, generally understandable and should reflect the content stored within. This rule applies especially for
business process folder names which have to have the same name as the process model it contains. Therefore
only one business process model can be stored in a folder.

Important: A requirement for Model-to-Execute is that all databases need to be versionable.
©2014 Software AG. All rights reserved. Page 10 of 57