Mobile devices are going to buoy this experience as they represent an always accessible data delivery mechanism. I couldn’t agree more!  There is, however, one small catch. Much of the data that business want to use/share is not stored in the same way that data needs to be consumed.

While there are tools and platforms, such as Hadoop, that work well with unstructured data, many of the data stores that exist today store data in a relational way. For those of you who are not Database Administrators, here’s a simple example of what that means. Let’s take a customer. For any given business, the idea of a customer is someone who has bought a product from the company. If the employee needed to gather information about a customer he or she would probably want information such as number of customers per products. However, in the database there is likely no such thing as a customer. Customer is a concept that could be represented in the data by the following tables:

Person
Address
Order
Product

Each table has its associative fields such as name, date, etc that would be tied to other tables by an ID (which is usually not readable just by looking at IDs). If the employee was given access to the raw data it wouldn’t make much sense to them.  A customer is a business concept, not a way of storing data. Much of the data that exists today is stored in this format. If an employee wants to look up all the customers who ordered product X in the last 90 days, there is work that needs to be done to prep the data in a business consumable fashion.

This problem is multiplied when a business desires to tie together multiple systems and their associative data. The way a customer is stored in one system is probably not how it is stored in another. Each application has slight differences and has slightly different data fields. If you need to merge the data sets together from various applications it will take some tweaking on the data side.

This isn’t by any means a deal breaker, but organizations need to begin to include the effort required in conversations, planning, implementation, and support. The problem isn’t that data can’t be tied back to business concepts in a consumable state, but that data transformation is time-consuming and expensive. It takes not only application knowledge, but business knowledge with the ability to merge the two (not the natural modis operandi of Application and Database Developers). This is also an on-going process that needs to be updated with each change to the database schema.

The way that data is stored in an application is why the notion of an “information Worker’ that Microsoft touted for years never panned out. Microsoft advocated the use of many of their data consuming products by this ‘information worker’ – a quasi-technical individual capable of mining and manipulating data on their own. The trouble is, even if you have a great tool, like Microsoft’s Report Builder, which allows you to drag and drop data sets into a WYSIWYG editor, you still need data in a ready-to-use business state.

What does this mean for mobile? Many of the advantages that we were going to see with the “information work” are now being used as reasoned advantages for consuming data on the phone. For example, users will be able to perform their own analytics or users will be able to build their own apps. I’m not saying this isn’t possible, just that we need to make sure we include in our dialog the amount of effort that will be required to prep the data so that is it readily consumable by an average user.  Our discussion around builing a meaningful mobile ecosystem can’t just be to say create we need to create an API and all will be copasetic. Yes, API’s will create the gateway to the data, but the data needs to be transformed into a business consumable state. Delivering a meaningful experience to the end-user will take bridging the gap between the business and structure of the data.