ARIS Standards and Conventions Manual

Transcription

1 CSU Enterprise Workflow Project (EWP) Phase 1 ARIS Standards and Conventions Manual Date: 23 June 2014 Version: 1.0 Software AG

2 Document Control Document History Date Version Authors Comments/Description of Change 10Jun Luke Audie Initial Version for Client review 13Jun Luke Audie Changes incorporating review comments 17Jun Luke Audie Further Changes based on discussions with CSU 23Jun Luke Audie Further Changes based on CSU feedback received 23Jun 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 06Jun2014 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 2014 Software AG. All rights reserved. Page 2 of 57

3 Table of Contents 1.0 Introduction Purpose Intended Audience Background Conventions Definition Why Adopt a Common Approach to Conventions? 8 1 ARIS Overview ARIS Methodology ARIS Framework / Views 9 2 ARIS Database Framework Database Naming Conventions Database Folder Structure Artefact Libraries Definition and Occurrence Objects User Access and Authorisation 13 2 ARIS Modelling Design Standards Filter Template Basic ARIS Client settings 18 3 ARIS Governance Content Release Cycle Management Modelling Governance Process Change Request and Assessment Model Design Audit Trail 21 4 ModeltoExecute 22 5 CSU Enterprise Framework Navigation / Entry Models CSU Entry Model Project Entry Model Organisational Modelling Process Modelling Valueadded Chain Diagram (Level 1 and 2) Software AG. All rights reserved. Page 3 of 57

4 5.3.2 BPMN Collaboration Diagram (Levels 3 5) Function Allocation Diagram (Supporting all levels) Information Modelling Level 1 IE Data Model (Business Objects) Level 2 IE Data Model (Entities) Level 3 eerm Attribute Allocation Diagram (Attributes) Application Modelling Application Domain Model Application Communication Model / Interfaces Application Screens Report Catalogue Project Requirements Modelling Capability and Service Modelling Business Capability Model Business Service Model Common Attributes Common Model Attributes Common Object Attributes 49 3 Modelling Standards General Modelling Guidelines BPMN Modelling Guidelines Model and Object Naming Model Naming 51 4 ARIS Reports and Macros Standard Reports and Macros Custom Reports and Macros ARIS Competency Centre (Proposed Future State) 56 5 Glossary Software AG. All rights reserved. Page 4 of 57

5 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: ModeltoExecute 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 Software AG. All rights reserved. Page 5 of 57

6 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 Software AG. All rights reserved. Page 6 of 57

7 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 toolset 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 Software AG. All rights reserved. Page 7 of 57

8 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 2014 Software AG. All rights reserved. Page 8 of 57

9 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 timeintensive development Automation of business process document generation: o o As a single point repository for business process document artefacts for consistency and document control Enterprise Map Main Process Business Process SubProcess Task Diagram L1 Model L2 Object L2 Model L3 Object L3 Model L4 Object L4 Model L5 Object L5 Model L6 Object Figure 1: CSU Process Hierarchy EWP Enterprise Map Student Administration Admissions Processing Assess Admission Eligibility and Credit Perform Initial Eligibility Assessment Reducing time and cost to create documents manually by generating predeveloped 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 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 Software AG. All rights reserved. Page 9 of 57

10 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: Examples: CSU Enterprise Repository V1.0 WIP [Company] [Purpose] [Version No.] [WIP / REL / Prod] CSU Standards and Conventions V1.0 REL Item Company Purpose Release Status Description Selfexplanatory For example, Enterprise Repository or Standards and Conventions WIP Work in Progress REL Released for build Prod production post build, deployment and publication The CSU Enterprise Repository database will be a multiproject 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 ModeltoExecute is that all databases need to be versionable Software AG. All rights reserved. Page 10 of 57

11 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 highlevel 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 processdriven 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, metamodel and configuration, sandpit Artifact Libraries Enterprise level framework folders and models Each project has its own parent folder which includes the various frameworks Folder to store temporary testing related models Figure 3: CSU Enterprise Repository Folder Structure Governance framework models Training, CM and general documentation folder Stores configuration as well as Technical area for performing onceoff tasks Folder structure guiding principles to help maintain a clean working database: 2014 Software AG. All rights reserved. Page 11 of 57

