Home / Support for EA Modelling With eaDocX / Insights / Mechanical vs Content Quality

Mechanical vs Content Quality

Mechanical vs Content Quality - they are different, and can be checked differently

I’m currently working with a client who is capturing a load of project knowledge into a single (EA) repository, pulling the skills & wisdom of 20-30 IT experts into one place.

Before they started doing this, they split up the problem into bits, so that each modeller could work semi-independently of the others, and not have everyone trip over everyone else. And this worked well for quite a while. They even had a small part of the model for obviously re-usable stuff, such as master lists of Actors and Components.

Now they are starting to put the bits together, and some other problems are emerging. To help them to make their model more consistent, and easier so other people to understand and re-use, I’ve been creating a family of tools & techniques to help them.

We’ve chosen to think about the errors into the model is two broad categories:

  1. “Mechanical” errors, which can be fixed by applying some simple (ish) rules, with minimal human involvement and bags of automation. Mechanical errors are self-defining: they are the kinds of errors which can be found by mechanical means.
  2. “Content” errors, are where, even though the ‘mechanics’ are correct, the model is  still wrong. These can’t be fixed – or even detected – by mechanical means. Another human needs to look at the content and think hard.

The remainder of this post is about the mechanical errors, and talks about using some new techniques we’ve used to find and fix the problems for users of Sparx Enterprise Architect.

Deciding what it's supposed to look like

Finding mechanical errors is about deciding what you think a model should look like, then checking to see if model looks that way.

There are some things we need to describe when defining what a model should look like:

  • Which types of element you should use (e.g. ‘Requirement’, ‘User Story’, ‘Stakeholder’)
  • Which stereotypes of those elements you should use (if any) e.g. you might decide to have <<Functional>> and <<Non function>>Requirements
  • Which links you allow between those elements/stereotypes, and what those links mean
  • Which of the built-in or additional attributes you’re going to use (in EA, additional attributes are called Tagged Values). For example, you might decide that each ‘User Story’ has an attribute called ‘Story points’, which, in EA, needs to be a Tagged Value
  • What kinds of diagrams you are going to draw, and what they should/may/must contain

A description of this is called a meta-model: a model of what a model should or does look like. Some people call this an ontology, which is a shame, because even most first-language English speakers don’t know the word, so I won’t use it again. But’s it’s in the article now, in case some smart person Googles it.

Your model may be very large, but may still have a simple meta-model. For example, if your model contains 100s of Stakeholders and 1000s of Requirements:

then your meta-model is really easy:

This says you’re only allowed two kinds of ‘thing’, and one kind of link between them.

But in reality, meta-models are much more complicated. The only I’m working on at the moment – a blend of Archimate, UML, BPMN and some bespoke stuff, – has just over 100 types of element, and a few 100s of possible types of link between them.

And that’s just what it’s supposed to look like: when we look at what individual modellers have done, there are quite a few more, which shouldn’t be here.

You might say at this point that we should have decided what kinds of ‘things’ our model should contain before we started. This is excellent advice, but sadly, at the start of the project, we didn’t know what we’d need, so the meta-model has evolved very quickly.

This model of ‘what the model is supposed to look like’ we have called a ‘Reference Model’. If the meta-model which see in our day-to-day model is the same as the Reference model, then we have no (mechanical) issues.

What we have developed is set of tools which allow a day-to-day model to be analysed and fixed, by comparing it to a Reference model.

What we do is:

  1. Analyse the day-to-day model to see what it’s reference model is like: it’s meta-model
  2. Compare that meta-model to the reference meta-model, to see where it differs: where we have issues, or ‘violations’
  3. Finally, once we have identified the issues, fix them.

See Model Expert for more details

More Insights

Process Modelling with Style

25 August 2020

There may be more ways to model processes than you think

Learn More

Models matter - nearly as much as deliverables

25 August 2020

Models matter - nearly as much as deliverables

Learn More

Fixing your meta-model

25 August 2020

