We’ve all heard about content services platforms or CSPs. Michael Woodbridge of Gartner introduced the term in 2017 as a way to kill off the term enterprise content management (ECM) and heralded a new era for the way in which organizations use technology to manage their information. But other than a change in name, did anything really happen?  

ECM vendors jumped on board rapidly from a marketing perspective at least — there is a certain need to follow the heavyweight analysts when they introduce a new industry term.

Yet from a capability perspective, not a lot really changed - if you really dig into what content services platforms “should” and “could” be, there is a huge amount of potential and benefit to be had by all. But, no one has delivered this to the market yet — until now.

 

What is a Content Services Platform (CSP)?

First off, a platform is something that is designed to be built on. That might sound obvious, but many “platforms” in the market are simply software tools that can be extended. Perhaps these extensions are a custom search that can be configured, or the ability to save files to a cloud-based file system — both of these are useful, but neither one involves actually building on the platform.   

The second aspect of a content services platform is that it needs to provide a wide variety of tools to work on content. Capabilities such as version control, granular access to permissions, content viewers, enterprise search, content collaboration and more are all prerequisites for a CSP. But, the interesting thing about the CSP model is that these functionalities do not need to be embedded in the base software, or even from the same vendor. 

A core pillar of the CSP mindset is open integration. This concept provides the ability to consume services from any REST-API-enabled service or system, or even have services consumed from the platform itself by other systems. Legacy ECM systems struggled with this concept, not playing well with other systems, and as these tools evolve toward the platform model, open integration is an area where they still frequently fall short of being a true CSP. 

The open integration philosophy expands to the technologies used within the content services platform as well. For example, some might consider robotic process automation (RPA) tools to compete with CSPs, yet a true CSP will work with RPA and numerous other technologies such as intelligent capture, AI and ML models, dashboards and analytics, workflow engines, and more.   

We saw a recent example of this in a bank for incident response. An RPA system had been set up to collate information from a variety of systems and package it up for review by the customer. The RPA bot was working perfectly, so why not make use of that from the CSP? Instead of rebuilding the functionality in the CSP or having two disconnected systems, the bank simply connected the CSP to the RPA using published REST-API calls to deliver the best of both worlds. 

And finally, we need to consider how CSPs arrived at this point. Many content services platforms are ECM tools with a new skin. These were all built as content repositories with functionality added on the top. When you build on top of these platforms, what you are doing is building on top of the repository with a set of tools designed to work well with that core repository. But not all of the content within your organization lives within that repository.

Why build on top of a specific ECM repository? Logically, this approach limits the organization’s ability to access content from across the enterprise and to make the most of it. Why not build on a content services platform that can instead connect to all of the information systems within the enterprise — ECM, Document Management, CRM, ERP systems, and more. To paraphrase a certain Gartner analyst, “Building business applications should not be about which bucket is best, but instead - about accessing information from ALL the buckets.” To achieve this cross-service capability the API is critical — it removes the limitations of narrowly focused micro-services by incorporating multiple, relevant services and functionality via one consistent API.

A true content services platform can give you all of the capabilities described above. So why are there so few true content services platforms available today? 

The Power of The API

One of the elements described in the previous section holds the key to answering that question. An open content services API allows organizations to build solutions that include not just traditional document management capabilities but also federation, migration, workflow, AI, RPA, analytics, and data understanding from their own platforms. Why should any vendor think that theirs is the only or best content services platform to build apps and solutions in? 

Call it history, call it arrogance, call it whatever you like — but many CSP and ECM vendors do not want to expose their API and integrate it to other solutions.

But from an enterprise perspective, why would you want to stop applications like UIPath, SAP, and Salesforce from accessing your business content? You wouldn’t, right?

At Simflofy we completely agree. That is why we built a truly open CSP, designed to be built upon, connected to, migrated to and from, and used as a federation engine and repository. 

The funny thing is, this capability has been hiding in plain sight for the past 4 or 5 years.

Introducing A True Content Services Platform

When Simflofy v1 was created in 2013, it was built on top of an Open API. The early functionality focused on migration but every function and every user interface was built on top of the newly created REST-API platform. 

This logic has continued as Simflofy v2 shared high-volume and scale content federation with the world — every feature and function, built first in the API to be exposed and used in the end product. And the recently released Simflofy versions 3 and 3.1, which showcases records management, e-discovery, and document management capabilities are concrete examples of true enterprise-grade solutions built on top of the underlying Simflofy content services platform API. 

Now the time has come to tell the world.  

Simflofy is not a product, it is a content services platform — and that platform is available for general use now. Simflofy provides the platform and API for anyone looking to leverage the power of their content.

Over the coming months, we will share details of how systems integrators, value-added resellers, and enterprise developers can gain access to the Simflofy platform, detailed technical documentation, and code-bases for sample solutions. 

This is the beginning of a new world of content services. 

A move beyond the repository-focused view clung onto by vendors, to a world where content can be accessed, viewed, transformed, and ultimately, liberated. 

 


To learn more about the Simflofy platform, visit our platform page here.