Content services are slowly seeping into people's worldview of enterprise content management (ECM). They understand that using content services to build a strong user experience is a better investment than a fully-featured single user interface. Businesses are starting to use the content engine's API service calls to build their tools. Slowly, applications are becoming stateless, allowing for the massive scale needed as content continues to grow in volume.

In the midst of this period of exploration, people are starting to make the same old mistakes. Just as databases are more than powerful spreadsheets, content management systems are more than glorified file stores. Simply providing generic system APIs fronting a content model and a collection of automated policies isn’t enough. Businesses implemented ECM in this way for decades. To succeed with content services, we need to build a platform that delivers business-centric services.

Related Article: Content Services Might Just Solve Our Old Content Management Woes

What Problem Are You Solving?

The first question I like to ask the organizations I work with is, "What problem are you trying to solve?" Obviously, when discussing content management, content is involved — but the issue isn't strictly a content problem. It may be a contract, correspondence or submission management problem you're trying to solve. When you design the services to merely solve the content part of the equation, you're failing to provide value to your users.

Your employees aren't searching for random "contract" related content. They want a specific contract and all the details around it, including the history, drafts, initiating correspondence, and everything else that falls under the business entity known as a contract.

Orchestrating the Content Flow

Every content engine has different strengths. I always look for ones with a strong API, solid developer support, and the core features that meet all of my client’s complex requirements. Approaching selection this way can usually narrow down the field quickly. But know, you’ll never find a system that does everything exactly how you want.

When you offer complete content services, you will need certain features that may not be available or robust. At this point you need an orchestration layer to take the incoming request and process it appropriately.

Consider a government agency. When content comes in, the system may need to translate it into specific formats to support the different applications and environments which may later access the content. Critical audit and encryption rules will likely need to be implemented. Other systems may need to be notified whenever a particular type of content is finalized.

That is a lot of features to fit into one content engine. While it's possible to deliver most by extending the platform, you run the risk of restricting upgrade paths or locking yourself into a vendor. Having an orchestration layer that can analyze the request and then call on the necessary systems to deliver needed functionality is key. It is how you make successful modern applications.

Applications are no longer expected to do it all. Orchestration layers bring the needed APIs together to deliver a core business service. In today’s world, that service increasingly includes content.

Related Article: Why Enterprise Content Management Is Giving Way to Content Services

Learning Opportunities

Employees Want Answers, Not a Look Under the Hood

Records management follows a basic rule that also applies to designing successful content services – do not make people work. The average person has zero desire to be a records manager and the average developer doesn’t want to know all the details of the systems underlying the content services.

Putting a layer of abstraction that speaks purely in business terms between the user's request and the resolution is vitally important — every content service call enters through this layer. Known as an API gateway, it can track traffic and send requests to the right place.

The URL of this article begins with Behind that URL is a collection of servers, virtual machines or containers with different physical addresses. As you navigate the site, you may be directed elsewhere physically but every request you make still goes to the same place before being directed.

Content services work in the same way. An employee may want to work with cases and case documents, but they don’t want to know where their calls are going — be it through an orchestration layer, directly to the content engine, or to some other hidden service. They are simply trying to get work done.

With Time, a Solution to Our Productivity Problems

Let this article serve as a warning: do not repeat the mistakes of our enterprise content management past. Simply building an application using the content service APIs provided by a content management vendor is not enough. It puts too much onus on developers to learn how that vendor thinks, instead of letting them focus on what counts: building the best user experience. Abstracting those details allows application developers to think about how the business gets work done, not how things are being done behind the scenes.

An abstraction layer takes time to build, but so does any application when you use a content engine for the first time. The second application takes dramatically less time and changes to business rules become a lot easier to implement. The true benefit comes when multiple applications begin to work against the same content services. Content does not exist in silos. By exposing it through content services built around a business domain, expanding the accessibility of an organization's content becomes easy.

Content that is readily captured, discovered and accessed is content that contributes to the mission. Done right, content services has the potential to finally deliver on all the productivity promises we've been hearing about for years. And not just in isolated cases, but across the board.

Take the time to plan things out and you’ll be surprised how far you’ll be able to go.