Getting started with ARIS 9 the design side

Getting started with ARIS 9 client is an easy exercise for those of us that have used ARIS before. The basic concepts remain the same and the new interface is easy to get around if you are familiar with tab based browsing, MS Office applications with “tabbed toolbars” or other such applications. This article might be interesting for most ARIS users, but are written with the new users in mind…

Something to consider when starting out with ARIS is the reason companies want to use ARIS in the first place. Most people think it is to have all their models in the same repository, though that is important, more important reasons should be re-usability and standardization.

Re-usability
When we re-use objects in ARIS, we are in essence enriching existing information. The first thing we gain is the fact that we do not need to define the same artifact more than once, and the other benefit is that when you update an object anywhere, it will be updated everywhere it has been used. The other major benefit is that it enables a wide range of impact analysis that would otherwise be very hard to achieve. As an example, using the same application system in different processes, the IT department can ascertain which areas will be impacted if a system is going to be replaced, which processes are impacted and which process owners need to be informed if a system failed.  Another example is that we can ascertain which users are using a specific system in which processes and enable the system access or authorizations based on the planned usage of the system. ARIS for SAP uses this principle in the Blueprint phase of SAP implementations. In ARIS re-usability comes standard, but only if the modelers understand what it is and why they should use it. I find that even when ARIS asks you if you would like to use an existing definition, most people choose not to. I guess this comes with not understanding the why or uncertainty if the object suggested is the correct one to use. Unfortunately this can only be fixed by guidance and training.

Standardization
Standardization is necessary for we can only realize specific benefits if everyone is talking the same language. It is important to understand what a specific level of information means and why. It also happens that a “level 3” in Business Architecture means something totally different in Systems Architecture. Most of the communication gaps start when there are no clear definitions between Business and IT. I would suggest doing away with Level 1-x and rather use names for each level, if everyone is talking about an “activity” rather than “level 4 or 5”, no-one in the room can misinterpret the meaning, and if someone asks what an activity means, you can give them a clear definition. This also helps if the people in the room are from different vendors, or areas within the business. When we have a standard way of documenting process, we always talk the same language. If we look at a process model, we always understand it the same way. All process reports, traceability reports and quality assurance reports work on all models.

Standardization in contrast to re-usability needs to be designed, implemented and documented for others to use. This should also be done before any work is started so that everyone understands what to do, how to do it and no “garbage” is created in the first place. ARIS enables the management of what is available to users in the form of filters that can be applied on a database when a user logs on. Filters allow only selected Model types, Object types, Symbols and attributes as defined by the ARIS administrators. We normally refer to the filter combined with the documentation on how to model whatever scenario we want the modelers to model the “Method” or “Methodology”. I found that allowing less in the beginning is easier to manage and adding other requirements as they come along. It’s easier to add than it is to remove something later… I also believe not all requirements MUST be included just because someone wants a certain piece of information included. It is hard, but sometimes we need to say no if it does not align to your Business Architecture, standards approach and planned usage of the tool.

Getting Started
If you are just starting out on your ARIS journey, I would suggest engaging with an experienced consultancy house to help you define the first version of the method. You need some insight into your journey and the way ARIS is structured. We normally plan 1-2 months for this, depending on your companies’ maturity. It has been done in 2 weeks, but is not recommended. Luckily in ARIS 9 we can now add model types and relationships that does not exist in the existing or standard method, so it should be simpler to implement a specific non standard view than in the past.

To get started you need to do the following (all of these activities is done on the ARIS Architect, unless stated otherwise):

  1. Get ARIS installed on your server (no client, server install).
  2. Load and configure all the users on the system (using User Management Console (UMC)).
  3. Define user groups (using UMC).
  4. Connect and configure all the client machines (Use the browser to connect, then configure the client if necessary).
  5. Import backups of old filters (only if you were a previous ARIS user).
  6. Import backups of old databases (only if you were a previous ARIS user).
  7. Create the required databases.
  8. Configure the filters to be used.
  9. Define access for all the user groups\users on the databases.
  10. Create the base folder structure and library models.
  11. Train your users and get started.

The next thing you should start looking at is managing the benefits that your Business Process Management (BPM), Enterprise Architecture (EA), System Development Lifecycle (SDLC) or whatever else your focus is, should deliver to your business. To do this, you will need to have good report scripts to showcase the information and value that you have built into the ARIS repository, publish the process content for transparency, proactively support business units/projects to deliver on requirements and generate deliverables. We can discuss this in more detail in a next discussion.

Standards
You should also consider aligning to world-wide standards when deciding on which frameworks and model types you should be using. This will reduce costs on training where users have been trained on some of these standards and you can find more support for standards than being on your own path.

Frameworks (these and more can be found online):

  • TOGAF
  • Archimate
  • UML
  • The Zachmann Framework
  • DoDAF

Model types (by no means extensive):

  • Value Added Chain Diagrams
  • BPMN
  • EPC
  • Function Allocation Diagrams
  • Application system type diagrams
  • UML model types

What you choose to use would depend on your requirements and your ultimate goal using ARIS.

I am in no way associated with Software AG. ARIS is a trademark of Software AG.

Leave a Reply

Your email address will not be published. Required fields are marked *