The term “mobile information management” (MIM) has been used a lot in our space over the last few years, but what the heck does it actually mean? Since it refers to a concept and not a specific technology, it’s been used in many different ways. Still, it’s interesting to look at how different forms of MIM could come to be.
First, there are a few things we can clear up pretty easily:
Is mobile file syncing MIM?
A few years ago, sometimes mobile file syncing or mobile content management or any of the other technologies that fall under what Gartner is now calling “enterprise file sync and share” (EFSS) would occasionally be called “mobile information management” or “mobile data management.” I know about this because I did it too. But now that the EFSS market is much more well-defined, there’s no more confusion here.
What about the purest form of MIM?
Another way to define MIM is in a very strict, pure way. The logic goes something like this:
We have MDM technology for when we want to manage the whole device. Many MDM policies, especially with earlier iterations of MDM, treat everything on the device the same—no distinction between different types of information or work and personal stuff.
Next, we got mobile app management, which can shrink the scope of what IT controls down to the app level. We don’t have to worry about the entire device or users’ personal apps that may be on it—we just worry about managing work-related apps. People love this because it makes it easier to use the same device for work and personal.
Now taking that idea even further, a very narrow hypothetical definition of mobile information management could be to shrink the scope of corporate control all the way down to the data/information/file level itself. If our policy was attached to that level, then we could theoretically free our users to choose any app to do their job.
This sounds great, but unfortunately it’s impossible. Even if we’re somehow embedding our management policies down at the data/information/file/whatever level, the app that’s used to view or manipulate the data has to be able to interpret our policy, and we have to trust that it will do so faithfully.
A more practical definition of MIM
So it seems that our previous definition of MIM doesn’t work because the apps involved have to be a known entity. But let’s say we’re okay with that, and we use this definition instead: MIM can mean an app that’s smart enough to differentiate between different data sources, or can interpret policies and permissions that come with the data.
Imagine an app that knows that I shouldn’t be sharing confidential internal planning documents with anybody outside of my company, so it turns off sharing features. At the same time, if I use it to write down a recipe for pie, it will let me post it to Facebook with no problems. (Credit to Brian Katz for writing about this definition of MIM quite a while ago.)
There are plenty of examples out there: There are document editors and email clients that support Microsoft rights management settings. The iOS email app can have different policies for personal accounts and for work accounts that are managed with MDM. Dropbox now lets you have work and personal data in the same app, and IT can’t see into your personal stuff.
So this definition of MIM is starting to become a reality today. Note that this doesn’t need to apply to all apps—just the subset of apps that are used for work and personal. Users love this, too, since they can see a more converged view of all their data without having to go back and forth between different apps.
Does the future of MIM look a lot like DLP?
Many current examples of MIM classify the data as work or personal, or an an account basis. The next logical way to extend this is to get a lot more advanced with how you classify data. Instead of just work and personal, you could get more granular and have different policies for work things that you want to share (marketing materials, etc.) and things you need to be more careful with (sensitive intellectual property, data that falls under compliance rules, etc.).
There are apps that let you do this to some degree. A lot of EFSS products let admins set policies on a per-repository, folder, or file basis. There’s even talk of apps that can use the content of the files themselves to build policies.
But wait—this is starting to sound a lot like standard DLP techniques. Is this a good thing? Or is it a bad thing? There are a lot of benefits to having more granular policies around data, and it could go a long way towards making enterprise mobile apps easier to use. (I’m thinking mostly by freeing up unnecessary restrictions as much as possible.) On the other hand, DLP hasn’t always had the best reputation. It can get complicated and cumbersome very fast.
One thing that makes these scenarios easier to deal with is to recognize the difference between user-generated work content and institutionally-created work content. We’ve talked about this before at BrianMadden.com, but the basic premise is that it’s a lot easier to classify and protect data that the company is pushing down to the user. (For example, if a company is publishing master revenue reports each week, they can always just put them in a folder with locked-down permissions.) But for user created-content, we can give them the right tools and the right training, but we know that ultimately they may or may not classify and protect that data correctly. All we can do (as David Stafford puts it) is pray for data ingestion.
If we apply this user-created versus institutionally-generated concept to the MIM/DLP apps we’re talking about today, it’s clear that anything requiring users to do data classification on their own could be a pain, but the other way could be much more successful.
So what do you think—could this advanced concept of mobile information management become a reality anytime soon? Or is it still a stretch to just be pushing for apps that can handle work and personal data at all?