[Originally published on the TeraThink blog]

There has been talk of creating enterprise content management (ECM) platforms for years. They typically do not live up to the hype or expectations. The upfront investment typically required dooms most projects before they deploy their first business solution. It has reached the point where if an organization wants to implement ECM I typically walk away if I cannot persuade them otherwise.

That doesn’t mean that the need for ECM platforms don’t exist. Given the ever increasing creation of content today, it is even more important to be able to rapidly solve content-centric problems without creating numerous content silos. What is needed is an alternate approach to gaining the benefits of an ECM platform without forcing a big-bang approach to ECM with its large upfront investment.

The answer is to pick an ECM system the same way an organization picks a database system. Choose based upon the system’s ability to scale and meet the needs of the organization. An open API (application programming interface) allows the exposure of content services that can be used to add content capabilities to other applications and to build new solutions. Being open allows an organization to move forward without worrying information being bound to that system forever.

Removing Complexity

Years ago, enterprise architects designed complex systems that consumed services. This service-oriented architecture (SOA) approach became very popular. Part of this approach included the concept of an enterprise service bus (ESB) operating as a central transactional hub.

The ESB was necessary because many applications did not have easy to use APIs. Companies had to write their own layer of services that were existed as a separate application. People could not simply point at the source application for answers; they had to know where the service application was located. The ESB served as a central hub for developers and systems, allowing them find and consume services.

That approach works well when implemented correctly. It is also complex. Managing the system ecosystem is complicated and there are many points of failure that have to be monitored and maintained. It was quickly realized that the solution was making sure that applications had open APIs that could be directly consumed.

This push to an API-driven world has been reinforced by application vendors building their front-end applications using their own published APIs. By using the same APIs as the rest of the world, those APIs have become more robust, secure, and stable.

The building of applications with open APIs creates a strong focus what the business actually needs to accomplish. The consumption of small parts of an underlying application at a time allows for greater agility and allows for an organization to more rapidly respond to the needs of the end-user needs.

What is Open?

Open simply means that the entire API set is documented and open to use by anyone. There are no special features that are restricted to internal developers. If the system can do it, there is an API to make it happen.

There is more to being truly open than having open APIs. The support of open standards is also important such as the Content Management Interoperability Services (CMIS) standard. CMIS is a defined set of APIs that represent the features that every ECM system should support along with a well-defined domain model. It represents the minimum viable product (MVP) of any ECM system.

A critical piece of an open APIs is that they are supported. While not part of the formal definition, the level of support for APIs demonstrates the underlying commitment to those APIs. Are those APIs simply there for show or are they core to the strategy for success for an application? If they are strictly for show, the APIs will diminish over time in their usefulness.

Building Open APIs

There comes a time when content becomes even more specialized and business rules exist outside the ECM system, such as in a case management application. It likely leverages a database, an ECM system, and a business process management (BPM) engine to manage cases for an organization. The resulting cases are logical sets of information that span all three underlying system.

In government, there are a multitude of case types from investigative to FOIA (Freedom of Information Act) processing. Many involve constituents that do not have direct access to the system. The ability to make these systems self-serve whenever possible means having the public website communicate with the internal systems.

This can become complex, especially if the Federal agency had multiple types of information it needs to share. Web developers could reach out to each underlying system (database, ECM, & BPM) to bring together the needed information. Instead, the in-house case management system should publish its own APIs that allow the website, and other systems, to access case information as a single item. This would also be useful for FOIA systems retrieving copies of case information to comply with external requests.

The development and documentation of these open APIs allows for a broader network of systems to work together to meet the mission of the organization.

Open with a Purpose

Open APIs enable a new approach to solving existing problems. Instead of going through middlemen or recreating functionality, it allows for direct access to needed content and information. When these APIs are published, an organization’s mission is readily met through the use of these APIs.

This allows for flexible growth of systems as new needs arise. Rather than building complex integrations or mapping out the entire infrastructure on day one, organizations can implement what is needed most and make changes over time. This agility reduces waste by not building anything before it is needed.

In a world where things change every day, the agility that open APIs provide allows for the creation of robust content applications that has been missing.

(This is the second post in a series on creating successful, open ECM platforms. The series began with a discussion on stopping closed content silos. The series continues with a discussion on how open source and cloud enable open ECM platforms.)

[Editor’s Note: This post was originally published on the blog of Dominion Consulting. On November 1, 2017, Dominion Consulting merged with TeraThink and are now operating jointly as TeraThink. All blog posts migrated from the Dominion Consulting website have been updated to refer to ourselves as TeraThink.]