Earlier today I saw an IBM storage blog addressing the issue of just what it means to “protect” data.  It stirred a memory …

A few years ago, I was at a project-planning meeting with several senior members at a major storage vendor. The company had sent teams from both their storage and security groups, most of whom were as unfamiliar with one another as many of them were with me. I remember early-on getting a sense that the meeting was not very productive — not a good feeling as I was chairing the meeting.

About 10 minutes into the session, I began to sense what was wrong: it all had to do with the question of just what does it mean to “protect” data. Everyone there certainly recognized the importance of what the other group had to offer, but to the storage guys “protection” was all about data availability and business continuance, and for the security people the term had everything to do with preempting unauthorized/inappropriate access.

Both groups used the same terminology, but the definitions were wildly different and so, of course, were the thought processes of each of the groups. The issue was not one of terminology, but of ontology.

Eventually we all got on the same page, but it had to be a physical page that we could all refer to make sure we were all working with a common set of definitions. (I still often use the metaphor of looking at a “common piece of paper” when working with clients — particularly if they are a mixed group, and even when all of them come from the same large corporation. I even have my own acronym, “CPOP”.)

The result was that a lot of time was invested in doing metawork needed to get us to a common starting point. Only then could we start the project we had originally gathered to work on. I think the time was well spent, but I know it also illustrated an important problem: reaching across two traditional “knowledge domains”, such as security and storage, is a challenge.

I wonder how many senior people out there, trained to be deep in a particular IT discipline, can easily bridge the gap between their own knowledge area and another without having been prepared upfront to think across these boundaries. The trick of course is not to see security and storage (or networking and servers, or any other combination) as being separate but equal, but rather to understand how multiple domains interoperate as a single system. In this context, I wonder how many security people read storage blogs and how many storage people have the inclination (or perhaps, the time) to keep up-to-date on security issues.

I also wonder how many vendors really understand that the logic they apply to one IT group may be counterproductive when used with another simply because the two groups do the same thing in different ways, or perhaps because they do different things in the same way? Interest, knowledge, and even terminology tend to be domain-specific, and anyone looking to address the wider IT audience ought to consider that fact up front.