“Enterprise content management is dead!” With this provocative statement in 2017, Gartner heralded in the era of content services. The whole discussion is sort of beside the point though. In fact, you could say it’s even misleading. The reality is that companies are dealing with more and more data and documents in a growing number of systems and services. At the same time, demands on customer-centric services and speed are rising parallel to the demands for better data protection and security.

Indeed, the need for enterprise content management is growing: the need to manage and secure all of a company’s content and to ensure its constant flow. Of course content services are the right technology for this. But what exactly does the technology have to deliver to successfully cope with the challenges of companies and their employees?

To turn a technology into a solution, it needs to map the different areas of responsibility in a company and be compatible with the way users work and think. In other words, from content services arise business objects which exist solely to help the user.

Users don’t create Word files or Excel tables; they create offers, budgets or articles like this. In turn, they are a part of a larger overall context. As an example, let’s look at an application for a house loan. Each application contains information about the applicant, the financial institution and various external sources. There are lots of similar examples out there: Tenders which include countless documents and never-ending correspondence. Orders involving inquiries, offers, invoices, delivery notes, etc. Case files which contain all information about one specific case. The list could go on.

The common thread in all of these examples is that it’s never about one single document. And it’s definitely not about what this document is called or where it’s stored. You, the user, don’t search for “Project_overview_v3_Jan_2019”. You want to know about the project status, the upcoming deadlines and who is working on which task. First and foremost, it's about the content. Or rather, the information and the context in which the user is working on it. The value of the information is defined and changed by the business context.

Furthermore, relevant information is often distributed throughout several documents. To check an invoice, for example, you likely need to see the related purchase order, the existing contractual agreements and even email correspondence. Traditional search tools quickly reach their limits here, because they either don’t find all of the necessary information, or there is so much information that it’s impossible to maintain an overview. Context-based search is much faster and more targeted: In the container “Order process”, you’ll find all necessary information in one spot and in a clear structure.

The examples listed here have much in common, but also many differences. Viewed abstractly, you could say that there are countless business objects (processes, cases, files, folders, etc.) in daily work that are made up of a multitude of information objects (documents, eFiles, workflow steps...). The task determines the form that business objects take for a user. Does the user work with processes? For example, in procurement processes? Or in a hierarchical structure of, say, highly complex projects? Is processing triggered once an online form is filled out? Or maybe a user creates internal workflows ad hoc?

A content services platform’s purpose is to digitally map all of these more or less complex contexts in the form of business objects. At first glance, many software offerings out there seem alike. Yet, if you look closer, the details make all the difference when it comes to effectively mapping business objects. Which capabilities does a solution need to offer?

One requirement is that documents, eFiles and workflows — or rather, all kinds of information objects — can be linked to various business objects. A document must also be able to appear in several different business objects. It may come as a surprise, but not many systems that call themselves DMS, ECM or even content services platforms actually offer this fundamental capability.

Some just aren’t able to break their ties to the analog world: For example, a document can only be stored – or rather linked – in just one eFile or in one virtual cabinet”. Otherwise, unwanted duplicates are necessary. Or documents always have to be assigned to a hierarchy, as if they were really attached to a digital file folder. It’s crazy, considering that the big advantage of an eFile is that it can do much more than its paper predecessor.

Another example of poor linking practices is Microsoft SharePoint. On the collaboration platform, users are able to link documents to their pages and workspaces. But they do not represent true relationships between information objects. Quite the opposite, actually: The documents are located once again in a fixed location — just like in a file system. If the file or source folder is deleted, the links will lead nowhere. Users are also not able to navigate easily from a document to its original source. In essence, SharePoint (just like many file sync & share offers) just ported typical disadvantages that frustrate users in the file system to the cloud: e.g. duplicates, outdated or broken links, and uncertainty about the location of the current version. You can call this File System 2.0 if you want, but definitely not content management system where documents are first-class citizens

Another important condition for working with business objects: Every element of a business object can be independent and have its own metadata. This applies in particular to container objects such as eFiles or case folders and processes. There are clear advantages to this: faster and more convenient searches, independent and overarching access rights, retention periods, deletion locks, and much more. Last but not least, it often makes sense to attach supplementary data, e.g. from ERP or CRM, to the overarching business objects instead of to each individual document. Not every software solution on the market offers this, which is why it’s worth taking a closer look.

There’s another benefit that should be noted: documents “inherit” relevant attributes directly from their overarching object, which may be a process or an eFile. This saves users from unnecessary work and also prevents inconsistencies and careless mistakes in metadata.

Speaking of metadata: It must be possible to describe all information objects without limits with metadata and to add further information as needed. Only if you have this level of flexibility can you bundle all required information, also from various systems, into one business object. What’s more, metadata is much more than a descriptive appendix. It also serves the function of regulating access to single information objects, managing retention or labeling sensitive information.

Considering the importance and the many different ways of using metadata, it’s mind-boggling that only a limited number of predefined metadata fields or types are available in some systems. Technically speaking, these kinds of limitations definitely make no sense. Rather, they draw attention to fundamental mistakes in the underlying information architecture. This can often be concealed from the user, but it ends up costing performance and flexibility later on.

In some ECM and DMS systems, or even CSPs, workflows are relegated to the status of second-class citizens. Then again, process- and data-centric offers manage documents often rather poorly. If you look at it from the perspective of business objects, you’ll quickly realize that both approaches can’t work: Sometimes the focus is on the process, in other cases it’s data-driven and again in other cases the documents are most important. Only one uniform metadata foundation and flexible linking options can give you the necessary freedom.

A unified platform is also what’s needed for innovative machine-learning services to exploit the value and information in existing content. AI methods rely on top data quality and a large pool of data in many cases. Information silos and poorly managed document pools are detrimental here. However, if ML-based services are integrated into the core of the content services platform, they can analyze not only new incoming content, but also retrieve all existing content from every connected system, plus information from and about processes, user comments, metadata, etc.

To clarify the title of this article: content services alone are no solution. But they are the right technology to digitally map business objects suitable for your users, suppliers and customers. This is how solutions evolve. When selecting a content services platform, careful consideration and strategic foresight are needed. Some vendors have simply relabeled their outdated and technically limited solutions. Other vendors are trying to best one another by offering new microservices — often developed by third-parties. Of course, how well these microservices fit into the respective platform is another question. If you build applications based on poorly tuned content services, you won’t create solutions, only new information silos.

The more open, flexible and unified the underlying content services platform is, the better it will digitally map the wide range of business objects. Create the best possible conditions by choosing the right platform. Your users will thank you for making their daily work easier, better and faster.