Fixing your meta-model too early is bad

Learn More

Advice for the new modeller #2 - (not) Melting the Pan

25 August 2020

Advice for the new modeller #2 - (not) Melting the Pan

Learn More

Advice for the new modeller #1 - Modelling The World

25 August 2020

Advice for the new modeller #1 - Modelling The World

Learn More

Knowing when to give up

25 August 2020

Knowing when to give up makes for better Business Analysts

Learn More

Diagram Graphics for Adults

25 August 2020

Diagram Graphics for Adults

Learn More

Decision, decisions

25 August 2020

Documenting your decisions makes models more useful

Learn More

Beck's Abstraction

25 August 2020

Possibly the best model abstraction in the world

Learn More

A time for Packages

25 August 2020

A time for Packages

Learn More

Ideas in diagrams

25 August 2020

How many ideas are there in your diagrams?

Learn More

Model Driven Analysis

25 August 2020

What is it ?

Learn More

"Look at me" Diagrams

25 August 2020

"Look at me" Diagrams - and why they are usually bad

Learn More

Why we model

14 August 2020

A short argument about 'why we model' which you might want to re-use

Learn More

Model Curation techniques for EA - #1: Cleaning

14 August 2020

Cleaning your model before you let other people see it

Learn More

Model Provenence

14 August 2020

When you look at some modelling work, knowing where it came from is vital information. This article explores some ways to capture and use this

Learn More

Getting to the Point

29 July 2020

How to help your stakeholders with documents that communicate efficiently and effectively.

Learn More

The Well Dressed Model

28 July 2020

Seven ways to organise your EA models so that other people can understand them

Learn More

Choosing Your Subset

27 July 2020

One of my occasional pleasures in helping people to do better modelling is to tell them the things they DON’T need to do. And ...

Learn More

Webinar - Working with Interactive Documents

17 July 2020

This webinar from the EA Global Summit 2020 describes how to generate interactive Word documents, and use them to automate your EA model updates.

Learn More

Webinar - How to successfully scale up your EA modelling team

30 June 2020

The key issues and decisions to consider when scaling up your modelling team, and how to avoid the common pitfalls.

Learn More

Model Curation techniques for EA – 2: Navigating

16 April 2020

This is the second article in the series which describes simple techniques to improve the effectiveness of EA model sharing.

Learn More

Model Curation techniques for EA – 3: Validating

16 April 2020

So now users can find their way around successfully. The question is, what will they find when they get there?

Learn More

Explaining the General with a Specific

16 April 2020

Explaining ideas using Object diagrams

Learn More

Different documents for Different People

16 November 2018

How to tailor information to each user - making it as easy as possible for everyone to engage with your work, project or deliverables.

Learn More

Document or Model View?

21 May 2018

Use your documents as an alternative to Model Views.

Learn More

Color your Knowledge

25 April 2018

A while ago a client asked me to look at some process diagrams which had been created for them by a well-known consultancy.

Learn More

Model Curation

6 March 2018

How cleaning, navigating and validating your EA model makes sharing and collaborating much more effective.

Learn More

Context - Where are we?

20 October 2017

I’m occasionally asked “What’s the most re-usable bit of a model – where should I start?“.

Learn More

Glossary

12 October 2017

In a recent talk, I asked the audience of about 100 BAs which of them maintained a glossary as part of their work.

Learn More

Hard and Soft

11 October 2017

No, not about Brexit… More about styles of Business Analyst.

Learn More

Printing connectors

18 October 2016

Creating documents that start with the connections between the things in your model

Learn More

Using Multi-hop relationships to display Branch/Merge with EA13

11 August 2016

One of the most common requests we see from new EA users is: "Why can’t I do branch/merge with EA?

Learn More

Compare pricing and features

Choose the eaDocX edition that’s right for you and your team

Compare Pricing

Download a free trial

Take a free, no obligation, 30-day trial of eaDocX. Discover for yourself why it’s the world’s best-selling Enterprise Architect extension.

Download