Part of The Beginning and The End of Information Management.
Organisations have a habit creating silos and then being delighted and self-congratulatory about the value of bringing them back together.
We forget that “silo” is just another name for “team” and your organisation will always be made up of more than one team. Sometimes a “silo” is a team that doesn’t play well with other teams, and sometimes a “silo” is just a team that shouldn’t exist. If you have the wrong portfolio of teams they will all be considered silos but that’s not an attribute of each of the teams it’s an attribute of the structure itself.
This particularly impacts data management because most of the high-value data management effort will be cross-business unit effort. If data management could be performed in a single business unit it wasn’t be difficult – it’s always something that involves multiple business unit.
We build functional organisations and then marvel at the value of cross-functional teams. Henry Mintzberg has mused that we structure our organisations like we structure our business schools. We have HR departments, and Finance departments largely because we have business schools that make people specialise in Human Resources and finance, and they then want to build organisations that they can shine in.
This to me is part of a broader problem of organisations managing themselves for the benefits of their managers rather than rationally or at least cohesively. This is a topic for the Manage Without Them book and ManageWithoutThem.com. But it’s important to understand the principle, often referred to as the Conway’s Law that “Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure”1
Here we address the first problem with typical approaches to information management. If you haven’t heard it already, lots of people will soon want to talk to you about “metadata”.
In the strictest definition, metadata is simply “data about data”. It’s descriptive of the content, rather than the content itself. It’s actually a reasonably useful concept when you first think about it because you need to be able to describe your data; including its features and business context.
However, there are two problems with the concept of metadata. I think both of these problems cause the word “metadata” to effectively kill any conversion it’s included in.
Metadata is broad. So it can be used as shorthand. This is the first problem. There are a number of very different types of information that can be classified as “metadata” so any time one of these is referenced, or a question is raised about how it might be managed – it’s summarised as “that’s metadata management”, which is close to meaningless.
But it gets worse. Because of Conway’s Law (I presume) we split metadata into “business metadata” and “technical metadata” at the first level. By “at the first level”, I mean if you were to structure the different types of metadata as a hierarchy with a series of branches, you end up with the first split being “business” versus “technical”.
When you are trying to get two groups to work together, the worst thing you can do is tell them explicitly as your first action that there are things of concern to you and there are things of concern to “them”. The above view of metadata – splintering in the first instance to “business” and “technical” does exactly that.
It’s worse when you consider how broad the concept of metadata actually is. It’s too broad, and again that’s the first problem. That this breadth of meaning can first be used to encompass just about everything and then be used to split everything down the middle is the second problem.
If you immediately split everything down the centre, without first creating a set of layers that all groups are obliged to develop a shared understanding of, you destroy collaboration. You are basically telling business units and I.T. to work in seperate silos. You’ve used your best chance at promoting collaboration to destroy it.
The first step is to ban the use of the word “metadata” from your information management initiative. Kill it now. This will force you to be specific. Say what you mean. Write what the person asked about in your notes rather than abbreviate it to “metadata”. Never think you are adding clarity be making a vague distinction between “technical” and “business” metadata because you aren’t thinking hard enough when you do this, and you certainly aren’t setting yourself up for effective change and transformation.
Even though you shouldn’t be saying “metadata” at all, you still need to consider what the uppermost split in concepts should be. If not “technical” and “business” what should the top levels of a conceptual hierarchy actually be?
For starters you might consider using the top levels of your hierarchy to seperate the different data assets you have! That would be good start for an information management initiative.
In reality it’s not helpful to think of a hierarchy at all. There are more interesting and useful relationships between different parts of your information environment that will feel natural once you understand them.
Though if you wanted to show the top-level split of the sort of “data about data” you need to maintain it would be more like this:
The concept of “your Enterprise Information Model” is covered later in this book. It covers the areas above – not as a hierarchy but as a set of artefacts that you’ll have to build, revise, and maintain to promote collaboration around your data assets.
In some ways the above view is more complicated than the first view of metadata split neatly into business and technical metadata. But it’s also more specific to your organisation, it’s richer in what it conveys. It also promotes collaboration by not splitting into business and technical categories until the lowest possible point (if at all).
By allowing the complexity of your information to be captured this approach provides you with a valuable tool for managing that complexity. If you don’t start managing complexity – rather than avoiding it – your information management initiative will fail to deliver the promise of value that initiated it.
- 1 1 Conway, Melvin E. (April 1968), “How do Committees Invent?”, Datamation, 14 (5): 28–31,