Home / Support for EA Modelling With eaDocX / Insights / Organising an Enterprise Architect Model

Organising an Enterprise Architect Model

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

  • If you have spent many hours creating a great EA Model, hopefully you want the rest of your organisation to use it as well. But how can you make it readable?
  • Or maybe have you just picked-up a model which you created a few years back, only to be baffled by your own work. What exactly was this model all about, and where has all that great stuff gone ?
  • Or perhaps you’ve inherited a model from someone else who isn’t available to tell you what’s in it. How are you supposed to sort out what’s complete and useful, from the ‘other stuff’?

Over the years, we’ve come across all of these several times, and have developed a few tricks to avoid them.

If you have more techniques for helping other people to understand your models,

please let us know.

1. A Package is not a Bucket

The most important ‘thing’ in EA is definitely the Package. It’s also the simplest. Just a folder with stuff in it, right? Wrong.

The Package or rather the family of Packages which you create, say more about your model than anything else. If you just use them as a bucket to put things in, then you’re missing-out on a critical way to communicate the intent of your model.

Some rules for Packages:

  • Sensible names. It may seem amusing to call a package ‘new stuff’, but nobody else will ever look there to find anything. If it’s ‘new stuff which was invented in the meeting..’ then call it that.
  • Descriptions. A Package without a description isn’t just half-dressed, it’s practically naked. There is always something you can say about what’s in the package, where it came from, whether it’s finished or not.
    I suggest that anyone who creates a package in a shared model and doesn’t add a description should buy the coffees for all of next week.
  • Authors. EA will make the Author of the Package the person who created it. But go further, and make the Author the Owner of the information in it. So, even if someone is totally confused at what’s in the package, they can always email the author…

2. Notes, notes, notes

I’ve been teaching UML and other modelling techniques for more than 15 years, so apologies to all former students for repeating this. If you’re in that select group, can you remember the most important UML (or BPMN, or SysML..) modelling construct ?

The Note. The humble note.

They don’t cost anything, they never run out, and they can communicate more about why your diagrams look the way they do than anything else.

Add them to elements, to links, to anywhere you can think of. But make sure to keep them up-to-date: a diagram with misleading notes is worse than one with no notes at all.

3. Single-purpose Packages

If you’re going to follow the rules above, and describe what’s inside each package, then having one, or a small number, of different types of ‘thing’ in a folder is sensible: it’s easier to find things, and easier to write a quick description.

This also becomes important if you are going to document your model using a document generator – either RTF or eaDocX.

A Package with one type of thing in it can be documented as a simple table, with the Package name becoming a title for the table.

4. Different things get different stereotypes

The idea of the Stereotype is one of the key ideas of UML, which EA has extended to cover all the other model types it supports. So whether you’re creating SysML diagrams, BPMN business processes or Use Cases, you can use stereotypes.

So use them.

A stereotype is just a ‘special kind of’ thing. So if you have use cases which are sometimes complete (all scenarios filled-in) then make them <<fully dressed>>Use Cases, or if not <<partially dressed>> . So a reader finding one of these will know whether it will be completed or not: they know what to expect.

The same can be true of any other element. Using a stereotype can tell your readers what they are looking at.

Stereotyping also makes it easier for documentation tools like eaDocX to change how they format their outputs. For example, a <<fully dressed>> Use Case should print its scenarios, and highlight where they are missing – that’s an error. But <<partially dressed>>Use Cases don’t need to.

5. Status is everything, or Somewhere to Play

When you read a model, probably the most common problem is that you don’t know what the status of something is: a diagram, an element, or a whole package of the model.

Is this completed, signed-off and implemented, or just some ideas I had over coffee one day?

So using the EA ‘Status’ fields (with some sensible values) is really, really useful to readers.

But you can do more to help separate the ‘finished’ content from the ‘just thinking’ stuff.

Why not have an area of the model which is just a sandpit? Somewhere where modellers can try things out, and to which no standards apply. Readers are not encouraged to look in these packages. Everything is work-in-progress or incomplete.

Equally, the areas which are for ‘real’ content DO obey all the local rules: packages must have descriptions, only the approved stereotypes are used etc.

6. Public and Private diagrams

The great power of EA is that it allows us to create links between all kinds of elements, depending on what kind of problem we’re trying to solve.

There are several ways to create these links: the Relationship Matrix is a quick way, but diagrams are also very common. And this creates a problem for the reader.

Are they looking a ‘proper’ diagram, which they are supposed to understand, or is this a diagram which you just created to establish some relationships, and isn’t really for public use?

So get used to naming diagrams so that this is obvious, and to prevent accidental printing of these diagrams in documents.

