Monday, April 30, 2012

Future File Format: .database

File format wars are way over. The clear winner - now - is databases. Not any particular database, just databases in general.

Why? Because "big data" is now king and to make any analytic use of the quantity of data out there, it needs to be mined in a raw format where the user creates the relationships and presentations in a format that makes the most sense. This isn't the end of documents and spreadsheets - yet - but the excess information to format and structure a static file simply to 'host' data is counterproductive to the real task - the analysis and presentation of the data.

I've used this example before, but the very page you're reading isn't a statically formatted HTML page, but rather built on-demand from a template and a database which contains the text you're reading. The layout of the page is determined by the template and can easily be changed independently from the data that the page presents. In software development, this is called model–view–controller (MVC) concept. MVC separates the tasks of data operation, data presentation and user interaction in a way that is modular and logical.

To leverage big data, you need a database to hold the data - maybe you need relational hierarchies like SQL or maybe you need sheer scale for unstructured information slices implying Hadoop. Other options exist also, but the key is storage of the data is not done in a "file" format, but a database "format". Generating "content" from the data is the creation of documents, spreadsheets and presentations and that can (or will) be done dynamically on-demand. This echoes my previous post about enterprise social platforms doing away with static file formats.

The more I read about big data, the more I see a push to software services, the more I see the traditional operating system become fragmented between local and cloud / processing and storage, the more I believe "database" is the file format of the future.

Wednesday, April 25, 2012

Enterprise Collaboration Education

My previous post talks about enterprise social software and my theory for slow adoption. Basically, as long as enterprises use email as the de facto collaboration standard, we will not see the growth or benefits of truly collaborative platforms.

To expound upon that point, look how humans collaborate outside of the knowledge workers' enterprise. Collectively working on a task does not imply a serial process. In fact, parallel work streams are more efficient and generally more productive when a cooperative group drives an idea forward. Yet when knowledge workers coalesce to produce a deliverable, why do we still create documents in strict, structured, proprietary standards with little flexibility for parallel processing?

My take on an ideal content management, knowledge management, enterprise social collaboration platform is probably pie in the sky. You can incorporate all the profile, following, "Like" button, activity stream, Facebook-like, status update, blogging, wiki, odds and ends since that's what people expect. Of course there is a document dumping ground to provide a web-based front-end for a file share. But what is really needed is online, real-time, editing of content by multiple people simultaneously in a more free-form forum that allows for the manipulation and aggregation of the information in a - or many - customized template for extraction. Sound like a mouthful of impossibility?

This blog you are reading is dynamically generated from the content posts and all the other links and widgets populating a template called on demand as you navigate to this site. This page does not exist in its entirety in the view you see now (save for on caching servers perhaps). That fundamental principle is what we as document creators and consumers need to grasp. Our documentation does not need to live in a neat file format stored away ready for portability should the need arise. Instead, it should be created on-demand and only when there is a demand for the information. Furhtermore, the type of demand (status report, final deliverable) could also determine the amount and/or order of the content presented.

I've done this many years ago eliminating useless network documentation that cataloged switch and router information like serial numbers and part numbers. The information was needed, but was also accessible via SNMP. A script to collect the information and present it in a tabular format was much more useful than maintaining a static document that begged for constant care and feeding when network changes where made. In effect, we used the network itself as a database and the script was a query launched against the database. The information was guaranteed accurate to represent current state as the network itself created the documentation dynamically.

If we've mastered this dynamic documentation skill in some instances, why not where it really matters - on the day to day tasks of creating documents, status updates, statistic and metric correlating reports, presentations and any number of other creative processes that yield static self-contained information in a structured format not readily available for parsing, sharing or collaborating? The short answer is because no solution exists in a nice package. The real answer is because no one is asking for it - content to collaborate content with email

Wednesday, April 11, 2012

Enterprise Social Collaboration = Email #FAIL

If you don't understand the "social" significance of the title of this post, all hope is lost for you.

What applications do you regularly have open on your work computer? If you're like the majority of those I asked, your answer is a web browser (flavor independent; IE, Firefox, Chrome, Safari) and an email client (Outlook being the most popular since all those I asked were on an Exchange/Outlook solution, but Lotus Notes or others also count in this regard).

The charge that I've witnessed to push social software into the enterprise has been at best small pilots and at worst an utter failure. Why is that? Because when I (and I use "I" as a generality - I don't have a Facebook account) use Facebook, it's about sharing pictures and status updates and in the enterprise, that is utterly useless. We need to share documents and presentations and don't care about "likes". And of course, we already have the most powerful collaboration software for sharing ideas and documents - email!

For enterprise social software to succeed, it needs to deliver a web-based, content-driven interface that incorporates communications and collaboration. That's not my bright new idea - that's the general industry consensus. My take is that's only half the picture. For enterprise social software to succeed, it needs to also take the focus away from the email client, which today is the de facto enterprise collaboration tool.

When I first started my career, our laptops were issued with Eudora as the email client since Microsoft Outlook wasn't released yet (am I dating myself). In the early 2000's, Outlook (and others) did wonders with regards to incorporating the social fabric of the workplace - appointments, meetings, contacts, scheduling of people and resources, task tracking - into an intuitive and integrated work space. If one were looking at the technology evolution from afar without context and information about how and why events unfolded, one may argue that a sine wave of innovation in enterprise IT forced a swing of innovation into consumer IT as the 2000's went on. After all, who was using Google Mail, Contacts and Calendar to share personal schedules (the way I would do with my work schedules in the enterprise) in 2002?

We are now in the next upswing of that sine curve driving new consumer innovations back into enterprise IT. And as social software tries to find a fit within the enterprise, there is no missing gap to fill for many of the ensconced enterprise employees who have developed a sharing and collaboration system based on the emailing of documents.

I have no argument that the existing method is better; in fact, I've railed against it for years begging for people to just send a link to a file share where the common document could live before Sharepoint found a way into enterprises and became the uber content management system. Still, people continue to maintain local versions of documentation and proliferate copies with obscure file names that act as a poor man's version control. No one has taken the time to learn check-in/check-out features of Sharepoint, and why would they - we're not software developers where this type of collaboration has its roots.

The evolution in enterprise social software that I'm looking for - to pick on Microsoft for example - is "Shoutlook", a merging of Sharepoint and Outlook that delivers a web-based interface for projects, work streams and sharing of documents and incorporates my email and calendaring into one interface. Real-time group editing of the documents is supported as well as the integration with a unified communications solution for quick voice/video/sharing ad-hoc conference break outs and logging to the active activity stream. No one does this. Well. Yet.

Enterprise social software is not going to see success by keeping available the crutch of a bloated email client for "old-school collaboration" by those resistant to change. The problem with new enterprise social software adoption is the lack of existing enterprise social software (email client) abandonment.

 

Copyright © VinsWorld. All Rights Reserved.