ECM 2.0 – Can you build it yourself?

Recently Gartner Analyst and long-time ECM evangelist Marko Sillapaa posted an interesting article titled “Why Build a Content Services Platform from Scratch?” . In the article Marko correctly points out that “build your own” isn’t easy and it’s better to avoid home grown solutions where support could be required for 20 years.  An alternative viewpoint comes from another long-time ECM evangelist Jeff Pots, “ECM, You Ain’t Gonna Need it” where Jeff points out how his firm has built light-weight content service capabilities for clients with high volume needs.  Adding to the chatter is one of the TSG posts from our DynamoDB efforts – DynamoDB and AWS – How to build your own ECM capabilities for massive scale and performance.  For this post, we will look under the covers on why many clients are considering building their own content services platform and how we have structured our consulting and software offerings to both assist in building efforts and avoid starting from scratch.

ECM 2.0 (or Content Services Platform) – Why the concern on buying again?

As Gartner pointed out in their famous article from 2017 (in the ECM space), The Death of ECM and Birth of Content Services, the enterprise goals of “E”CM didn’t really work out and often most larger companies had multiple, competing ECM tools evolve over time.  As we have pointed out often, back in the 1990’s, ECM began with goals to:

• Replace network drives
• Manage all types of documents in one shared repository (when CPU, Memory and Storage were very expensive)
• Unify document management features under one user application
• Allow for security and search across the repository for a variety of user scenarios

As CPU, Memory and Storage have become cheaper from both on-premise and cloud based services, the thought of “one infrastructure to rule them all” doesn’t make as much sense as content services tailored for each unique integration or requirement.  Experienced clients are starting to wonder if the infrastructure provided by their ECM vendors is worth the cost.  Issues we have seen from their clients with existing legacy ECM vendors include:

• Cost – First and foremost, for certain applications the cost of $50 to $100 (or more) per user per year for often simple document storage and retrieval capabilities that don’t require the full capabilities of an ECM platform.
• Technology – Legacy ECM tends to be built on legacy components.  Innovative clients want to explore building on new components.  Clients are finding it more and more difficult to hire and retain resources familiar with the legacy ECM platforms where newer technology provides for more resources and better retention.
• Support –   The cost of legacy ECM tools isn’t just the initial cost but the ongoing subscription or maintenance cost.  Many clients have expressed concern that these costs don’t seem to be going into either better support or product improvements but rather more extensions that cost additional dollars.

While we would agree with Marko that, for those who built their own ECM solutions back in the ECM 1.0 days, (probably relational DB with file links from what we have seen from migration efforts) support and keeping a customized application up to date for the last 20 years has been a challenge, many that bought ECM solutions haven’t necessarily been happy or that well supported either. 

ECM 2.0 – New Paradigms drive new decisions

One major point we tried to make in our “DynamoDB and AWS – Build” post was that in the move to more content services and less “document management as an application”,  modern content services needs to be rebuilt from the ground up focused on a new approach rather than rely on paradigms from the 1990’s that haven’t worked.  Specifically:

• Application Security rather than Repository Security – By pushing security to the application, the repository can perform quicker with less complexity and management.
• Departmental Search versus Repository Search – By pushing for multiple, efficient search indices rather than one large index, content services can perform quicker with less complexity.
• Object Store versus Mounted Drives – By building content storage and retrieval with the content store in mind, content services can retrieve, store and stream content quicker with less complexity.
• NoSQL versus relational database for metadata, versioning and relationships – By building metadata and document relationship objects with a NoSQL repository rather than relational database, content services can store and retrieve document properties and relationships quicker with less complexity.

As we have mentioned before, we would not predict that the new paradigm would come from old vendors for some of the following reasons:

• Cost – Legacy ECM vendors are tied to their current cost point to clients.  We have even seen pressure from clients to reduce ECM costs.  Supporting additional repositories is not a trivial activity and we don’t see existing vendors making that investment without an identified revenue stream from new clients that doesn’t cannibalize existing revenue streams.  It is also easy to predict further pressure to reduce costs for new technology investments driving continued high price per user for the new technology.
• Focus – Legacy ECM vendors have been focused on selling more to clients, not necessarily delivering more capabilities at the same price.  See our thoughts on the ECM Suite for more detail.
• Interfaces – Many of the Legacy ECM vendors interfaces are hardcoded to their current repositories with proprietary API and RDMS repository calls and would not be portable to a new NoSQL repository that would take advantage of the NoSQL approach.  The same could be said for new object store or search capabilities.

