Little-discussed CASE tool selection criteria

This page is published under the terms of the licence summarized in the footnote.


How to manage the structure and behaviour of business systems if you don’t know that structure or behaviour?

How to plan changes that are optimal for the enterprise (rather than suboptimal and localized) if you have no enterprise-wide repository of the system estate?

On the other hand, why is building and maintaining an enterprise-wide architecture repository more challenging than CASE tool vendors tell you?

(CASE = Computer-Aided System Engineering).


The CASE tools market is (still) not mature; buyers don’t really know what they are looking for.

There are many tool evaluation schemes in the public domain, and TOGAF’s evaluation criteria are all reasonable.

Yet buyers don’t really gets to grips with something that matters above most other things, that is, usability.

This paper does not replace other evaluation schemes.

It draws attention to some features that really do matter when you are using a tool.


The two major functions must be superb and integrated. 1

Fast and easy reuse. 1

Change management 2

Customisable meta model 4


The drawing and recording functions must be superb and integrated

The two major functions of a CASE tool are drawing and recording.

Some drawing-first tools make life difficult for repository maintainers.

Some repository-first tools make life difficult for diagram/view drawers.


You need a tool that combines Power-Point-like drawing with intuitive repository maintenance.

You want to sketch diagrams without saving changes to the repository as you go.

You want the drawings to provide a user-friendly data capture mechanism for repository maintenance.

You want the tool to automatically generate drawings and matrices - filled with objects you have selected from the repository.

Fast and easy reuse

You want to re-use objects by selecting objects in one diagram, then copying & pasting them into any other diagram that can legitimately contains objects of that type.

You want to lasso objects and/or fast click on a selection of objects, and copy and paste the set selected into another diagram.

You want to copy and paste a whole structure of objects from one diagram to another, preserving the physical structure of the copied-from diagram in the copied-to one.

(Power Point has these and scores of usability features missing from some CASE tools.)


And when you paste objects into a diagram, you want to see any relationships it has to objects already in that diagram.

Change management

I struggle to describe well the various change management issues I have come across.

So please don’t treat what follows as a specification of features your tool should implement – as discussed below.

The aim is only to explore change management issues that a CASE tool needs to address somehow.

Ask your tool vendor how they address these issues.

The relationship between the repository and documents that draw from it

When you need an architecture description document, you create it and populate it with artefacts from the EA repository.
That document describes the state of some system elements at the time of document’s publication.
Unfortunately, the state of the EA repository moves on relentlessly, so any document may expire very soon after it is published.


Ideally, every repository item that appears in a document should be annotated with that item’s last update date and time.
That is probably unrealistic. But what to when a repository item changes?

It is probably impractical to update all documents that contain the item (even if the repository owner asks for it).
You should however update a document when the document’s users need it.

At this point, you can create a new document from an old one and re-populate as need be with items from the current EA repository.

You need either help to know which items have changed since the document publication date, or else automatic re-population of the items in the document.

Recording historical system states

At the extreme there are two options:

·         your CASE tool stores every historical version of every item in the repository.

·         your CASE tool records only the current state of the items.

In the latter case, it is the documents published with repository items that store the history of the architecture at different points in time.

The documents should be archived in a repository, as historical records that cannot be updated.

Support for migration planning

A migration path from baseline to target is a sequence of successive versions of a single configuration.

Typically however, most of the objects and inter-object relations are preserved from one architecture state to the next.

You want to maintain the coherence of an architecture description through successive states, stages or versions.

You don’t want to have to populate and maintain each architecture state as separate repositories


Does your CASE tool support migration planning?

Can you define each object and relationship as having a life time from version N to version N+X?

So the tool can display – for any specific version – only the objects and relationships that are alive at that time?

I know only one tool that does this.

Intuitive local/global change

When you add, change, rename or remove an object or relationship in a repository, what do you intend to happen?

You might change something by opening a repository item and editing details in that local context.

A question arises – what happens to drawings that contain the object you have changed?

You might change something in a diagram.

A question arises – what happens to the underlying repository? And any other drawings that contain those objects?


Your tool should help you decide whether an change is

·         a local-only change, affecting only the object or diagram you are working on.

·         a global change, rippling throughout a configuration

·         a change that affects a selected subset of whole configuration.


Some ideas

You may want the choice of local or global change to offered as you edit a diagram.

So when you edit an object name to a new name, a pop-up asks which option you want.

And when you edit an object name to match an existing object's name, a pop-up asks which option you want.

If you select a global change or merge, then a pop up might ask you - save now or later?


You want to change repository entries and diagrams locally, without worrying about the wider effects of your change until you explicitly choose to save your changes.

You want the CASE tool to cache all changes you make until the moment you choose to save those changes.


At which point, you want the CASE tool to offer you the choice of global change or local-only change.

You must accept the tool may reject some global changes – for various reasons – leaving you to decide what to do about that.

You should be prevented from changing diagrams you have no authority to change - by updating objects they contain.


Before saving a change, you want to see the list of diagrams that will be affected by that change.

You might want to select those diagrams that you do NOT want to be changed – meaning that the prior version of your changed object persists in those.

Customisable meta model

You want a flexible repository, you want a readily modifiable meta model.



Copyright conditions

Creative Commons Attribution-No Derivative Works Licence 2.0             10/06/2015 22:46

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited:” before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see