ARIS Standards and Conventions · PDF fileARIS Standards and Conventions Manual Date: 23 June...

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

©2014 Software AG. All rights reserved. Page 2 of 57

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

Approvers

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



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



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



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



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



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.



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



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

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

Product / Service: Product and/or Service portfolio

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.

Figure 2: ARIS House representing

the Views of an Organisation

L1 Model

L2 Object

L2 Model

L3 Object

L3 Model

L4 Object

L4 Model

L5 Object

L5 Model

L6 Object

Student Administration

Admissions Processing

Assess Admission Eligibility

and Credit

Perform Initial Eligibility

Assessment

Enterprise Map

Main Process

Business Process

Sub-Process

EWP Enterprise Map

Task Diagram

Figure 1: CSU Process Hierarchy



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.



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 scenario’s 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

Figure 3: CSU Enterprise Repository Folder Structure

Folder structure guiding principles to help maintain a clean working database:

Artifact Libraries

Enterprise level

framework folders

and models

Stores

configuration as

well as

Technical area for

performing once-

off tasks

Each project has

its own parent

folder which

includes the

various

frameworks

Governance

framework models

Training, CM and

general

documentation

folder

Folder to store

temporary testing

related models



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

…

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.

Figure 4: Example Library

Folder Structure



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



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.



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.



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

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.

In Administration

4. Select Filter

3. Right-click “CSU Filter”

and Edit

1. Select “Create

Automatically” 2. Select CSU

Standards DB. And select “Overwrite

filter contents”



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 CSU’s 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



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



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

1 Design New or work-in-progress items

2 QA Items that are currently undergoing ARIS Technical QA (For models only)

3 Sign-off Items that have been QA’ed and now require sign-off

4 Approved Items have been formally signed-off by the owner and may be included in the next build / implementation cycle.

5 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



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:

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

Figure 16: Model Design Governance Process



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:

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.

Figure 18: Governance Process for Controlling Modelling Activities

Figure 19: Changes Stored in Model

Attributes

Figure 20: Documenting Process Design

Status (e.g. QA)

Performed by email



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



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



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

-



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 -

ARIS Object / Symbol This object is the generic representation of a high-level organizational unit

-

This object is the generic representation an organizational unit

-

This object is the generic representation of a group within an organization

-

This object is the generic representation of a location

-

This object is the generic representation of a position

-

This object is the generic representation of a role

-



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 1-

4). 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 Value-

Added 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.

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)

Student Administration

Admissions Processing

Assess Admission Eligibility and Credit

Perform Initial Eligibility Assessment

Enterprise Map

Main Process

Business Process

Sub-Process

EWP Enterprise Map

Task Diagram

Figure 24: CSU Process Hierarchy



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 -

ARIS Object / Symbol Value add function -



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 CSU’s 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



Model purpose: Detailed business processes Specific Attributes

ARIS Model type BPMN collaboration diagram (BPMN 2.0) -

ARIS Object / Symbol 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.

-

Function / Call activity A point in the process where a global process is reused.

Read-only - Called element

Participant / Pool 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.

-

Pool

Lane



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.



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



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 -

ARIS Object / Symbol Function / task -

This object is the generic representation of a process KPI

-

This object is the generic representation of a business or technical requirement

-

This object is the generic representation of an organisation

-

This object is the generic representation of a business objective

-

This object is the generic representation of a business capability

-

This object is the generic representation of a process role

-



Model purpose: Function or task details Specific Attributes

This object is the generic representation of an application

-

This object is the generic representation of a software service

-

This object is the generic representation of a business service

-

This object is the generic representation of information carrier

-

This object is the generic 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 modeller’s efforts.

Figure 34: Example Level 1 - IE Data Model (Business Objects) Diagram



Model purpose: Business objects / data clusters Specific Attributes

ARIS Model type IE Data model -

ARIS Object / Symbol 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 -

ARIS Object / Symbol

This object is used to represent data at many levels. It depends on what

level the model in which they are used.

-

This object is used to 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.



Figure 36: Level 3 – Example eERM Attribute Allocation Diagram (Attributes)

Model purpose: Entity attributes Specific Attributes

ARIS Model type eERM attribute allocation diagram -

ARIS Object / Symbol 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 [Text, Floating point number, Integer, Boolean, Enumeration type, Point in time, Duration, Date, Time]

ERM attributes are characteristics which describe entity types. (e.g., Your height

(descriptive attribute))

Data type [Text, Floating point number, Integer, Boolean, Enumeration type, Point in time, Duration, Date, Time]

Enumeration describes a list value of an attribute

-

Lists the values within an enumeration

-



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 -

ARIS Object / Symbol This object is the generic representation of an application class.

-

This object is the generic representation of an application.

