The Content Management industry is rife with contradictions. The biggest of which is that the business just wants solutions to their problems while IT wants a common platform from an established player to make integrations and upgrades less risky.

I’m not sure how we solve this problem and I am tired of watching the pendulum swing back and forth.

• Most of the systems in the 90s worked great, mostly because they were focused and installed on the local desktop. Integrating those systems was difficult as APIs were tied to a technology platform.
• Enterprise content management (ECM) was conceived in response to the integration challenge shortly after Y2K. ECM, in theory, combined all the basic content technology together, allowing you to buy a full suite of content management tools. ECM failed because many suites were loose integrations and not true suites. Additionally, companies ended-up with multiple ECM systems through acquisitions or simply had to buy new platforms when the old platforms were neglected into obsolescence.
• The cloud came along and suddenly everyone has an app for every problem. Each app works well, partly because they have reverted back to the pre-web user interface that worked well in the 90s. The problem is that the apps proliferated faster than they stitched into the enterprise ecosystem, assuming the enterprise even knew what was being used.
• Open APIs have come along to enable the combining of multiple applications to build an enterprise-class set of features. In the content space, it is giving new life to the concept, though not the term, of the content-enabled vertical application (CEVA).

The current swing is likely to culminate in some consolidation as some cloud vendors will likely pull together under a common umbrella while keeping some semblance of individuality. Think Instagram under Facebook but at a larger scale like Alphabet overseeing all the Google properties.

The Platform Appeal

In IT, long term strategy has traditionally been easier to implement if you have a common platform to solve a common set of problems, i.e. having a default database platform. This works great for IT departments as most platforms also offer frameworks to use when building solutions. This has also been their greatest problem; they only offer frameworks.

This means that when the platform needs to be used to deliver a solution, IT must get involved. These requests pile-up and traditional IT departments tend to do the bare minimum to solve a problem before moving on to the next request. The business hates this because the resulting bare-bones solutions are typically less intuitive and require more manual steps, both of which contribute to more errors.

There are some solutions available for many platforms but those are the exceptions. They are often built by partners that may, or may not, be true product vendors. Sometimes they are built by a platform vendor but these typically work really well for one of their leading customers upon launch, after which they are neglected until the fade away.

The Open API Model

In the content management space, one solution to all of this was the Content Management Interoperability Services (CMIS). CMIS is a solid standard that was quickly adopted by the major ECM vendors and put into maintenance. While used by some companies to build CEVAs, only the open source vendors seem to care about advancing the standard.

Cloud vendors seem adverse to even spelling CMIS.

The cloud vendors have been pushing open APIs. Open APIs are public, well documented, and often used by the providing solution to integrate with complementary systems. Open source vendors in the content management space use open APIs to augment CMIS and provide a way for platforms to communicate smoothly.

In the cloud, they are gaining real traction. They are being used to create ecosystems of applications, making it easy to connect diverse systems, sometimes without actually having to write code. All that is required is a real understanding of what you need to do and knowing what API calls are available within the other system. With that information, you can have event in one system trigger an event in another system.

It is all pretty cool but does it solve everything?

Flaws Everywhere

Things are still not perfect. Better but not perfect. There are limits to what can trigger an action and how many actions can be triggered. If there are all-or-nothing rules that have to be implemented or other more complicated business logic, customization is still required.

What we do have is the ability to begin cobbling together real applications using different services. If those new applications also have a fully defined API layer, then we are starting to make real progress.

It likely won’t be enough and the pendulum is going to keep swinging. Our biggest limitation right now are the user interfaces. They require human effort to build them in a friendly manner. When we get to voice commands, then we will start being able to truly combine systems in ways that work and make sense.