For decades, enterprise content management vendors tried to be one-stop content services platforms. In the early...
years, they even brought web content management into the fold. The result has been a collection of good technology with poor user experiences, and a succession of point content services that routinely became obsolete.
The pattern has been consistent: The sales teams from an ECM vendor and a content application provider will go on a joint sales call. Together, they are successful and build reasonable market share. Eventually, the ECM vendor buys either the content application or the provider that built it, or builds a competing app. The goal is always to drive more license and services revenue.
The problem is the ECM vendor doesn't understand the market it just entered. The business environment evolves, and the only feature changes to the application are those made to the platform. Sales eventually dry up, clients begin to switch to a new system, and the old one is eclipsed and dies.
ECM vendors cannot build sustainable applications for every market. There are too many variations. There are common capabilities, but it takes detailed domain knowledge to build services that meet the needs of a specific market. Vendors that live in the space are best suited to make sure that these applications or services properly evolve.
The rise of the content services platform
In my experience, the most successful ECM deployments have been those with focused UIs. In the 1990s, invoice processing exemplified this approach quite well. The scanning and task-specific nature of the process lent itself well to burgeoning ECM vendors. As they expanded to handle more use cases, their UIs became cluttered. The need for custom UIs became increasingly important.
Custom UIs were possible through the utilization of the ECM product's API. The first APIs were very unique to each vendor and required extensive knowledge of both the product and the API. Eventually, the vendors began rolling out service-oriented APIs based on Simple Object Access Protocol and eventually RESTful concepts. This made the creation of the UIs faster but still required vendor-specific implementations.
In 2008, the Content Management Interoperability Services (CMIS) standard was released. This was the culmination of years of work by content management system vendors across different industries. It paved the way for treating an ECM system as a content services platform (CSP). The defined content services were created not as the lowest common denominator, but as the features an ECM vendor needs to offer to be a complete CSP.
The release of CMIS defined a map for the industry. Vendors quickly adopted the standard, anxious to be leaders in the -- as yet unnamed -- CSP market. Many augmented CMIS with complementary features specific to their platforms.
As exciting as this all seems, collaboration is not served by the CSP model -- or at least, not well. The need for people to collaborate around content is a universal use case and has changed very little over the decades. There have been many attempts to create new tools, but email still reigns supreme for content collaboration. File sharing is the surest go-to feature for these capabilities, but the rise of Microsoft Teams and Slack has blurred the lines even more.
Setting your content services platform strategy
Simply following a CSP approach will not promise success, however. It is merely an approach to providing consistent content services to all your application. There are still valuable information modeling and user experience tasks that need to be accomplished. Much of the power of using a CSP comes in understanding how the different applications may interact under the covers.
Because of this, while many push an agile, iterative approach for systems from day one, a larger, holistic view of the endgame is beneficial to consider. This is true even if that larger vision isn't built until years down the road.
Take the time to look at your existing content infrastructure. Is it a locked-down silo or is everything available via services? Can the content be used in multiple systems? More importantly, are you able to find ways to apply information governance from a central application to content on multiple systems?
If you don't know, now is a good time to map it out. Determine where your content resides and if it is residing in an open content services platform. Map it out, find the gaps and start to determine which content would become more valuable if it wasn't locked down. Then start your transition to the architecture of the past and future.
Why LA County stays on Documentum