Wednesday, March 2, 2016

Platform is a Business Model, Not a Technology

Many software companies have been infected by the platform bug. They market their software as a platform. They have built a platform. Their software comes with tiered architecture, an API, and perhaps even some developer tools. But do they really have a platform?

Well, to have a platform, someone has to “stand” on it. What that really means is there have to be others who have built applications on your platform. If the only applications available on your platform come from you, the world couldn’t care less about your platform. There have to be companies out there that decided to build their applications on your platform and not on someone else’s.

That last point is critical. The application developers are effectively asked to place a bet on your platform. That’s particularly important for commercial application vendors as their application will require your platform to run. That represents a huge commercial risk. The application vendors can usually afford to build their software only for one or two platforms. Supporting more than that becomes very cost prohibitive. So why would the application vendors select your platform over some other one?

This effectively becomes a business decision based on the market presence of the platform. The market presence is critical in determining the total addressable market for the application. It’s only one factor, because your application actually only targets a fraction of that potential target market - there are other factors involved based on the type of the problem the application solves. It is very rare, that customers would adopt a certain platform because of a particular application. They may adopt a platform because of a perceived abundance of applications but rarely because of one application.

Let’s take the mobile devices as an example. If you want to build a mobile application, you need to decide on which operating system platform your application will run. Considering the market presence, your decision is relatively easy - you need to support Android and iOS and then your application will support well over 95% of all mobile devices. Adding a third platform to support - perhaps Windows or Blackberry - makes commercially little sense. It’s a huge development cost for a marginal increase of potential customers.

While the market presence is key for an application vendor to support your platform, the features are not. No matter how rich your API is, how easy your development tools are to use, or how well you ensure security, scalability, reliability, etc., application vendors won’t support your platform if you don’t have a market presence that represents an attractive enough target market. Sure, all those features are important but, commercially, the market potential will always beat features.

There has been a long debate about Enterprise Content Management (ECM) as a platform. All the key vendors provide technically a platform. They have the right architecture, the API, and the developer tools. But let’s take a look at the market from the application software vendor point of view. The market is very fragmented with many players and none of them has more than 15% of market share. If you can only afford to support 1-2 platforms, which ones to you choose? IBM? OpenText? EMC? Box? SharePoint? Picking any one of those two will give you no more than 25% of the market as a potential target audience. Would you as an application vendor bet your business on any one of those platforms?

No. What you do is you build your application in a manner that is agnostic to all those ECM systems and you provide integrations to any one of those ECM repositories. That way, you only need to support one code base while potentially targeting a significant percentage of the ECM market. You have mitigated your commercial risk by not making your application stand on any one platform - there is no business dependency for the application. Your approach, however, makes all those ECM systems just information sources, not platforms.

“Wait a minute”, you might say, “how about the applications that are built by customers rather than commercial vendors?”. True, those applications do make your platform a true platform, even if most of the customer development falls more into the category of customizations rather than applications. But as that line is very blurry, let’s not split hairs. The question to ask is what makes customers who intend to build their own applications choose your platform? And the answer is, yet again, not so much about the features and technology and much more about the skillset availability, which is a function of market presence.   

To be a platform, any system has to devise a business model that compels application developers to bet their applications on a platform’s success. How do you attract developers to build their applications on your platform? How do you make it commercially attractive for them? Without resolving this fundamental issue, all the features and APIs won’t make any difference.

Because a platform is a business model, not a technology.  

Wednesday, November 4, 2015

The Case for Non-Persistency

"Never write if you can speak; never speak if you can nod; never nod if you can wink."
-- Martin Lomasney, Massachusetts state senator

We have collaboration, we have enterprise file sharing, we have enterprise content management systems. It’s secure, efficient, and compliant. Yet, most collaboration is still done using email. Why is that? What does email have that all the collaborative software doesn’t?

What all these tools have in common is that they are persistent. The messages, comments, and documents that we create and share as part of collaboration are meant to remain preserved in the repository for a long time. And, for a good reason. They are part of the organizational body of knowledge, the corporate memory, that can be leveraged by the entire organization today and in the future. Often, there are also compliance reasons that stipulate persistency, sometimes even requiring us to turn all collaboration artifacts into formal records.