-



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



-

This object is the generic representation of an 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.



Figure 39: Example Level 1 - Overall Interface Diagram

Model purpose: Interfaces Specific Attributes

ARIS Model type Application collaboration diagram -


-

This object is the generic representation of an 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



Model purpose: Interface description Specific Attributes

ARIS Model type Application collaboration diagram -


-

This object is the generic representation of an application interface.

-

This object is the generic representation of a protocol.

-

This object is used to represent data at many levels. It depends on what 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 Specific Attributes

ARIS Model type Function allocation diagram -

This object is the generic representation of a screen.

-



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

(descriptive attribute))

Data type [Text, Floating point number, Integer, Boolean, Enumeration type, Point in time, Duration, Date, Time]

This object is the generic representation of a process / function / task.

-

Panel object is used to group the screen elements (e.g. text inputs, buttons, ect.)

-



Model purpose: Screen design Specific Attributes

Available screen design elements

For items where multiple selection is available, it is important to mention in its description what section options are allowed.

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



Model purpose: Screen navigation Specific Attributes

ARIS Model type Screen navigation -

This object is the generic representation of a screen.

-

This object is the generic representation of an “exclusive or” rule.

-

This object is the generic 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


This object is the generic representation of a report

-



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 -

This object is the generic representation of an objective

-

This object is the generic 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.



Figure 46: Example Business Capability Model

Model purpose: Business capability grouping Specific Attributes

ARIS Model type Service architecture diagram -

This object is the generic 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 enterprise’s 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.

-



Model purpose: Business service grouping Specific Attributes

This object is the generic 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 -

This object is the generic representation of a business service.

-

This object is the generic representation of a business capability.

-

This object is the generic representation of a process / function / task.

-

This object is used to represent data at many levels. It depends on what level the model in which they

-



Model purpose: Business service information Specific Attributes

are used.

This object is the generic representation of a process KPI

-

This object is the generic representation of an organisation

-

This object is the generic representation of a software service.

-

5.7.2.3 Level 1 – Enterprise Software Service Map

The enterprise software service map catalogues and groups the enterprise’s 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


The application class is a grouping object for software services.

-


-

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.



Figure 50: Example Level 2 – Software Service Allocation

Model purpose: Software service information Specific Attributes



-

This object is the generic representation of a software service operation.

-



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* Read-only - Maintained by ARIS

Identifier* Maintained by ARIS

Last change* Read-only - Maintained by ARIS

Last user* Read-only - Maintained by ARIS

Time of generation* Read-only - Maintained by ARIS

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)



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 Read-only - Maintained by ARIS

Creator* Read-only - Maintained by ARIS

Identifier* Maintained by ARIS

Last change* Read-only - Maintained by ARIS

Last user* Read-only - Maintained by ARIS

Time of generation* Read-only - Maintained by ARIS

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)



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 model’s 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?

o 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 don’t 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 enterprise’s 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



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 model’s 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

Don’t 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.



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

(Note: It is not clear what is being calculated,

since an information object is not specified.)

Calculate information object

e.g. Calculate sales price, Calculate risk

Customer identification (Verb missing) Identify customer



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.



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 macro’s that may be useful to the CSU team:

Name / Path (Category) Start Context Description

Output Model Information

(Excel/Word)

Path: Reports\Standard

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).

Create Process Manual

(Word/PDF)


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.

Output object information

(Excel/Word)


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.

The data is output in a table.

Export attribute values for

translation (Excel)


Right-click group

that stores required

models or objects

Exports attribute information to Excel for easy

mass-update.

Import translated attributes


Right-click database Import attribute changes made using “Export

attribute values for translation” report



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

Path: Reports\CSU

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

ADMIN - Reference Model

Generation Wizard VX

Path: Reports\CSU

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.

ADMIN - Replace Text in

selected attribute in selected

Objects or Models or Groups VX

Path: Reports\CSU

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.

ADMIN - Transfer Common

Attributes to Selected Meta-

Model Items VX

Path: Reports\CSU

Right-click object or

model

Transfers the maintained attributes from the

“common attributes” model and object to the

selected items.

N.B. This report can only be executed on the “ARIS

Standards and Conventions” database.

CSU - Generate Business Process

Design Document VX

Path: Reports\CSU

Right-click object Generates a Business Process Design Document.

N.B. Needs to be executed from a level 3 function

(e.g. Applications Processing).

Audit Trail – VX

Path: Macros\CSU

Automatically

configured to

execute after an

updated model is

closed

Maintains the ARIS model and object governance

information.



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:

[email protected] (illustration only)

mailto:[email protected]



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

Date post:	06-Mar-2018
Category:	Documents
Upload:	hoanghuong
View:	229 times
Download:	1 times