CSU ARIS Modelling Standards and Conventions Manual V1 0

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
CSU IT Team
Project Manager and BPM

Lead
Bruce Crawford
19/06/2014
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
Organization
Role
Name
Date
CSU IT Team
Director, Enterprise
Architecture
Diane Ireland
25/06/2014
CSU Steering
Committee
Project Sponsor
Geoff Honey
(Executive Director, Division of
Student Administration)
N/A
Approvers
2014 Software AG. All rights reserved.
Page 2 of 57
17 June 2014
Table of Contents
1.0 Introduction
1.1
Purpose
1.2
Intended Audience
1.3
Background
1.4
Conventions Definition
1.5
Why Adopt a Common Approach to Conventions?
ARIS Overview
1.6
ARIS Methodology
1.7
ARIS Framework / Views
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
ARIS Modelling Design Standards
16
2.1
Filter
16
2.2
Template
17
2.3
Basic ARIS Client settings
18
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
Model-to-Execute
22
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
Page 3 of 57
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
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
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
Glossary
57
Page 4 of 57
17 June 2014
Table of Figures
Figure 1: CSU Process Hierarchy
Figure 2: ARIS House representing the Views of an Organisation
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
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
Page 5 of 57
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
Page 6 of 57
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 CSUs
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 CSUs 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.
Page 7 of 57
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 nonuniform 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
Page 8 of 57
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
design, analysis, optimization and
implementation of business processes
Documentation of the Enterprise Architecture
Ease the collaboration on design of new CSU

capabilities
Quickly build out solutions without costly and

time-intensive development
Automation of business process document

generation:
o
As a single point repository for business

process document artefacts for
consistency and document control
Enterprise Map
L1 Model
L2 Object
EWP Enterprise Map
Main Process
L2 Model
L3 Object
Student Administration
Business Process
L3 Model
L4 Object
Admissions Processing
Sub-Process
L4 Model
L5 Object
Assess Admission Eligibility

and Credit
Task Diagram
L5 Model
L6 Object
Perform Initial Eligibility

Assessment
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 CSUs 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
Product / Service: Product and/or Service portfolio
Figure 2: ARIS House representing

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.
Page 9 of 57
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.
Page 10 of 57
17 June 2014
1.9 Database Folder Structure