Photo: Flickr
But this persistency has a side effect. For one, employees often refuse to commit to bits the communication that they don’t want anyone to forward or discover. No, I don’t mean any politically incorrect jokes or some corporate sexting. I mean useful, productive communication in the form of feedback, opinions, advice, or critique that are often only shared in person. That’s why a lot of this communication either doesn’t happen at all or happens via SMS text messages and consumer instant messaging tools outside of IT control.

Another problem of persistency is vulnerability. That’s the benefit that Snapchat exploits so well when they say that delete is the default. Persistent information can be leaked or hacked. Information that has vanished because it was non-persistent, can’t. Many consumer companies have recently learned a tough lesson when their customer database has been hacked and the customer data has been leaked. If the data wasn’t persistently stored in the database, it wouldn’t have been leaked.

The other side effect of persistency is the added burden on employees. When you are saving a document in a repository where it may be shared with other people, you have to save it responsibly. Responsible collaboration means you have to think about where you save it, what you name it, decide with whom you share it, specify access permissions, assign metadata, add an expiration policy, and perhaps even classify it as a record. If you don’t do that, you are not collaborating responsibly because the organization won’t be able to get much benefit from what you are sharing.

Sure, some of those tasks can be automated and there is an entire industry trying to solve that problem. But some of the steps can’t be and that makes it a hassle. That’s why so many people just email the document to those they need to collaborate with right now. With email, we are free to collaborate irresponsibly -  we don’t need any of that metadata or policies, we don’t even have to name the document. All we need is just to click on Reply to All.

Email is not exactly non-persistent but it seems that way. Sure, some of us might be aware that the emails live on a server somewhere and some might even know that their IT department archives all emails for possible litigation and compliance purposes. But that’s only preventing us from engaging in irresponsible behavior, not in irresponsible collaboration.

There is one more burden that persistency creates. It creates clutter. The more sharing of documents and comments, the more clutter that is being created. If the collaboration artifacts remain persistent, the volume of documents, folders, messages, and comments just keeps growing and growing. Pretty soon the repository becomes difficult to navigate and nobody can find anything anymore. The corporate memory becomes a digital landfill, denying the organization the benefit of future reuse.

In fact, non-persistent collaboration is a gap in the collaboration market. We need a solution where a few people can quickly come together in an asynchronous way and just share, review, comment, and edit information. It could be a single document, a collection of images, or just an idea in the form of a sketch. After the collaboration is concluded, the initiator can decide whether the result should be moved to a persistent area or just leave it upon which it would vanish. The versions, comments, and messages would all vanish too.  The vanishing could be timed or immediate and it would always be the default behavior. Any move to persistence would have to be deliberate and it would notify all participants.

I am not aware of any commercial offerings providing non-persistent collaboration today but they might exist. I know that the US military has been using such a solution in the past, perhaps they still are. Obviously, the security aspects of non-persistency have a great appeal for a security sensitive organization like the military. I should probably also mention Snapchat again here. It is not exactly a commercial offering but it certainly has made a mark with its non-persistent messaging.

Would such non-persistent collaboration finally replace email? Maybe. Probably not. If I had a penny for every time someone declared email for dead… But it would address a gap in people’s needs. I know it goes against the grain of every corporate legal counsel and chief compliance officer but non-persistency would make us more productive.

Thursday, April 2, 2015

They Should Be Business Tools

A few weeks ago, Google decided to quietly sunset Google Glass. They never said it publicly and in fact they might be considering another strategy for the device, but by all measures, Google Glass as we know it has failed. There are many theories for the reasons of this failure ranging from privacy concerns to the lack of social acceptance for walking around with geeky glasses. My theory is that the failure may be related more to the $1,500 price tag as consumer gadgets are simply not supposed to be that expensive.

Sergey Brin wearing Google Glass
That’s perhaps really the problem. Google Glass was certainly too expensive as a gadget for consumers but it likely wouldn’t have been too expensive as a business productivity tool. Most companies wouldn’t have a problem with the devices price, particularly with the customary volume discounts, if it demonstrated tangible benefits.