Pick a naming convention for ‘do not print’ documents: we add ‘hidden’ in front of the document name. We’d like to use a diagram stereotype, but that doesn’t appear in the Project Browser. So ‘My untidy diagram’ becomes: ‘Hidden – my untidy diagram’. We also tick the box in the diagram properties to “Exclude image from RTF Documents”. Both the EA RTF generator and eaDocX will take this to mean ‘don’t print in any document’.

So now you’re free to create as many untidy diagrams as you like, and readers will know to ignore them.

7. Pick a meta-model, write it down, and stick to it

This final piece of advice is really a summary of all the others.

Each idea we’ve discussed above contributes to your meta-model.

If that sounds like a scary, super-technical idea, it isn’t.

All of your EA models already have a meta-model, whether you know it or not. The meta-model just says what kinds of ‘stuff’ is in your model.

  • What kinds of elements have you used? e.g Requirements and Use Cases, but not internal requirements,
  • How have you linked them together?
  • What stereotypes have you used, and what does each one mean?
  • How have you used things like Element Tests, the Glossary, or Project Tasks?

..so not really complicated. The meta-model is just your local modelling standards.

If you want to find out what your meta-model is, use Model Expert. It will draw a diagram of all the element types, stereotypes and links in your model. Be prepared for a surprise! Big models can be complicated!

This is a good reason to make your meta-model clear and simple. Pick a small number of elements, stereotypes and links, and use them consistently.

Communicating the meta-model is critical: one which only you understand is no use. It MUST be written down, preferably in the model itself, and taught to all of your team.

AND kept up-to-date, as your modelling style evolves, as it will certainly do.

More Insights

Using Excel to create an EA dashboard

16 February 2021

A simple example of an EA dashboard, to show how you can create your own and show the information in your EA model to your project team

Learn More

Where's the best place to start modelling?

19 October 2020

Advice for the new modeller #1 - Where do you start?

Learn More

Process based model styles

25 August 2020

How to use BPMN and UML to make models which last.

Learn More

Models matter - nearly as much as deliverables

25 August 2020

Models matter - nearly as much as model deliverables

Learn More

Improving model quality using a Sparx EA reference model

25 August 2020

Maintain quality with tools to find and fix mechanical errors in your modelling

Learn More

Fixing your meta-model

25 August 2020

Advice for the new modeller #3 – Fixing your meta-model

Learn More

How much domain modelling is enough?

25 August 2020

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

Learn More

What needs to be included in your EA model content?

25 August 2020

Advice for the new modeller #4 – (not) Modelling The World

Learn More

Knowing when to give up

25 August 2020

Knowing when to step back makes for better Business Analysts

Learn More

Using UML icons for more useful models

25 August 2020

Diagram Graphics for Adults

Learn More

Using Enterprise Architect to document decision making

25 August 2020

Make your models more useful for future modellers

Learn More

Beck’s Map: an EA model abstraction example

25 August 2020

Possibly the best model abstraction in the world

Learn More

Use case, package or process?

25 August 2020

A time for Packages

Learn More

Simplifying ideas in a BPMN Process Diagram

25 August 2020

How to find the right number of ideas to include in your model.

Learn More

Explaining EA Sparx Systems to non-modellers

25 August 2020

Model driven analysis - the best way to define what we do?

Learn More

How to simplify BPMN Data Models

25 August 2020

Why simplifying your diagrams can actually make them more informative.

Learn More

Create useful models using the Sparx EA Tool

18 August 2020

Advice for the new modeller #3 - Producing useful outputs with your new EA tool.

Learn More

Beginners guide to Enterprise Architect software

18 August 2020

Our advice for new EA modellers

Learn More

UML Business Analyst Solutions

14 August 2020

Using UML to resolve inconsistencies, gaps and overlaps.

Learn More

Cleaning: How to Simplify Enterprise Architecture Models

14 August 2020

Model Curation Techniques # 1 - Cleaning your EA model before you let other people see it

Learn More

Including Sparx EA Model Provenance

14 August 2020

Sparx EA model help to explain to others why your models look the way they do.

Learn More

What to include in your enterprise architect documentation

29 July 2020

How to create documents which communicate your ideas efficiently and effectively to stakeholders.

Learn More

Choosing Your UML Subset

27 July 2020

Narrowing down the modelling ideas in your Enterprise Architect model to make consistent, understandable models.

Learn More

Webinar: Using Interactive Documents to Collate Sparx EA Model Feedback

17 July 2020

A webinar from the EA Global Summit 2020.

Learn More

Webinar: How to successfully scale up your Enterprise Architect team

30 June 2020

A webinar from the EA Global Summit 2020.

Learn More

Navigating Models: Enterprise Architect Help and Techniques

16 April 2020

EA Model Curation Techniques #2 - Making models easy to navigate.

Learn More

Validation: Improving your Enterprise Architecture Model Structure

16 April 2020

EA Model Curation Techniques #3 - Validating your model

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