To support the categorisation of content and navigation through the database, there needs to be a consistent
folder structure. In general the folder structure consists of seven high-level areas:
Folder / Area
Purpose
A. Library
Stores all the artefact library objects, e.g. data, roles, systems. The ARIS
support team is responsible for managing these libraries in conjunction with
the respective library owner (HR roles and positions)
B. Enterprise Model
Hold all enterprise level framework models
C. Projects
Contains all project framework models (during the project phase and then
these models may be migrated to the Enterprise Model.
D. Governance
Stores all governance processes (e.g. RCM and CRM) and ITIL support processes
for the EA Competency Centre
E. Testing
Holds all the process-driven business scenarios and test cases created for
projects
F. Training and
Documentation
Store all the help guides and training collateral for the ARIS solution as well as
to support the CM activities within projects
X. Technical Content
ARIS administrator, data import, meta-model and configuration, sandpit
Artifact Libraries
Governance
framework models
Enterprise level
framework folders
and models
Training, CM and
general
documentation
folder
Each project has

its own parent
folder which
includes the
various
frameworks
Folder to store
temporary testing
related models
Stores
configuration as
well as
Technical area for
performing onceoff tasks
Figure 3: CSU Enterprise Repository Folder Structure
Folder structure guiding principles to help maintain a clean working database:

Page 11 of 57
17 June 2014
One model per folder where possible (especially for process models)
Folders can contain n. number of child folders
Modellers should create content within the correct Architecture (e.g. processes should be placed under
01. Process)
1.10 Artefact Libraries

For the purpose of consistency, re-use of content, easier maintenance and content governance, artefacts (i.e.
ARIS objects) are collected in libraries. The CSU Library folder is created to store models and objects which are
managed and maintained centrally through a governance process and
includes:
Process objects (high-level value-added chains)
Information Assets/Data
Organisational Objects (such as Organisation Units, Positions,

Task Roles, Locations)
Technology / Application / Screen Objects
Business and Software Services
Requirements
Figure 4: Example Library

Folder Structure
Suggested: Create library folders based on object symbol names.

Note: Artefact library folders will be updated as part of enhancement / enrichment process by the ARIS
support team.
1.11 Definition and Occurrence Objects

The definition of every library object is stored in the library folder whereas the occurrence copy of this object
is used in different models by the modellers. This approach assures that only the owner of the object
(framework area) has change rights to the definition object and that the user can analyse the distribution of
the used objects in the database. Changes to the occurrences can only be executed by changing the definition
object.
It is important to note that if new library objects are identified in a specific architecture, for example roles in
Function Allocation Diagrams, occurrences will also need to be manually modelled in various other architecture
model types (e.g. organisation chart) and library models. ARIS does not automatically create occurrences or
maintain artefact libraries.
Page 12 of 57
17 June 2014
Figure 5: Occurrence Copy Illustration
1.12 User Access and Authorisation

The access privileges to content within the ARIS database are distributed according to the project roles and
responsibilities. Only the ARIS Administrators (system user) have the complete set of privileges.
Assign Identifier ID
Identifiers are assigned to users/user groups so that the models/objects created can be identified by the user
group. This can be maintained in the Administration view on the respective database by right-clicking and
selecting properties.
Example:
CSU All CSU users
CC Specific ARIS Competency Centre users ( If planned in future)
CFG Administrator User of Configuration Database
EXT External users (just for e.g.)
Multiple Identifiers can also be created for various groups associated in the database. In current environment
at CSU we have used Standard Identifier denoted as STD.
Figure 6: ARIS Identifiers

Page 13 of 57
17 June 2014
In addition, the direct assignment of the identifier (activate checkbox) is set during user and user group
maintenance.
User Access Control

In the multi tenancy CSU ARIS database, user access is controlled and only authorised users will have access to
the specific content folders they are assigned to.
For example BPM project members will have read/write access to their modelling folders in the project
workspace and read access to the global object libraries. Only framework content owners will have
permissions to change content in the global object libraries.
Figure 7: Example Folder Permissions
Access Attributes
Certain folders are specified with read, write and delete privileges for every user/ user group. Those privileges
can be maintained as followed:
No access (----): Users can see the group structure of the database. Group contents are not displayed.
Read (r---): The group content is displayed. Users can open models but cannot change models and
objects, nor add or delete new items.
Read + write (rw--): The group content is displayed. Users can change models and objects, add new
items, delete object occurrences from models, but not object definitions.
Read + write + delete (rwd-): The user can modify models and objects and add and delete items.
Read + write + delete + version (rwdv-): The user can modify models and objects and add and delete
and version items.
The privileges can be inherited from a parent folder to its subfolders via the user access properties by passing
them on to related folders.
Page 14 of 57
17 June 2014
CSU User Groups

To assist in the management of multiple users, there is the possibility to define user groups and assign access
and permissions at this higher level instead (group permissions automatically cascade down to all associated
members).
Currently the following User groups have been defined.
Figure 8: User Groups Defined in Central User Management

Group
Description
Arisservice
Required for Model-to-Execute. Requires rwdv to all folders and needs the
Entire method and wM integration filters assigned.
Process developer
All webMethods Process developers need their ARIS user account assigned to
this group.
Process engineer
All process engineers who need to synchronize process models with

webMethods Designer need to be assigned to this group
CSU Admin
All ARIS support team members are assigned to this group, which has rwdv
access to all folders. This group has both the Entire method and CSU Filter
assigned.
CSU Project (e.g. EWP)
A group will be defined for each project. This group will only have the CSU
Filter assigned and rwdv access to models in their respective folders and the
sandpit area and read access to other allowed folders (e.g. Library and
Enterprise Model). Example permissions below:
CSU Publisher
This user group is specially used for anonymous access in ARIS Business
Publisher. It has read access to all general areas and allowed project models.
Page 15 of 57
17 June 2014
2 ARIS Modelling Design Standards

2.1 Filter
The CSU Filter contains all allowed model types, object types, relationship types, symbols with enabled
relationships, assignments, and attributes. It has been applied to the CSU Enterprise Repository Database
and enables modellers or users to model/view ARIS content according to the Standards and Conventions as
defined by CSU.
The CSU Filter should never be directly updated, but rather maintained through the CSU ARIS Standards and
Conventions V1.0 WIP database. For example, if an additional model attribute it required it should firstly be
maintained in the CSU ARIS Standards and Conventions V1.0 WIP database and then the filter updated using
the Create automatically (which analyses what was maintained in the standards DB) option.
Figure 9: Example Attributes Maintained in Standards DB
In Administration
3. Right-click
CSU Filter
and Edit
4. Select Filter
1. Select Create
Automatically
2. Select CSU
Standards DB.
And select
Overwrite
filter
contents
Figure 10: Steps to Update CSU Filter
Important: The Entire method must be used when updating the Standards and Conventions Database and
when synchronising processes with webMethods.
Page 16 of 57
17 June 2014
2.2 Template
In order to ensure a uniform appearance of the models the template CSU Modelling Template must be
applied to all models. This Design Template maintains the look and feel conventions defined for CSU e.g. font
sizes, object appearances, etc.
Figure 11: CSU Modelling Template
Another aspect the CSUs modelling styling is the model header which needs to be applied to every ARIS model.
A modeller can copy the header from any current model or from the master model which is located in the
following folder:
Figure 12: CSU Header Model Location
The model header shows a set of basic information which is relevant to identify, understand and analyse the
model itself.
The header shows the following attributes depending on the model type:
Model Name
Model Status
Last Change Date
Company Logo
Figure 13: CSU Header

Page 17 of 57
17 June 2014
2.3 Basic ARIS Client settings

The following layout settings have to be applied in every ARIS client to ensure a consistent look and feel of
models.
Grid Settings
Connections
Text attributes in symbols: Set to Multi-line text
Page 18 of 57
17 June 2014
3 ARIS Governance
3.1 Content Release Cycle Management
The Design Governance Process utilises a five-phase approach for managing the release cycle of ARIS content
and processes. The release cycle helps coordinate the modelling and QA teams with the business and
technologies owners. For example, process owners can search through the ARIS database looking for all content
flagged as Ready for sign-off and either approve or reject the proposed designs.
Below are the five phases of classification for ARIS models and objects. The phases are sequential and
mandatory (excl. Archived).
Seq.
Phase (Item Status)
Description
Design
New or work-in-progress items
QA
Items that are currently undergoing ARIS Technical QA (For models only)
Sign-off
Items that have been QAed and now require sign-off
Approved
Items have been formally signed-off by the owner and may be included in the
next build / implementation cycle.
Released
Approved items that have been built, tested, deployed and released into the
organisation and are now classified as BAU.
Archived
Identifies which previously released versions of items need to be kept for

historical audit purposes.
The release information for all ARIS content will be recorded in the Model Status and Object Status
attributes refer to examples below:
Figure 14: Model Status List
Figure 15: Object Status List

Page 19 of 57
17 June 2014
3.2 Modelling Governance Process

The Modelling Governance Process governs the design activities within ARIS and comprises of two phases,
Change Request and Assessment and Model Design.
The diagram below illustrates the proposed process, including phases and high-level activities:
Figure 16: Model Design Governance Process
3.2.1 Change Request and Assessment

The Change Request and Assessment process manages the definition and approval of business requirements
built in ARIS. Activities include:
Request quantification and approval
Work prioritisation
Requirements management
Defect / Enhancement management
Below is a high-level illustration of these activities:
Figure 17: Change Request and Assessment Process
Page 20 of 57
17 June 2014
3.2.2 Model Design

This process governs the design of the approved business process requirements (refer to Change Request and
Assessment process). The purpose of the process is:
To ensure all design changes have prior approval and align to pre-set requirements
Give a consistent approach to process design and modelling in ARIS
Provide full traceability
Provide accountability
Below is a high-level illustration of these activities:
Figure 18: Governance Process for Controlling Modelling Activities
3.2.3 Audit Trail

An ARIS Macro has been developed to support the capture of governance information (i.e. Status, comment,
performed by, etc.) for management and audit purposes. This macro is automatically executed after closing a
changed model in ARIS and prompts users to supply their email address, select a status and add a comment.
The below example illustrates what the modelling team will maintain when designing their processes.
Performed by email
Status (e.g. QA)
Figure 20: Documenting Process Design
Figure 19: Changes Stored in Model

Attributes
Page 21 of 57
17 June 2014
4 Model-to-Execute
An important use-case for the ARIS solution is to be able to support CSU enterprise workflows developed by the
webMethods platform. The business-driven requirements including processes, KPIs and service information
defined in ARIS can be shared with webMethods and the changes identified in webMethods can be inversely
feed back into ARIS. This approach between the two platforms is commonly known as Model-to-Execute.
Below is the proposed Model-to-Execute lifecycle (additional information can be found in the ARIS Technical
RCM Process presentation):
Figure 21: Model-to-Execute Lifecycle
Page 22 of 57
17 June 2014
5 CSU Enterprise Framework

The CSU Enterprise Framework consists of a set of ARIS models, objects and methodology to describe the
different aspects of the CSU Enterprise Model.
The following sections describe the ARIS models, objects, connections and attributes that comprise within the
CSU Enterprise Framework. Including:
Navigation / Entry Models
Organisation Modelling
Process Modelling
Information Modelling
Application Modelling
Requirement Modelling
Capability and Service Modelling
5.1 Navigation / Entry Models

5.1.1 CSU Entry Model
The CSU Entry Model is high-level enterprise-wide entry point into the ARIS database with linkage to:
Projects (past, current and future)
General information (ARIS and end-user training, communications and change management
information, news and updates, etc.)
Governance processes: E.g. Change Request Management and Release Cycle Management
Support processes: E.g. ARIS Help Desk requests (e.g. user access)
Figure 22: CSU Entry Model
Page 23 of 57
17 June 2014
5.1.2 Project Entry Model

The project entry model is the starting point to explore and navigate the ARIS content specific to projects. It
provides links to the main aspects of the localised Enterprise Framework content.
Example below:
Model purpose: Entry/Navigation Model
Specific Attributes
ARIS Model type
Structural model
ARIS Object / Symbol
Page 24 of 57
17 June 2014
5.2 Organisational Modelling

Every organization varies in its structure and components. The organisational chart maps the overall
organization with respect to its units, locations, groups, positions and roles.
Figure 23: Example Organisation Chart
Model purpose: Organisational structure
Specific Attributes
ARIS Model type
Organizational chart
This object is the generic

representation of a highlevel organizational unit

representation an
organizational unit

representation of a group
within an organization

representation of a location

representation of a position

representation of a role
Page 25 of 57
17 June 2014
5.3 Process Modelling

A core element of the CSU Enterprise Repository is the Process Architecture, which comprises of operational
processes and relationships to enterprise aspects including requirements, applications, data, organisation, etc.;
combining the information captured in the different views to form a holistic picture of the organisation. The
methodology has been specifically designed to support the Model-to-Execute approach and tooling
requirements.
The CSU Business Process Architecture in ARIS is a hierarchical structure of at least four model levels (level 14). It allows an optional model level (5) to capture detailed work instructions. It starts from a high level
process map (level 1) representing a conceptual business view down to the detailed process flows describing
specific tasks and their relation to roles, data, IT-systems, etc. Model levels 1 and 2 are represented in ValueAdded Chain diagrams using level 2 and 3 value-added chain objects (see figure CSU Process Hierarchy).
From model level 3 onwards BPMN Collaboration Diagrams are used to model process, sub-process, task and
instruction information.
IMPORTANT: All webMethods synchronisation relevant process information is modelled in relation to model
levels 3 - 5.
Enterprise Map
EWP Enterprise Map
Main Process
Student Administration
Business Process
Admissions Processing
Sub-Process
Assess Admission
Eligibility and Credit
Task Diagram
Perform Initial Eligibility

Assessment
Process modelling utilises the following model type:
Value-added Chain Diagram (Level 1 and 2)
BPMN Collaboration Diagram (Levels 3 5)
Function Allocation Diagram (Supporting all levels)
Page 26 of 57
17 June 2014
5.3.1 Value-added Chain Diagram (Level 1 and 2)

A Value-added Chain Diagram (VACD) is the model type used to articulate the enterprise map and main process
levels. The VACD is mainly used to identify the functions within an organisation that are directly involved in the
creation of a value added activities. These functions can be interlinked as a sequence of functions (which are
then described more precisely in detailed process models) and thus form a value-added chain.
On the top-level (level 1) the Enterprise Process Map is the central entrance model for the complete process
landscape and shows all defined main processes divided in management processes, core processes and
enablement processes.
Figure 25: Example Level 1 Enterprise Map Diagram
The Level 2 VACD shows the different main processes for each of the functions within the enterprise map.
Similar to the structure of the level 1 model, the Business Process objects will be categorised into
Management, Core and Enablement.
Figure 26: Example Level 2 Main Process Diagram
Model purpose: Business process function mapping
Specific Attributes
ARIS Model type
Value-added chain diagram
Value add function
Page 27 of 57
17 June 2014
5.3.2 BPMN Collaboration Diagram (Levels 3 5)

The BPMN Collaboration Diagram depicts the detailed flow of referenced process, tasks and activities that take
place within the process represented on the levels 3 to 5.
N.B. The BPMN Collaboration Diagram methodology included in the section below is a sub-set of the full
notation and configured to suite CSUs process modelling requirements and that of the Model-to-Execute
standards.
Level 3 BPMN diagrams consist of a series referenced sub-processes. The underlying level 4 BPMN diagrams are
referenced using the Call Activity as illustrated in the graphic below and shows the flow between these
processes.
Figure 27: Example Level 3 BPMN Diagram

The main purpose of the level 4 BPMN diagram is to model the tasks (including manual, user and service)
performed by actors within the process and the record the interactions between the participants. Level 4
BPMNs are the primary level for modelling processes and offer the most versatile level of process information
for the organisation. For many organisations level 4 BPMNs are the lowest required level of modelling, but an
optional level 5 BPMN can be modelled if required to capture the work instructions for the individual tasks.
Figure 28: Example Level 4 / 5 BPMN Diagram
Page 28 of 57
17 June 2014
Model purpose: Detailed business processes
Specific Attributes
ARIS Model type
BPMN collaboration diagram (BPMN 2.0)
An abstract task should be used as a

temporary placeholder and should be
replaced with a manual, user or
service task.
Function / Manual Task
A Manual Task is used to

depict a single activity
which is performed
manually. A loop shows
that a task may loop for a defined amount of times.
Function / User Task
A User Task is used to
depict a single activity
which is performed by a
person using an application or system (e.g.
webMethods).
Function / Service Task
A Service Task is used to

indicate where a process
step or activity is fully
automated and executed
by an IT system only.
Read-only - Called
element
Participant / Pool
Lane
Pool
Function / Call activity

A point in the process where a global
process is reused.
A Pool is used to show a

Participant in a Process
Collaboration Model.
A Lane is a sub-partition within
a Pool to show individual
Process responsibilities.
A Start Event (Basic) is

used to depict the start
of a Process. Start Event
(Message) is used to
represent the receipt of message interaction from
another pool which triggers a process.
An Intermediate Event
(Message) is an
Intermediate Event that
is triggered when a
message is received or sent.
Page 29 of 57
17 June 2014
Model purpose: Detailed business processes
Specific Attributes
An End Event (Basic) is used to

depict the end of a Process. End
event (Message) is used to represent
a process or sequence that ends with the
sending of a message to another pool.
An Exclusive (OR) Gateway is used to

identify a decision where two or more
outgoing sequence flows are available,
but only one can be taken.
An Inclusive (AND/OR) Gateway is a

branch in the process that may trigger
more than one out-going path, based on
conditions.
A Parallel (AND) Gateway is used to

identify where multiple flow paths must
be taken.
An End Event (Terminate) is used to

terminate ALL functions running in the
process regardless of their status when
the Event is reached.
Text annotation
IMPORTANT: Connections resulting from decision gateways may have the following attributes maintained:
Figure 29: BPMN Connection Attributes
5.3.3 Function Allocation Diagram (Supporting all levels)

The Function Allocation Diagram (FAD) extends the limitations of the BPMN notation to capture the full
business context. This model will be utilised to describe the additional detailed business information (such as
roles, applications, requirements, etc.) on the BPMN process level and to assign detailed information about
e.g. Requirements, Data, KPIs, etc. to higher level models (VACD) if required.
Process Hierarchy Levels 2 to 4
The FAD information for level 2 main processes, level 3 business processes and level 4 sub-processes includes
the following: requirements, KPI instances, organisation units, objectives and capabilities.
Page 30 of 57
17 June 2014
Figure 30: Example Level 2 4 Process FAD

Mandatory: All connected objects are optional.
Process Hierarchy Levels 5 to 6
Level 5/6 Task FADs are depended on the task type. A FAD for manual, user and service tasks has been defined.
Manual Task
Figure 31: Example Manual Task FAD Diagram

Mandatory: Role (only 1 permitted)
Service Task
Figure 32: Example Automated Task FAD Diagram

Mandatory: Either one business service or software service
Page 31 of 57
17 June 2014
User Task
Figure 33: Example User Task FAD Diagram
Mandatory: One role and screen
Model purpose: Function or task details
Specific Attributes
ARIS Model type
Function allocation diagram
Function / task

representation of a process
KPI

representation of a
business or technical
requirement

representation of an
organisation

representation of a
business objective

representation of a
business capability

role
Page 32 of 57
17 June 2014
Model purpose: Function or task details
Specific Attributes
application

representation of a
software service

representation of a
business service

representation of
information carrier

representation of a screen
5.4 Information Modelling

Information modelling comprises of three hierarchical levels:
Level 1 - IE Data Model (Business Objects)
Level 2 - IE Data Model (Entities)
Level 3 - eERM Attribute Allocation Diagram (Attributes)
5.4.1 Level 1 - IE Data Model (Business Objects)

The IE data model used at L1 is used to logically group clustered data (i.e. business objects) together in
domains that are defined by the data architecture group and represented by the modellers efforts.
Figure 34: Example Level 1 - IE Data Model (Business Objects) Diagram
Page 33 of 57
17 June 2014
Model purpose: Business objects / data clusters
Specific Attributes
ARIS Model type
IE Data model
This object is used to

represent data at many
levels. It depends on what
level the model in which they are used.
5.4.2 Level 2 - IE Data Model (Entities)

The IE Data Model at L2 is used to describe an L1 Cluster/Data Model object in greater granularity using the
entities that make up the upper level Cluster/Data Model object.
Figure 35: Example Level 2 - IE Data Model (Entities) Diagram

Model purpose: Data cluster entities
Specific Attributes
ARIS Model type
IE Data model

level the model in which they are used.

describe a L2 Cluster/Data
Model object in greater
granularity. The
entity objects represent what makes up the L2 data
object.
5.4.3 Level 3 - eERM Attribute Allocation Diagram (Attributes)

The eERM Attribute Allocation Diagram should be used to detail the entity objects including the attributes that
make up those L2 objects.
Page 34 of 57
17 June 2014
Figure 36: Level 3 Example eERM Attribute Allocation Diagram (Attributes)
Model purpose: Entity attributes
Specific Attributes
ARIS Model type
eERM attribute allocation diagram
Describe a L2 Cluster/Data
Model object in greater
granularity. The
entity objects represent what
makes up the L2 data object.
Primary key attribute
Data type
[Text, Floating point
number, Integer,
Boolean, Enumeration
type, Point in time,
Duration, Date, Time]
Foreign key attribute
Data type
number, Integer,
ERM attributes are

characteristics which
describe entity types.
(e.g., Your height
Data type
number, Integer,
Enumeration describes a
list value of an attribute
Lists the values within an

enumeration
(descriptive attribute))
Page 35 of 57
17 June 2014
5.5 Application Modelling

The following standards have been defined to support application modelling:
Application Domain Model
Application Communication Model / Interfaces
Application Screens
Report Catalogue
5.5.1 Application Domain Model

Application domain model comprises of two hierarchical levels:
Level 1 - Application Domains
Level 2 - Application Modules
5.5.1.1 Level 1 - Application Domains

The application domains model is used to logically group the enterprise applications and describes system
families or hierarchies of application systems. Similar application system types can be combined to form an
application system class. The similarity can be based on different classification criteria. Thus, an application
system type can be assigned to multiple application system classes.
Figure 37: Example Level 1 - Application Domains Diagram
Model purpose: Application domains
Specific Attributes
ARIS Model type
Application system type diagram

application class.

application.
Page 36 of 57
17 June 2014
5.5.1.2 Level 2 - Application Modules

This model is used to decompose an application defined in the L1 application domain mode by showing the
modules that make up the specific application.
Figure 38: Level 2 - Example Application Modules Diagram
Model purpose: Application modules
Specific Attributes
ARIS Model type

application.

application module.
5.5.2 Application Communication Model / Interfaces

Application communication model comprises of two hierarchical levels:
Level 1 - Overall Interface Diagram
Level 2 - Interface Description
5.5.2.1 Level 1 - Overall Interface Diagram

This model shows the overall interface diagram of a client. Some clients may call this a "wire Diagram". Only
the applications and their interactions with one another are shown in this model. More detailed information
surrounding these interfaces is shown in the level 2 interface description diagram.
Page 37 of 57
17 June 2014
Figure 39: Example Level 1 - Overall Interface Diagram
Model purpose: Interfaces

ARIS Model type
Specific Attributes
Application collaboration diagram

application.

application interface.
5.5.2.2 Level 2 - Interface Description

This model describes the specific interface identified in the level 1 overall interface diagram including; the
data exchanged between the two applications, the interface itself and the protocol used to pass this
information.
Figure 40: Example Level 2 - Interface Description Diagram
Page 38 of 57
17 June 2014
Model purpose: Interface description
Specific Attributes
ARIS Model type
Application collaboration diagram

application.

application interface.

representation of a protocol.

level the model in which they
are used.
5.5.3 Application Screens

Application screens model comprises of two hierarchical levels:
Level 1 Screen Catalogue
Level 2 Screen Design
Level 2 Screen Navigation
5.5.3.1 Level 1 Screen Catalogue

The screen catalogue diagram lists all the screens.
Figure 41: Example Level 1 - Screen Catalogue Diagram
Model purpose: Screen catalogue

ARIS Model type
Specific Attributes
Function allocation diagram

representation of a
screen.
Page 39 of 57
17 June 2014
5.5.3.2 Level 2 Screen Design

The screen design diagram defines the conceptual design elements (e.g. text inputs, drop-down boxes, logo,
etc.) of the respective screen included in the level 1 screen catalogue diagram.
Figure 42: Example Level 2 - Screen Design Diagram
Model purpose: Screen design
Specific Attributes
ARIS Model type
Screen design
ERM attributes are
characteristics which
describe entity types.
(e.g., Your height
Data type
number, Integer,

/ function / task.
Panel object is used to

group the screen
elements (e.g. text
inputs, buttons, ect.)
(descriptive attribute))
Page 40 of 57
17 June 2014
Model purpose: Screen design
Specific Attributes
For items where multiple
selection is available, it
is important to mention
in its description what
section options are
allowed.
Available screen design

elements
5.5.3.3 Level 2 Screen Navigation

The screen navigation diagram defines the navigation between screens identified in the level 1 screen
catalogue diagram.
Figure 43: Example Level 2 - Screen Diagram
Page 41 of 57
17 June 2014
Model purpose: Screen navigation
Specific Attributes
ARIS Model type
Screen navigation
representation of a
screen.
This object is the generic representation
of an exclusive or rule.
representation of an event
(condition)
5.5.4 Report Catalogue

The report catalogue diagram lists all the required reports.
Figure 44: Example Report Catalogue Diagram
Model purpose: Report catalogue
Specific Attributes
ARIS Model type

representation of a report
Page 42 of 57
17 June 2014
5.6 Project Requirements Modelling

Before and during the design phase of a project the requirements will be collected, assigned to a project
objective and decomposed. Typically these include both business and technical requirements. The ARIS model
type is a Requirements Tree model and it shows all requirements that determine the scope of the project.
Figure 45: Example Project Requirements Diagram
Model purpose: Report catalogue
Specific Attributes
ARIS Model type
Requirements tree
objective

representation of a
requirement
Requirement type
[Functional (General),
Non-Functional
(General), Functional
(Assignment), Functional
(Escalation), Functional
(Conditions)]
5.7 Capability and Service Modelling

Capability and service modelling comprises of the following:
Business Capability Model
Business Service Model
Software Service Model
5.7.1 Business Capability Model

The business capability model is a catalogue of all capabilities, grouped into logical categories or business
areas.
Page 43 of 57
17 June 2014
Figure 46: Example Business Capability Model
Model purpose: Business capability grouping
Specific Attributes
ARIS Model type
Service architecture diagram

representation of a
business capability.
5.7.2 Business Service Model

The business service model comprises of the following two hierarchical levels:
Level 1 Enterprise Business Service Map
Level 2 - Business Service Allocation
5.7.2.1 Level 1 Enterprise Business Service Map

The enterprise business service map catalogues and groups the enterprises business service inventory into
logical categories or business areas.
Figure 47: Example Level 1 - Enterprise Business Service Map
Model purpose: Business service grouping
Specific Attributes
ARIS Model type
Service architecture diagram

The district is a grouping
object for business
services.
Page 44 of 57
17 June 2014
Model purpose: Business service grouping
Specific Attributes
representation of a
business service.
5.7.2.2 Level 2 Business Service Allocation

For every business service listed in the enterprise business service map a corresponding business service
allocation diagram need to be created, which includes the following information about the business service;
incoming and outgoing clustered data, KPI instance, capability, software service, organization and functions.
Figure 48: Example Level 2 Business Service Allocation
Model purpose: Business service information
Specific Attributes
ARIS Model type
Service allocation diagram

representation of a
business service.

representation of a
business capability.

/ function / task.

level the model in which they
Page 45 of 57
17 June 2014
Model purpose: Business service information
Specific Attributes
are used.
KPI

organisation

representation of a
software service.
5.7.2.3 Level 1 Enterprise Software Service Map

The enterprise software service map catalogues and groups the enterprises software service inventory into
logical categories or business areas.
Figure 49: Example Level 1 - Enterprise Software Service Map
Model purpose: Software service grouping
Specific Attributes
ARIS Model type

The application class is a
grouping object for
software services.

representation of a
software service.
5.7.2.4 Level 2 Software Service Allocation

For every software service listed in the enterprise software service map a corresponding software service
allocation diagram need to be created listing the underlying software service operations.
Page 46 of 57
17 June 2014
Figure 50: Example Level 2 Software Service Allocation
Model purpose: Software service information
Specific Attributes
ARIS Model type

representation of a
software service.

representation of a
software service operation.
Page 47 of 57
17 June 2014
5.8 Common Attributes

Attributes are a property or characteristic of a model, object or connection. In ARIS some attributes are system
or macro maintained while others are configurable by the modeller. The following lists of attributes are
common for all models and objects in the database. All mandatory attributes are marked with a *.
5.8.1 Common Model Attributes

Attribute
Information
Name*
Model name
Full name
Long name
Description/Definition
Model description (e.g. Purpose, Scope, Description)
Remark/Example
Additional information (e.g. comments or remarks)
Release
Current release version
Person responsible*
Email address of model owner
Type
Read-only - Maintained by ARIS
Creator*
Identifier*
Maintained by ARIS
Last change*
Last user*
Time of generation*
Link 1
Link to external document
Title 1
Title/Name of link to external document
Model Status
Release cycle status (Audit Trail Macro maintained)
Design History
Design history tracker (Audit Trail Macro maintained)
QA History
QA history tracker (Audit Trail Macro maintained)
Approval History
Approval history tracker (Audit Trail Macro maintained)
Release History
Release history tracker (Audit Trail Macro maintained)
Page 48 of 57
17 June 2014
5.8.2 Common Object Attributes

Attribute
Information
Name*
Object name
Full name
Long name
Description/Definition
Object description (e.g. Purpose, Scope, Description)
Remark/Example
Additional information (e.g. comments or remarks)
Type
Creator*
Identifier*
Maintained by ARIS
Last change*
Last user*
Time of generation*
Link 1
Link to external document
Title 1
Title/Name of link to external document
Object Status
Release cycle status (Audit Trail Macro maintained)
Design History
Design history tracker (Audit Trail Macro maintained)
Approval History
Approval history tracker (Audit Trail Macro maintained)
Release History
Release history tracker (Audit Trail Macro maintained)
Page 49 of 57
17 June 2014
3 Modelling Standards
5.9 General Modelling Guidelines
General modelling guidelines include:
Keep consistency between the level of detail and the types of objects being included at each level
within a model and between referenced models.
Define your models scope.
Do not resize symbols.
Use the zoom out view test. If you zoom out of the model:
o
Can you follow the general flow of activities?
Is it clear where the core process flow is and where the exceptions are?
Record a high-level description first.
Note details and complexity in the flows using free-text comments. Simplify and populate attribute
details later.
Save regularly (especially when working remotely).
Working with Modelling Levels (e.g. Process Hierarchy)

The purpose of using modelling levels is two-fold:
Different levels have different uses (each level conveys different information)
The level of granularity increases with each process level Guideline.
Establish a target level of detail before beginning to model, but dont ignore or throw away
information at the wrong level that is raised. This information can be cleaned up later, and may
indicate that there are other higher, same, or lower level models to be considered.
Use model assignments to break down complex functions from high-level models to more detail while
maintaining a consistent level of detail at each level.
Break up complex branching flows using process interfaces (BPMN Signal Events) at logical points to
help simplify individual models.
Using Models to Support Communication and Knowledge Transfer

The CSU repository represents a common understanding of the enterprises architectures and often
incorporating inputs from many individuals. It is important to ensure that all of the participants have a clear
and common understanding of the information depicted. Once completed, the ARIS models become a valuable
asset stored in the common repository. Following some basic practices can help ensure that these process
models are re-usable in the future:
Follow the training rules (for all models and objects)
Put supporting details into the attributes fields of models and objects rather than into separate
documents. Reports can be generated on models and attribute information to create textual reference
documents.
Describe objects clearly in the description attributes.
Record model owner and author/modeller.
Avoid bullet-point lists in attribute fields
Page 50 of 57
17 June 2014
5.10 BPMN Modelling Guidelines

General BPMN modelling guidelines include:
Keep models to less than 3 pages or about 15 functions/tasks, when possible, to improve readability.
Define your models scope. (For example, when does the process start and end.)
Follow main flow first before mapping exceptions (assignments or sub-processes).
Exception paths i.e. Rejection of approval must be modelled
It is good process modelling practice to include an exit path to a loop for the end user to understand
that all loops have a final conclusion. When modelling a loop set the conditions for the loop exit to
avoid an endless loop.
Model tasks, events and decisions first and add other objects later.
Model the essentials of the flow as a draft, and then return later to elaborate detail and map exception
processes.
5.11 Model and Object Naming

Naming conventions are provided for better allocation and clarity to help in maintaining the integrity and
stability of the model structure. Besides conventions on which model types, object types, and attributes to use
on what level, conventions also exist over both the names of models and objects within those models.
This section details and discusses best practices for Naming Conventions that must be applied to the models
and objects.
As a guide, here are some general guidelines which will be applicable for naming objects and models:
Keep names brief yet specific
They should be generally understandable and common - try to fit in space without resizing
Dont use abbreviations
Names should reflect the organisations terminology (valid for the whole organisation, not only parts of
it)
Avoid overuse or inconsistent use of capitalisation (Only first letter of a sentence should be capitalised)
5.12 Model Naming

The conventions for naming models:
Model names should have business meanings and should not describe the model type. (Example:
Organisational Chart).
Subordinate models should have the same name as the originating object when linking models.
Avoid using special characters, numbers or letters that depict relationships as it is redundant to the
capabilities inherent to ARIS and can cause future rework as you refine models and structures.
Page 51 of 57
17 June 2014
Objects Naming
An object name should be unambiguous and concise. For example, use completely spelled words wherever
possible to avoid different interpretations and to facilitate keyword searches.
As a best practice, object names should not contain more than 7 words for readability of objects. Any further
explanation or details are to be stored in the description attribute.
Avoid using:
Generic names (Use Fix Customer Payment Errors instead of Fix Errors)
Special characters and punctuation (such as underscores), when possible
Plurals and possessive forms of a word
Conjunctions (and, but, or)
Prepositions
Articles (a, an, the)
Abbreviations (especially organisation-specific, not commonly known abbreviations)
Overuse of capitalisation
Naming Convention for Functions / Activities

The name of a function is composed of a single verb (in the infinitive) followed by at least one noun. A function
describes an activity, avoid and, or should be then split into two steps.
The following convention applies to the attribute Name of the object type Function:
Verb in infinitive + information object (noun in singular), for example Release Purchase Order.
Examples of incorrect Function/Activity names are:
Customer identification (Verb missing)
Identification of the customer (Verb missing)
Perform customer identification (Information object incorrect)
The Function/Activity name, Perform customer identification, does not correspond to the naming
convention. The information object that the Function/Activity processes is the customer and not the customer
identification.
Hint: The verb perform is an indication that the information object is not suitable.
Incorrect Function Naming
Correct Function Naming
Perform customer order checking
Check customer order
Perform calculation
Calculate information object
(Note: It is not clear what is being calculated,

since an information object is not specified.)
e.g. Calculate sales price, Calculate risk
Customer identification (Verb missing)
Identify customer
Page 52 of 57
17 June 2014
Naming Convention for Events

The name of an event is composed of at least one noun followed by a single verb (in past participle). An event
describes a state. For the Name attribute of the object type State Change / Event, use:
Information subject (noun in singular) + verb in past tense, for example Purchase Order Released or Order
Received.
A State Change/ Event always:
Relates to precisely one Function/Activity
Describes the state transition of the information object processes in the Activity/Function
Matches the information object of the Activity/Function that precedes it by not using auxiliary verbs
(is, are, was, were).
Summary of Object Naming Conventions

Since generally identification of objects results from the attribute Name, it is essential to comply with
naming conventions when modelling.
Page 53 of 57
17 June 2014
4 ARIS Reports and Macros

ARIS provides a rich set of standard reports and macros to create, change, analyse, export or import
information. In addition new reporting capabilities were developed to support CSU Enterprise Model definition,
QA and technical/management reporting requirements.
It is also important to note that some sensitive reports (e.g. reports that can change content in ARIS), may be
deactivate by default so users cannot accidently execute it. These reports can be reactivated at any time by an
ARIS administrator by opening the properties of the respective report.
Figure 51: Hiding ARIS Reports
5.13 Standard Reports and Macros

A list of highlighted ARIS reports and macros that may be useful to the CSU team:
Name / Path (Category)
Start Context
Description
Output Model Information

(Excel/Word)
Right-click any
model
Creates an Excel or Word document which lists the

content of the selected models (objects contained
in a model, object relationships, object names and
types, attributes and the model graphic).
Right-click any
model
This report outputs all data of the selected

processes up to the selected assignment level.
Graphics and/or attachments may be included, if
required.
Right-click any
object
Outputs the relationships and target objects at

definition level for the selected objects.
Optionally, you can output the groups and
attributes of the source and target objects.
Path: Reports\Standard
Create Process Manual
(Word/PDF)
Output object information
(Excel/Word)
Export attribute values for
translation (Excel)
The data is output in a table.

Right-click group
that stores required
models or objects
Exports attribute information to Excel for easy

mass-update.
Right-click database
Import attribute changes made using Export

attribute values for translation report
Import translated attributes
Page 54 of 57
17 June 2014
5.14 Custom Reports and Macros

The following list of custom reports and macros have been developed for CSU and have been tailored to the
specific requirements and environment of the organization.
IMPORTANT: Items with ADMIN in the title should only be executed by ARIS administrators.
Name / Path (Category)
Start Context
Description
ADMIN - Exchange Model

Headers VX
Right-click any
model or group
Exchanges the headers, of all the selected models

or all models within the selected group, with the
header of the selected model
Right-click any group
The report creates a reference model of all the

objects in a database based on a specific object
type. The report is particularly useful in creating
library models.
Right-click any
object, model or
group
Replaces the text value of an attribute value for

the selected items. It is particularly useful for
updating read-only attributes or mass updating
multiple items at once.
Right-click object or
model
Transfers the maintained attributes from the

common attributes model and object to the
selected items.
Path: Reports\CSU
ADMIN - Reference Model
Generation Wizard VX
Path: Reports\CSU
ADMIN - Replace Text in
selected attribute in selected
Objects or Models or Groups VX
Path: Reports\CSU
ADMIN - Transfer Common
Attributes to Selected MetaModel Items VX
N.B. This report can only be executed on the ARIS

Standards and Conventions database.
Path: Reports\CSU
CSU - Generate Business Process
Design Document VX
Right-click object
Generates a Business Process Design Document.

N.B. Needs to be executed from a level 3 function
(e.g. Applications Processing).
Path: Reports\CSU
Audit Trail VX
Path: Macros\CSU
Automatically
configured to
execute after an
updated model is
closed
Maintains the ARIS model and object governance

information.
Page 55 of 57
17 June 2014
5.15 ARIS Competency Centre (Proposed Future State)

The ARIS Competency Centre (CC) provides CSU with the capabilities required to support current and future
strategic initiatives / objectives, which utilise the ARIS Software Platform as part of their software delivery
lifecycles and BAU initiates.
The CSU ARIS CC provides the following key services:
ARIS Infrastructure
Process Framework & Conventions
EA Architectures and Frameworks
ARIS Release Management
QA & Integration
ARIS Technical QA
ARIS Technical Training
ARIS Governance
Model-to-Execute / webMethods Integration
Figure 52: ARIS Competency Centre

Please contact the CSU ARIS CC Team in case you need any ARIS related support:
ARIS.CC.SUPPORT@csu.edu.au (illustration only)
Page 56 of 57
17 June 2014
5 Glossary
Term
Definition
ARIS
The software used to model EA and process content
BAU
Business As Usual
BPMN
Business Process Modelling Notation
CC
Competency Centre (e.g. ARIS CC)
E2E
End-to-End
GUID
Global Unique Identifier
KPI
Key Performance Indicator
SME
Subject Matter Expert
VACD
Value-added Chain Diagram
Rwdv
Access attributes for ARIS database read+write+delete+version
Page 57 of 57

CSU ARIS Modelling Standards and Conventions Manual V1 0

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

CSU ARIS Modelling Standards and Conventions Manual V1 0

Diunggah oleh

Hak Cipta:

Format Tersedia

CSU Enterprise Workflow Project (EWP) Phase 1

ARIS Standards and Conventions Manual

ARIS Modelling Standards and Conventions Manual

Initial Version for Client review

Changes incorporating review comments

Further Changes based on discussions with CSU

Further Changes based on CSU feedback received

V1.0 release based on approval of V0.4 draft.

Project Manager and BPM

2014 Software AG. All rights reserved.

ARIS Modelling Standards and Conventions Manual

Why Adopt a Common Approach to Conventions?

ARIS Framework / Views

ARIS Database Framework

Database Naming Conventions

Database Folder Structure

Definition and Occurrence Objects

User Access and Authorisation

ARIS Modelling Design Standards

Basic ARIS Client settings

Content Release Cycle Management

Modelling Governance Process

Change Request and Assessment

CSU Enterprise Framework

Navigation / Entry Models

CSU Entry Model

Project Entry Model

Value-added Chain Diagram (Level 1 and 2)

2014 Software AG. All rights reserved.

ARIS Modelling Standards and Conventions Manual

BPMN Collaboration Diagram (Levels 3 5)

Function Allocation Diagram (Supporting all levels)

Level 1 - IE Data Model (Business Objects)

Level 2 - IE Data Model (Entities)

Level 3 - eERM Attribute Allocation Diagram (Attributes)

Application Domain Model

Application Communication Model / Interfaces

Project Requirements Modelling

Capability and Service Modelling

Business Capability Model

Business Service Model

Common Model Attributes

Common Object Attributes

General Modelling Guidelines

BPMN Modelling Guidelines

Model and Object Naming

ARIS Reports and Macros

Standard Reports and Macros

Custom Reports and Macros

ARIS Competency Centre (Proposed Future State)

2014 Software AG. All rights reserved.

ARIS Modelling Standards and Conventions Manual

Figure 2: ARIS House representing the Views of an Organisation

Figure 3: CSU Enterprise Repository Folder Structure

Figure 4: Example Library Folder Structure

Figure 5: Occurrence Copy Illustration

Figure 6: ARIS Identifiers

Figure 7: Example Folder Permissions

Figure 8: User Groups Defined in Central User Management

Figure 9: Example Attributes Maintained in Standards DB

Figure 10: Steps to Update CSU Filter

Figure 11: CSU Modelling Template

Figure 12: CSU Header Model Location

Figure 13: CSU Header