12 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, reuse 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 (highlevel valueadded 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 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 Software AG. All rights reserved. Page 12 of 57

13 1.12 User Access and Authorisation Figure 5: Occurrence Copy Illustration 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 rightclicking 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 2014 Software AG. All rights reserved. Page 13 of 57

14 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 Software AG. All rights reserved. Page 14 of 57

15 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 Arisservice Process developer Process engineer CSU Admin CSU Project (e.g. EWP) Description Required for ModeltoExecute. Requires rwdv to all folders and needs the Entire method and wm integration filters assigned. All webmethods Process developers need their ARIS user account assigned to this group. All process engineers who need to synchronize process models with webmethods Designer need to be assigned to this group 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. 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 Software AG. All rights reserved. Page 15 of 57

16 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 4. Select Filter 3. Rightclick CSU Filter and Edit 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 Software AG. All rights reserved. Page 16 of 57

17 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 2014 Software AG. All rights reserved. Page 17 of 57

18 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 Multiline text 2014 Software AG. All rights reserved. Page 18 of 57

19 3 ARIS Governance 3.1 Content Release Cycle Management The Design Governance Process utilises a fivephase 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 signoff 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 workinprogress items 2 QA Items that are currently undergoing ARIS Technical QA (For models only) 3 Signoff Items that have been QA ed and now require signoff 4 Approved Items have been formally signedoff 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 2014 Software AG. All rights reserved. Page 19 of 57

20 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 highlevel activities: Figure 16: Model Design Governance Process 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 highlevel illustration of these activities: Figure 17: Change Request and Assessment Process 2014 Software AG. All rights reserved. Page 20 of 57

21 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 preset requirements Give a consistent approach to process design and modelling in ARIS Provide full traceability Provide accountability Below is a highlevel illustration of these activities: Figure 18: Governance Process for Controlling Modelling Activities 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 address, select a status and add a comment. The below example illustrates what the modelling team will maintain when designing their processes. Performed by Status (e.g. QA) Figure 20: Documenting Process Design Figure 19: Changes Stored in Model Attributes 2014 Software AG. All rights reserved. Page 21 of 57

22 4 ModeltoExecute An important usecase for the ARIS solution is to be able to support CSU enterprise workflows developed by the webmethods platform. The businessdriven 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 ModeltoExecute. Below is the proposed ModeltoExecute lifecycle (additional information can be found in the ARIS Technical RCM Process presentation): Figure 21: ModeltoExecute Lifecycle 2014 Software AG. All rights reserved. Page 22 of 57

23 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 CSU Entry Model The CSU Entry Model is highlevel enterprisewide entry point into the ARIS database with linkage to: Projects (past, current and future) General information (ARIS and enduser 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 2014 Software AG. All rights reserved. Page 23 of 57

24 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 2014 Software AG. All rights reserved. Page 24 of 57

25 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 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 2014 Software AG. All rights reserved. Page 25 of 57

26 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 ModeltoExecute 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, ITsystems, etc. Model levels 1 and 2 are represented in Value Added Chain diagrams using level 2 and 3 valueadded chain objects (see figure CSU Process Hierarchy ). From model level 3 onwards BPMN Collaboration Diagrams are used to model process, subprocess, 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 SubProcess Assess Admission Eligibility and Credit Task Diagram Perform Initial Eligibility Assessment Figure 24: CSU Process Hierarchy Process modelling utilises the following model type: Valueadded Chain Diagram (Level 1 and 2) BPMN Collaboration Diagram (Levels 3 5) Function Allocation Diagram (Supporting all levels) 2014 Software AG. All rights reserved. Page 26 of 57

27 5.3.1 Valueadded Chain Diagram (Level 1 and 2) A Valueadded 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 valueadded chain. On the toplevel (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 Valueadded chain diagram ARIS Object / Symbol Value add function 2014 Software AG. All rights reserved. Page 27 of 57

28 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 subset of the full notation and configured to suite CSU s process modelling requirements and that of the ModeltoExecute standards. Level 3 BPMN diagrams consist of a series referenced subprocesses. 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 2014 Software AG. All rights reserved. Page 28 of 57

29 Lane Pool ARIS Modelling Standards and Conventions Manual 17 June 2014 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 by an IT system only. A Service Task is used to indicate where a process step or activity is fully automated and executed Function / Call activity A point in the process where a global process is reused. Readonly Called element Participant / Pool A Pool is used to show a Participant in a Process Collaboration Model. A Lane is a subpartition 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. message is received or sent. An Intermediate Event (Message) is an Intermediate Event that is triggered when a 2014 Software AG. All rights reserved. Page 29 of 57

30 Model purpose: Detailed business processes 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 outgoing 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. Specific Attributes Text annotation IMPORTANT: Connections resulting from decision gateways may have the following attributes maintained: Figure 29: BPMN Connection Attributes 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 subprocesses includes the following: requirements, KPI instances, organisation units, objectives and capabilities Software AG. All rights reserved. Page 30 of 57

31 Mandatory: All connected objects are optional. Figure 30: Example Level 2 4 Process FAD 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 2014 Software AG. All rights reserved. Page 31 of 57

32 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 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 representation of a process role 2014 Software AG. All rights reserved. Page 32 of 57

33 Model purpose: Function or task details Specific Attributes representation of an 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) 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 2014 Software AG. All rights reserved. Page 33 of 57

34 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 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 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 Software AG. All rights reserved. Page 34 of 57

35 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. (descriptive attribute)) Primary key attribute Foreign key attribute ERM attributes are characteristics which describe entity types. (e.g., Your height Enumeration describes a list value of an attribute Data type [Text, Floating point number, Integer, Boolean, Enumeration type, Point in time, Duration, Date, Time] Data type [Text, Floating point number, Integer, Boolean, Enumeration type, Point in time, Duration, Date, Time] Data type [Text, Floating point number, Integer, Boolean, Enumeration type, Point in time, Duration, Date, Time] Lists the values within an enumeration 2014 Software AG. All rights reserved. Page 35 of 57

36 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 Application Domain Model Application domain model comprises of two hierarchical levels: Level 1 Application Domains Level 2 Application Modules 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 representation of an application class. representation of an application Software AG. All rights reserved. Page 36 of 57

37 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 ARIS Model type Application system type diagram Specific Attributes representation of an application. representation of an application module Application Communication Model / Interfaces Application communication model comprises of two hierarchical levels: Level 1 Overall Interface Diagram Level 2 Interface Description 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 Software AG. All rights reserved. Page 37 of 57

38 Figure 39: Example Level 1 Overall Interface Diagram Model purpose: Interfaces Specific Attributes ARIS Model type Application collaboration diagram representation of an application. representation of an application interface 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 2014 Software AG. All rights reserved. Page 38 of 57

39 Model purpose: Interface description ARIS Model type Application collaboration diagram Specific Attributes representation of an application. representation of an application interface. representation of a protocol. are used. This object is used to represent data at many levels. It depends on what level the model in which they Application Screens Application screens model comprises of two hierarchical levels: Level 1 Screen Catalogue Level 2 Screen Design Level 2 Screen Navigation 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 representation of a screen Software AG. All rights reserved. Page 39 of 57

40 Level 2 Screen Design The screen design diagram defines the conceptual design elements (e.g. text inputs, dropdown 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 ARIS Model type Screen design Specific Attributes (descriptive attribute)) ERM attributes are characteristics which describe entity types. (e.g., Your height representation of a process / function / task. Data type [Text, Floating point number, Integer, Boolean, Enumeration type, Point in time, Duration, Date, Time] Panel object is used to group the screen elements (e.g. text inputs, buttons, ect.) 2014 Software AG. All rights reserved. Page 40 of 57

41 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 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 2014 Software AG. All rights reserved. Page 41 of 57

42 Model purpose: Screen navigation ARIS Model type Screen navigation Specific Attributes representation of a screen. representation of an exclusive or rule. representation of an event (condition) 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 Application system type diagram representation of a report 2014 Software AG. All rights reserved. Page 42 of 57

43 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 representation of an objective representation of a requirement Requirement type [Functional (General), NonFunctional (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 Business Capability Model The business capability model is a catalogue of all capabilities, grouped into logical categories or business areas Software AG. All rights reserved. Page 43 of 57

44 Figure 46: Example Business Capability Model Model purpose: Business capability grouping Specific Attributes ARIS Model type Service architecture diagram representation of a business capability 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 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 ARIS Model type Service architecture diagram Specific Attributes The district is a grouping object for business services Software AG. All rights reserved. Page 44 of 57

45 Model purpose: Business service grouping representation of a business service. Specific Attributes 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 ARIS Model type Service allocation diagram Specific Attributes representation of a business service. representation of a business capability. 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 2014 Software AG. All rights reserved. Page 45 of 57

46 Model purpose: Business service information are used. Specific Attributes representation of a process KPI representation of an organisation representation of a software service 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 ARIS Model type Application system type diagram The application class is a grouping object for software services. representation of a software service 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 Software AG. All rights reserved. Page 46 of 57

47 Figure 50: Example Level 2 Software Service Allocation Model purpose: Software service information Specific Attributes ARIS Model type Application system type diagram representation of a software service. representation of a software service operation Software AG. All rights reserved. Page 47 of 57

48 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 * Common Model Attributes Attribute Name* Full name Description/Definition Remark/Example Release Person responsible* Type Creator* Identifier* Last change* Last user* Time of generation* Link 1 Title 1 Model Status Design History QA History Approval History Release History Information Model name Long name Model description (e.g. Purpose, Scope, Description) Additional information (e.g. comments or remarks) Current release version address of model owner Readonly Maintained by ARIS Readonly Maintained by ARIS Maintained by ARIS Readonly Maintained by ARIS Readonly Maintained by ARIS Readonly Maintained by ARIS Link to external document Title/Name of link to external document Release cycle status (Audit Trail Macro maintained) Design history tracker (Audit Trail Macro maintained) QA history tracker (Audit Trail Macro maintained) Approval history tracker (Audit Trail Macro maintained) Release history tracker (Audit Trail Macro maintained) 2014 Software AG. All rights reserved. Page 48 of 57

49 5.8.2 Common Object Attributes Attribute Name* Full name Description/Definition Remark/Example Type Creator* Identifier* Last change* Last user* Time of generation* Link 1 Title 1 Object Status Design History Approval History Release History Information Object name Long name Object description (e.g. Purpose, Scope, Description) Additional information (e.g. comments or remarks) Readonly Maintained by ARIS Readonly Maintained by ARIS Maintained by ARIS Readonly Maintained by ARIS Readonly Maintained by ARIS Readonly Maintained by ARIS Link to external document Title/Name of link to external document Release cycle status (Audit Trail Macro maintained) Design history tracker (Audit Trail Macro maintained) Approval history tracker (Audit Trail Macro maintained) Release history tracker (Audit Trail Macro maintained) 2014 Software AG. All rights reserved. Page 49 of 57

50 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 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 highlevel description first. Note details and complexity in the flows using freetext 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 twofold: 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 highlevel 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 reusable 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 bulletpoint lists in attribute fields 2014 Software AG. All rights reserved. Page 50 of 57

51 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 subprocesses). 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 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 Software AG. All rights reserved. Page 51 of 57

52 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 organisationspecific, 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 Perform customer order checking Perform calculation (Note: It is not clear what is being calculated, since an information object is not specified.) Customer identification (Verb missing) Correct Function Naming Check customer order Calculate information object e.g. Calculate sales price, Calculate risk Identify customer 2014 Software AG. All rights reserved. Page 52 of 57

53 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 Software AG. All rights reserved. Page 53 of 57

54 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 Create Process Manual (Word/PDF) Path: Reports\Standard Output object information (Excel/Word) Path: Reports\Standard Export attribute values for translation (Excel) Path: Reports\Standard Import translated attributes Path: Reports\Standard Rightclick any model Rightclick any model Rightclick any object Rightclick group that stores required models or objects Rightclick database 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). This report outputs all data of the selected processes up to the selected assignment level. Graphics and/or attachments may be included, if required. 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. Exports attribute information to Excel for easy massupdate. Import attribute changes made using Export attribute values for translation report 2014 Software AG. All rights reserved. Page 54 of 57