Telling the Information Management Story

Stories, as my English teacher used to say, have a beginning, a middle and an end. The beginning is the context: in this case the Information Management landscape. The story then becomes a question of determining the value that the user is looking for (the middle) and how a solution (the end) can be put together from the services, technologies, products, or suites to provide that value.

Another thing that English teachers teach you is that you need to understand your plot before you start writing. J K Rowling knew what was going to happen at the end of Harry Potter and the Deathly Hallows before she started writing book one. From our perspective that means focusing on the customer and end user right from the outset. Having a content map is no use if you can’t relate that to real-world problems in real-world companies. So that’s where we come from: we aim to tell stories about products and vendors in context to the overall market in a way that resonates with users.

So, how does our content map help? Well, it is in several parts. There’s a technology sub-map, which is available here; there’s a business value sub-map, which we will be publishing in due course; and there are some components to the map that we use internally, such as lists of vendors, sources of information, and so on.

For the time being then, we are talking about the technology sub-map, which provides the overall context for the story. All stories, after all, have to have a setting, whether that is Middle Earth or Middlemarch. The technology sub-map provides a hierarchy that puts all relevant technologies in context. What we’d really like is a three-dimensional representation that allows cross-referencing and visualisation across branches but that’s kind of difficult to follow; you’d need special software and you couldn’t print it out as a pdf document. So, we’re making do with a two-dimensional hierarchy, with as few overlaps as possible.

The fundamental premise is that there are only four things that you can do with information: store it, govern it, move it around, and retrieve and deliver it. Then there are sub-requirements within each of these: there is physical storage and logical (database) storage; governance we split across discovery, trust, security, lifecycle management (overlap with physical storage), compliance and stewardship; movement encompasses connectors on the one hand and various types of data integration on the other; and retrieval and delivery covers the non-database aspects (that is, not ECM or warehousing) of BI, eDiscovery, search and so on, as well as presentation capabilities like dashboards. Then the structure is broken down further but only in so far as product segments are concerned, not to the level of features or benefits. In due course, we intend to publish a wiki that gives definitions of the relevant sectors identified in the map.

Of course, we expect this map to evolve as new sectors appear and old ones merge. For example, we expect significant consolidation in the security/information management market segments where there is currently a lot of overlap: more platform-based product suites are likely to emerge and, indeed, have already started to.

We would actually argue that it’s not the map itself that’s important (the map, after all, is not the territory) but that it provides a formalised way of thinking about information management. We think that’s important because otherwise it can be all too easy to drown in a sea of acronyms and terminology. We believe that putting structure on things helps us to understand them and to understand relationships across segments (even if they are not easy to draw!). The other thing we would say is that this is certainly not the only way of organising the IM environment, nor are we suggesting that it is even the best way, but we do think that some sort of formal structure helps understanding.