I can think of numerous business applications for Google Glass – from instructions while operating or repairing complex machinery, to patient records during surgery, to production data on the assembly line and supplier data in the warehouse.

But none of that was ever a priority apparently. Instead, Google put all their efforts into marketing Glass to consumers. The consumers may represent a greater opportunity in terms of volume but the enterprise market may represent a greater opportunity to optimize revenue. Just ask Microsoft.

There have been other technologies that I thought would have benefited from this strategy. Microsoft Kinect for Xbox comes to mind. While popular with gamers, the novelty of gaming via full body motion control is now wearing off. Let’s face it, most gamers want to shoot at aliens while sitting on their sofa and the Kinect is not the optimal weapon for that.

I would have hoped that we’d see Kinect being used in business – the repair technicians with oily hands reviewing designs, foremen at construction sites reviewing blue prints, surgeons with sterile hands reviewing patient records, farmers with dirty hands, lab technicians working in gloves – there are many use cases for gesture-based interaction.

When gestures are not practical, voice-based interaction might be appropriate. This is another technology that might have a greater application in the professional world than in the consumer space, at least given the current state of voice recognition. While the consumers relish in finding out the shortcomings of the still relatively new technologies such as Apple Siri or Amazon Echo, the business use cases may be more feasible. The business vocabulary is more precise and predictable, particularly in the given context. Professionals usually have to learn their business vocabulary as part of their job training and that makes it easier and less ambiguous.

Consumers usually resort to calling a company’s 800-number only after they failed to accomplish something online. At that point, we are exposing the already frustrated consumer to a voice recognition system that is far less mature than the web site and expect it to deliver a great experience. People usually don’t call in to do something that can be done with a smartphone app – like to check their account balance. In the business world, on the other hand, users are already trained to use a fairly precise language and their voice commands are usually in the context of a specific data set or business process.

I need the Q3 revenue data for Europe broken down by product group” is much easier for a machine to understand and act upon than: “I want to buy a companion ticket for my spouse using my miles to match an already issued ticket purchased by my employer”. This relatively common task requires many additional data points - ticket number, flight numbers, account number, name and DOB of the traveler, seating preferences, credit card number, etc. – and that is very difficult for a voice-driven system to piece together.

Apple Watch. Yes, I want one!
A few weeks ago, Apple launched its new Watch. By all measures, it is already a success even though it won’t ship for another few days. The demo by the Apple team was very impressive and the press reviews are glowing. I have no doubt that the Apple Watch will become a success. But I wonder about the practical use cases of the Watch for consumers. So far, most wearable devices have focused on fitness but that market is very saturated already. The serious athletes will be hard to separate from their specialized Garmin, Timex, and Suunto watches. The hobby athletes are well served by the Fitbit, Jawbone, and Nike Fuel fitness trackers or they simply keep using their smartphones.

I can’t help but to wonder about the business use cases for the Apple Watch. There are many possibilities – approving process tasks, participating in simple collaboration activities, delivering business context-relevant information, etc. Smart watches are looking for a killer app and sharing your heartbeat is probably not it.  I suspect that we could find it sooner in business rather than the consumer space. 

Google Glass page on March 31, 2015

Monday, March 23, 2015

Business Process – the Future of ECM

This is a blog post that summarizes the presentation I delivered on March 19 at the AIIM Conference 2015. The link to the presentation slides on SlideShare is included below.

For years, enterprise content management (ECM) solutions were adopted primarily for two main use cases. The first was to achieve compliance, and many early adopters of ECM continue to successfully use it to address various regulatory requirements. Compliance provided functionality for records management, archiving, and information governance. A while back I wrote a blog post titled What Features Ensure Compliance? that elaborates on the functionality required for compliance use cases.

The second use case was around team effectiveness with functionality such as collaboration, document sharing, and social capabilities. Collaboration is subject to frequent changes in direction as every new technology promises an easier and more compelling user experience—from mobility and social software to file sync-and-share. The frequent feature churn in the collaborative use cases doesn’t go well with the compliance requirements that often need the system to remain unchanged for several years (validated environments, anyone?).

