AE Stories

It's an eternal clash that comes to mind when building information models: should we allow attributes in our conceptual information models? Should we plead for simplicity, or is a complex model based on the stakeholder a better choice? This blog post aims to bring clarity to the discussion, before the clash results in a total loss.

I recently saw a funny video in which a couple were arguing over something trivial while they were getting out of a car.  While they were engaged in heated discussion, their car started to roll back slowly, and by the time they realised the car was moving, it had gathered too much momentum for them to be able to prevent a crash—which luckily didn’t cause too much damage.  This scenario reminded me of a few discussions that I’ve been part of or have witnessed myself in the past few years on one particular subject: should we allow attributes in our conceptual information models?  While believers and non-believers—usually architects—are involved in this endless non-argument, the engagement and buy-in of business stakeholders and analysts is rolling away faster and faster, right behind our backs.  Even before the argument is settled, all hope of adding value and using conceptual information models constructively within the organisation has long faded, resulting in a total write-off.

Ivory tower architects

Ivory tower architects.  I can’t help but feel a cold shiver down my spine when I hear those words.  There have of course been times when this insult was hurled at me too.  Every (enterprise) architect who looks further than the end of his or her own nose (and by definition, that should include every one of us) has probably been in a situation where this criticism was levied against him or her.  In those instances where the levying party was someone who didn’t have the ability to look any further ahead than the next project, the architect could probably live with those words.  However, that little phrase carries a lot more weight when it comes from another architect or vision-driven person.  Still, this is exactly what I want to talk about here.

Why?

Because enterprise information architects are entrusted with the task of teaching organisations the most appropriate information and data models, and getting these models established in the general enterprise architecture. A good theoretical foundation is essential in this process, but only on the condition that it is applied to the specific situation of an organisation. If this doesn’t happen, it will result in a crash that will most likely look a little as follows:

• The organisation has too few people to keep all models up to date or to deliver them.
• The models in question can only be created (and understood) by an elite club within (or outside of) the organisation.
• A lot of documentation is generated, but none of it is ever read and it soon loses its value.
• Business owners need to approve the models, but this becomes more of a formal obligation than a useful tool.

Are you one of those business stakeholders who has found themselves trawling through information models with an increasing sense of confusion and frustration? Or worse still, have you ever had to sit and listen to an analyst trying to engage you in a completely incomprehensible story? Or maybe you’re an analyst who has been told to create all kinds of models with a ridiculous amount of overlap, continually wondering why any of them are needed?

Well, there’s no need to despair, because it doesn’t have to be that way.

Janice from Accounting

Knowing what you’re about to model, in what level of detail, using which models, who for, why etc. are crucial questions, and there are a lot of decisions to be made while looking for the answers. To many people, those questions might seem like remote concerns, but they do have a direct impact on workloads, because they might result in extra work, require new tooling or new knowledge and so on.

You might recognise some of these questions:

• Is there an enterprise information model, or just domain models? How do we link domains?
• Do we adopt our model from a package that already offers data in service/APIs?
• Do we stay completely application-agnostic in our models, or do we adopt what our main vendor is offering?
• How much traceability, lineage and mapping should we document between different levels of models?

And then there’s the question that video reminded me of: Should you keep the BIM (Business Information Model or Conceptual Information Model - CIM) as simple as possible by avoiding attributes, or is it necessary to add all attributes to be able to use a richer model as a basis for the organisation? Different arguments have been put forward by different people at different times, and I’ve summarised a few of them below:

Most architects can probably add a few points to those lists.  As an architect, I’d love to delve a little deeper into which of these arguments makes the most sense, and how I would interpret them in the context of a specific customer.  But I’m not going to do that, because I’d only be alienating my business audience.  In fact, here’s something I use to remind myself not to fall into that trap: John Oliver's "Janice from Accounting".  Redacted somewhat for more sensitive eyes: “Janice from Accounting don’t give a f***”. 

Handbrake on

Yes, I realise I’ve probably gone into too much technical detail already for most of my business readers, and I’ve lost a fair few of you along the way.  If you have made it this far: congratulations.  I promise you’ll figure out how this affects you soon...

Instead of having a never-ending discussion out in the open or behind the scenes, the first thing we should be doing is secure the car by pulling up the handbrake.  In this case, that means having an open dialogue with business and other stakeholders about impact and consequences.  Why should you invest in a good BIM? Because you’ll soon feel the pain when even the most basic concepts are interpreted differently in different projects, which leads to incorrect implementation and unreliable data as well as lots of frustration, misunderstandings, discussion and wasted resources.

If that sounds familiar, you now know the ‘why’. We’ve already looked at the ‘what’ (BIM), so that leads us to the ‘how’.  You should know that there are different ways to set up a BIM, so it’s all about keeping your eye on the prize.  You were familiar with some of the reasons why we need a BIM, so next, you’ll want to know in concrete terms what to expect once you have a BIM.  Which discussions will it be able to prevent? Can the architect provide empirical insight, through extrapolation, into how much time and rework you will be saving (e.g. “right first time” KPI)?  

It’s during those conversations that the outlines are drawn of what must be included at all cost from a technical point of view, and what the impact will be in all areas (people, processes, technologies).  And that’s without talking about theory or models.  Taking on board the objectives of stakeholders before getting into (internal, behind the scenes) discussions between architects usually results in a relatively quick validation.

The BPost effect

During one of my training sessions, one of my colleagues served me a taste of my own medicine.  I regularly ask senior colleagues to attend the sessions I host, because this usually results in great discussion and is guaranteed to provide enriching practical examples, every time.  The subject was CIM or BIM, and I was explaining to a room mainly filled with beginners why you should only model core business concepts at the highest level.  One of the consequences of this decision is the fact that you won’t always be able to use a ‘decomposition’ relationship for impact analysis in your logical models.  I usually illustrate this with the following example: it’s fine to have “customer” at the highest level, but “address” is not really at the core of your business, so in most cases, you’re more likely to only start looking at the latter at logical levels.

Even before I could finish my sentence with “but it all depends on the context of your business”, my colleague piped up to say that one of his customers not only includes “address” at their highest level, but also covers a significant amount of address detail.  That customer was BPost, the Belgian national postal service.  Of course, “address” is crucial to them, and no one will fail to understand the sheer added value provided by the fact that this attribute has a single, consistent and well-documented definition and interpretation across the whole of BPost, and that this definition and interpretation is supported by its top management.

One-nil to my colleague.

Summary

It is incredibly important for information architects to have enough of a theoretical background.  It is even more important that they are able to drill down into that theory deeply enough to understand its origins.  However, to turn information models into a success, it is also important that we only ever start from a highly stakeholder-focused perspective instead of allowing theory to hold sway over everything.

Models should be adjusted to ensure they best support their actual purpose: to foster clarity and understanding for different stakeholders, to ensure impact analyses and change can be managed properly, to make maintenance a less daunting prospect etc.

That’s what decides whether or not we allow a certain attribute in a CIM. End of discussion.

Liked our Blog post? Share it with others!