Why Build versus Buy?

Given concerns of the cost, support and long-term viability of the legacy ECM vendors, clients are asking Marko (or TSG) if they can build their own with a simpler approach and new technology as defined above.  Typical disruptors to the status quo of ECM tools include:

• Old Legacy ECM Tools – Whether the cost, upgrade requirements, proprietary file formats or a host of other reasons, clients are looking for new tools rather than building on old legacy stacks.  Whether the legacy vendors like it or not, the ECM legacy brands are often tied to thoughts of older technologies and historical vendor issues.
• New Talent – New people want new tools.  In a dynamic employment market, technical talent will pick and choose employers based on the technology stack they are assigned.   Retaining talent and a positive work culture when working on older legacy ECM has proven difficult for clients.
• Cloud Wave and Tools – Clients want to build their cloud skills whether that be Amazon, Azure, Google or others.  While the legacy vendors support cloud tools, clients want to consider using the services of the vendor themselves to build out their own technical expertise.

Build versus buy – How can TSG provide a jumpstart on the build process?

As an integrator, TSG is constantly seeing clients that want to build their own or add new integrations or capabilities to their legacy ECM platforms.  As we have evolved our services and software, we continue to look for ways to leverage our skills and services to support modern approaches for significantly more robust and cost effective solutions. 

TSG can provide a supportable “jump start” for those looking to build on their content repository services with a custom interface due to the portability of the all our products from current ECM tools to DynamoDB or Hadoop offerings.  TSG has interfaces and REST APIs for search, viewing, annotation, redacting, form and workflow, migration, audit trail and other integrations that have been proven in production environments and offer “out of the box” configurable approaches for DynamoDB and Hadoop.  Clients looking to build similar capabilities for their modern solution should consider some of the capabilities of the OpenContent Management Suite including:

• https://tsgrp.wpengine.com/2017/03/10/documentum-or-alfresco-reporting-big-data-to-the-rescue/OpenContent Web Services – Provides isolation as well as a robust API to access Alfresco, Documentum, Hadoop or DynamoDB repositories.  All of our interfaces are built on OpenContent Web Services so that DynamoDB or Hadoop customers have access to interfaces that have been thoroughly tested and in production for other repositories.  For DynamoDB and Hadoop, we have added 100% support for OpenContent Web Services to support versioning, relationships and other complex ECM capabilities. 
• OpenAnnotate – Provides for viewing, annotation and redaction of documents.  Based on OpenContent Web Services, OpenAnnotate works with DynamoDB and Hadoop “out of the box”.  Currently available with OpenContent search and case on the AWS marketplace for DynamoDB.
• OpenContent Search and Case – Provides for robust Search and Case Management features configurable for different object models and easily supportable.  Currently available with OpenAnnotate on the AWS marketplace for DynamoDB. 
• OpenContent Forms – Provides form and workflow capabilities leveraging Activiti.
• No Code Configuration – OpenContent Management Suite features configuration with a no code approach rather than low code approaches to allow for easy support and adoption of new documents and object models.
• OpenMigrate – OpenMigrate supports DynamoDB and Hadoop as well as a host of other ECM repositories.  Clients will need products for migration, ingestion and publishing.  OpenMigrate also provides integration to Ephesoft to allow for capture.
• Elastic Audit Trail – One of the more interesting add-ons for monitoring access and performance is to leverage the Elastic Stack (Elasticsearch, Logstash and Kibana) to record activity. See post and look for more in regards to a better monitoring and auditing tool.
• Other – lots of other integration including Docusign, WorkShare Compare, Box, Office 365 and the rest are part of the OpenContent Management Suite.

Our 11 Billion document benchmark with AWS and DynamoDB leveraged all of the capabilities above. 

Summary

More now than ever, innovative clients are considering building their own content services platform due both the cost and older technology of legacy ECM vendors as well as the new capabilities like NoSQL and the cloud.  For those looking to build their own modern infrastructure but concerned about the cost and support, TSG can provide out of the box solutions built on a modern technology stack that can be supported with services and updated products from TSG.