ROI and Dependency on the User
Not only were the two primary use cases not really well aligned in their feature requirements, they had two additional challenges. Neither use case provides a very strong ROI. Sure, we marketers always calculate the savings in storage and government fines that compliance solutions help you avoid. But let’s face it: preventing penalties is not exactly a hard ROI and storage is cheap (or at least everybody thinks it is). The collaborative use cases are even worse—measuring the ROI here is fuzzy at best and often impossible.

The second challenge was the dependency on the users to do the right thing. For the compliance use cases, users were expected to diligently file their documents, weed out their inboxes, type in the metadata, and apply the right retention policies. Obviously, users are not very consistent at it, even if you try to force them. In the case of collaboration, users were expected to share their documents openly with others, comment in a productive way, and stay away from email and all the other collaboration tools around them. As it turns out, this type of behavior very much depends on the culture of the team—it works for some, but it will never work for others. The adoption of any collaboration solution is therefore usually very tribal.

So, is there any hope for ECM? Can we get an ROI and get employees to use it without someone watching over their shoulder?

ECM: Part of the Process
As it turns out, there is a third type of use case emerging. It is the use of ECM as part of a business process. Business processes are something people already do—we don’t have to force anyone. That’s what companies and working in them is all about: everything we do is part of a business process. Business processes are also important, relevant, and very measurable. There is an ROI behind every business process. Every instance of a business process includes the context, which can be used to populate the metadata and to select the right policy automatically. Business processes can handle the automation of content management and don’t have to rely on the end user to do it.

But business processes don’t live in ECM. Sure, the process artifacts usually reside in a content repository, but it would be a stretch to claim that the entire business process happens in an ECM application. Nor does it live in the BPM application, even if that application may be the primary application for some users. In fact, there is usually a master application from the structured data world that rules the business process: enterprise resource planning (ERP), customer relationship management (CRM), product lifecycle management (PLM), supply chain management (SCM), etc.

That’s why it is important for ECM to connect with the master applications through the business process. This is not just a simple way to link data sets or to hand over data from one system to another. Using modern, REST-based technology, it is possible to achieve integration that goes much deeper and involves users, roles, permissions, classifications, and of course the user experience.

Deal with Content Chaos
ECM addresses some very important problems that every organization has to deal with. Given the volume and relentless growth of content in every enterprise, it has to be managed. Yet ECM struggled to be adopted widely because of lack of tangible ROI and a difficulty to attract end users. Tying ECM to a business process through a master application addresses these challenges. It may not solve every problem with content in the enterprise and there will still be content outside of any business process, but it will go a long way to dealing with what AIIM calls “Content Chaos”.

Monday, March 9, 2015

Is It Time to Revive Knowledge Management?

This blog post has been originally posted on the Big Men on Content blog:
Back in the 90s, Knowledge Management was being heralded as one of the best use cases for content management. The goal of Knowledge Management was to effectively capture and reuse an organization’s knowledge. That’s a lofty goal and it’s not a surprise that most Knowledge Management failed miserably.
There were many cultural, organizational, and process reasons for the failures of Knowledge Management but one of the main reasons was the technology.  Back in the 90s, the technology to capture, manipulate, share, and reuse content was still in its infancy. In fact, most vendors indirectly admitted as much when they stopped marketing Knowledge Management as one of their offerings.
But the customers haven’t given up on it.
In fact, I keep running into customers and prospects with “Knowledge Management” on their business cards. And, rightfully so! There are some major demographic related issues that drive the demand for Knowledge Management.
Many customers I meet face the problem of an aging workforce. According to the Bureau of Labor Statics, there are numerous industries with a median workforce age over 50. I’ve seen organizations with an average workforce age over 55. In fact, the Stanford Center on Longevity predicts that by the year 2020, the 55+ years old workers will represent 25% of the workforce!
This is a workforce that is not Internet natives. They are not millennials. They didn’t grow up digital. A lot of their knowledge and expertise is not in a corporate repository. It is in the decades of notes stored on paper and in their heads. In a few years, those employees will retire and their knowledge will leave the organization. Often, this knowledge is mission critical and it has to be captured, processed, shared, and reused.
Does that sound familiar?
Yes, that’s exactly what Knowledge Management is supposed to be all about. Knowledge Management is needed more than ever before and, finally, the technology has advanced mightily since the 90s. Today, our ability to capture information in the form of paper, voice, images, drawings, video, and other content is very powerful. So is our ability to ingest, index, and manipulate the content. We have structured and unstructured data analytics which help to make sense of all that information. Finally, we have compelling responsive experience, mobile devices, and cloud environments that help us share and consume the information effectively.
Knowledge Management is needed and increasingly, Knowledge Management is possible. Maybe, it’s time to start promoting Knowledge Management again. Because this time, it might actually work.

