ARIS for Everyone

Article by George Smith
Senior Business Analyst - Information Systems

You might be aware that for the last couple of years, Swinburne has been creating Business Process Models using a piece of software called ARIS. But ARIS also allows you to build other model types that describe, amongst other things, the underlying Information Systems that exist to support the business processes. If you are used to using a traditional drawing and diagramming tool such as Visio, you might have the idea that a model is a useful thing to have, but ultimately, “just a pretty picture”.

ARIS is different because it incorporates a database which allows Objects (chunks of information that describe things) to be defined once and re-used many times in different models – and in different types of models. So, for example, whilst modelling a business process we can identify that a system like ASCOL supports a particular function.

We can then construct a “System Profile” type model that provides some general information on that system such as the Hardware and OS and RDMS, also information on who owns the system, that kind of a thing – which will look like this:

And then, to complete the picture, we can also build models that describe our infrastructure – for example, a topology diagram that will show “All of the hardware components in a particular server room”

Each of these objects has many, many standard and user defined attributes, and so an entire library of information can be held on each object. So as you build up your models, you start to develop a real picture of how the business is put together, and the things that it needs to do its job – and who does the job as well, if you get really eager.

More interestingly, because every object is stored with a database, you can run queries and reports to identify critical items, and then display the attributes stored against it.

You can ask the question “what is the point of all this”. One answer is Disaster Recovery.

In the event of a catastrophic event we can now, with a reasonable degree of confidence, explain the impact on the business in terms that mean something to them, and we can do it relatively quickly.

Example:

• Enrolments are important
• ASCOL supports the Enrolment function
• The AS400 that runs ASCOL is located in EN Server room

So If the EN server room gets destroyed by rampaging AFL players, then no enrolment will occur.

This same process allows us to demonstrate “traceability” , so if the business ever comes to us and asks the question “what do we need X for anyway?” then we can show (in at least the Student Management arena anyway) the reason for a particular piece of technology (application or server) existing. And we can start to take an architectural approach to the management of our systems.

If you have any questions on this topic, give George a shout on ext. 4550.

Feedback on this article