5 Steps to follow when implementing ARIS customized requirements

ARIS is recognized as being one of the leading enterprise architecture tools by all the analysts, in addition to supporting in excess of 150 modelling methods it is also infinitely customizable. A powerful attribute of the tool is that configuring ARIS customized requirements is fast, easy and requires no coding meaning you can adapt modelling use to support almost any scenario. However to harness this power you need some knowledge about what not to do and some creative thinking.

One of the most common questions we get in delivering ARIS training or troubleshooting is:

 “The tool is great, but would be even better if it could support X”

X being a specific domain application or architectural component such as; product lifecycle management, master data management, security architecture etc.

Our usual answer is:

“We're pretty sure it can.”

To which the immediate reply is almost always something like:

”No you can't, I've searched the entire method library all 150 odd model types and there is nothing there that remotely supports X.”

We would generally say:

“You are probably right, but we're still pretty sure it can be done. Tell us exactly how this needs to be done here.”

After some discussion, a prototype of the concept can usually be fleshed out and put together in a couple of days. Concept to production can take as little as a week and quite often whatever you are trying to do, it has probably been done before (the tools have been around for 15 years).

There are a number of simple steps to execute this and any other creative requirement.

 1. Find the right questions to answer

• The result of the exercise will be specific information in your modelling repository.
• Unless you can clearly articulate what information is needed to answer specific questions or advance understanding about the business and the value of this information, you should stop and think some more.

2. Agree how the questions will be answered

• Models in the repository are of no real use unless they can be accessed.
• Either relevant information is published, output in a report or used in a query for analysis.
• If you can’t describe how the information will be used in the real world (project, business planning, roadmaps etc.) you should definitely stop now and think some more.

3. Define the information you need to realize the concept

• Define exactly how you will represent them (architecture types will call this a metamodel) and how they will be managed through a defined lifecycle.
• This includes key relationships that may need to be defined between key pieces of information (objects) and any other information (attributes).
• In addition define how this information will be depicted, that is what symbols you will use and what defines a specific set of this information to be managed – in a model.

4. Determine where the information is now

• Most of the content users seek to capture and represent in models already exist within their organizations. These are in the form of spreadsheets, PowerPoints as well as the un-documented knowledge that inside your team’s heads.
• Find the sources of the information, make sure it is up to date and make a plan to upload it to the repository en masse preferably . This can usually be accomplished quickly and easily.
• If you can’t find the information, then you need to make a plan (usually a project) to create the information. If you find it difficult to do either then clearly you need to revisit the capture state above.

5. Assign accountability and execute the concept.

• If no one is responsible for managing this information, it will not work.
• Executing the concept means tying off all the things needed to make the concept real including;
  • defining semantic checks,
  • updating training material and
  • communicating to the business.
• Lastly, it will include writing queries or report scripts that are the realization of what was defined as important in step one

Many standard ways of depicting conceptual information already exist and are well defined  (such as OSA for security architecture). Translating your specific requirements into the ARIS context requires specific knowledge and experience in the tool. While this is knowledge is more specialized, it is probably the easiest part of the process (yes, this is a process…).

Most importantly, if you can do steps one and two successfully, but can’t clearly define your concept that integrate into your wider collection of methods in ARIS terms,  you should  stop and think some more.

We recommend getting some help at this stage. A couple days of expert advice will save you a lot of time and effort down the line.  

Let’s look at a quick summary of how this played out with the client;

Step One:

• Security Architecture designs needed to be constructed for each aspect of the technology portfolio, as this was a ‘greenfield’
• Security designs need to be provided as part of the overall design package to be signed off for each project stream.
• Understanding how security impacts the design of the technology portfolio and how this information is managed is a key requirement for the customer.
• The client had already determined that the OSA framework was to be used and it is agreed with all key stakeholders that this initiative is extremely

Step Two:

• The design information will be ultimately provided in the form of a document with all the models, risks, threats, mitigations etc. In other words a simple report – this is how the information is to be
• The second requirement was understanding how specific components (threats and vulnerabilities) were distributed across different technology platforms. In other words there was a need to define some specific queries that may be used in a report.
• Document templates for these reports had already been developed providing an understanding of exactly what information was

Step Three:

• Because the OSA framework has already been specified it provides the specific directives about what and how information is captured. In the case of OSA it is quite comprehensive with many components as illustrated in the example security pattern below;

Because the framework are freely available and the symbols specified these can be quickly updated within ARIS once it is understood how the components integrate with the existing Enterprise Architecture approach as shown below.

Additional information requirements such as those from the document template or other external sources can also be defined as shown below;

Once the representation concept was completed, a process and governance structure was defined around how all the components are managed in the repository. This included links to external sources of information that can change over time (e.g. the threat categories in the example below).

Step Four: As this was a Greenfield site, the key existing information was sourced through the OSA catalog above and an external reference database. This information was imported via excel, and the library models automatically generated. Semantic checks defined and a number of other necessary repository tasks configured.

Step Five: Communication and conventions packs were put together and presented to key stakeholders along with some reference examples and the concept was executed.

All up the process took about 3 weeks from conception to delivery with about 5 days of Leonardo Consulting assistance.

The most common troubleshooting queries we get from clients is when this process has not been followed. Typically unwinding the problems takes more effort than taking some thinking time up front.

By far the most common mistake we see organizations make is doing this process in reverse. There is a natural inclination to take a tool, start modelling this world and then ask what is in the tool that we could possibly use. It’s a bit like building a house with all its rooms, and then going in with a hammer to knock out where all the doors and windows should be.