Lubor On Tech

Wednesday, March 2, 2016

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.

Wednesday, November 4, 2015

"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.

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

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.

Monday, March 23, 2015

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 UserNot 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 ProcessAs 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 ChaosECM 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

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

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.