Friday, February 6, 2015

Could ECM Have Prevented the Sony Hack?

This blog post has been originally posted on the Big Men on Content blog:
There were hundreds of data breaches last year but Sony Pictures won the prize for the most publicity received by a hack. Mostly that publicity came about because Dennis Rodman’s friends got to watch The Interview before any of us. Like the President of the United States said, we can’t tolerate that. We must prevent such cyber-attacks.
But how?
According to the media coverage, most of the stolen data was in the form of structured data such as employee salaries and social security numbers but also emails, documents, movie scripts, and video files – even entire full-feature movies. Over 100 terabytes of data have been allegedly stolen and a lot of it was unstructured data, content. From the little information we have about the hack, no ECM system was in place and the content was stolen from servers and employees computers running Windows. ECM has always been claiming to have the ability to ‘secure’ content, right?
So, would ECM have prevented the Sony hack?
Let’s assume that it really was a hack – a malicious data breach by external actors rather than an internal security leak. An Edward Snowden scenario would have been a whole different ball of wax. But if the bad guys came from the outside, could ECM have prevented the Sony hack?
ECM could have certainly helped by securely archiving the content files and email messages, keeping them off the user drives, and expunging them as their retention period expired. Culling the email volume would have reduced the number of sensitive and sometimes embarrassing emails that were hacked and exposed. It wouldn’t solve the problem entirely but it would have helped. Getting rid of unneeded and potentially compromising data is one of the best practices of information governance solutions based on ECM. Well organized ECM repository and processes would have kept at least some of the sensitive content off employees’ hard drives.
Next, let’s consider permissions. Many of the stolen files were allegedly swept off file servers, which likely had little or no permission control. An admin level access gives a hacker the master key to the vault. Permissions provided by an ECM system would make things much more difficult for the hackers. Sophisticated permissions often allow administrators or even curators to do their job without having the rights to access the content itself – no master key. That would have helped a lot.
How about security features? I’ll skip over the authentication, SSL, VPNs, and other perimeter security that is not specific to ECM – most ECM systems do this but so do other applications. I’m skipping over virus checker and malware detection for the same reason – those were clearly not in place or ineffective in the hack but they are outside the scope of ECM. By the way, a two-factor authentication and a good firewall would have helped too – chances are they had some of it and it was hacked.
The ECM specific security would include repository level encryption and possibly also file level encryption. The repository level encryption is big – many customers use it, it doesn’t burden the users, and it does represent another layer of security, which could have prevented some of the data theft.
File level encryption provided by a rights management system is also a capability that some ECM vendors provide. But let’s be honest, most customers don’t use it as it imposes a significant burden on users and impacts their productivity. That said, having to break the encryption of every file would provide as much security as one can get these days.
I should also mention the audit trail, which by itself doesn’t prevent any data theft but it does help the forensics after the fact. Tracing back the hack helps to assess the damage and more importantly, to prevent it from happening ever again. The Sony hack apparently occurred over several months. A good audit would have discovered the breach earlier and prevented some of the data loss. ECM systems are well known for their sophisticated audit trails and I bet Sony now wishes they had it.
So, to sum things up, an ECM system could not have entirely prevented a data breach like the Sony Pictures hack. No system can. But it would have provided several additional layers of security to protect the intellectual property better and the result of the hack would have compromised less data. Every security layer makes things more difficult for the bad guys and it slows them down. That’s what security is all about – both in the physical and in the digital world.