Challenges of a modern content platformWhile we saw in our last post, as a primary requirement and challenge, the need to really enable the building of content-driven processes and applications, we'll look now and in the next posts of this serie at some more technical requirements.

Providing Modularity and Extensibility

No vendor can anticipate every use case that must be supported for managing enterprise content. New content types, standards and business models are constantly being developed; therefore, it is important to select an ECM platform that is architected for interoperability, customization and extension – not something all vendors support. Lack of extensibility can have a direct impact on business capabilities. Over half of businesses indicate that lack of ECM tool support for their requirements is restricting their ECM adoption (Miles, 2011). The chart below illustrates some of the reasons supplied:

Reasons for Inability to Meet ECM Vision

Reasons for Inability to Meet ECM Vision (Miles, 2011)

A well-designed ECM platform will support extensibility and customization in a manner that is predictable, sustainable and affordable. Let’s explore what this means.

At a minimum, a well-designed content platform should be modular, component oriented and deliver functionality as a set of independent, decoupled features (services) with few dependencies between the components or to the technical environment. This design allows architects to choose the precise set of features and services necessary to meet project requirements. In addition, the platform should have an exposed API that can be used to access platform services without “hacking,” engaging specialty vendor resources or purchasing add-on products. Other platform features to support a sustainable model for building ECM applications include:

  • Testability: The platform should support testing extensions/customizations without being overly cumbersome. Ideally, the platform should easily integrate with a testing platform and allow continuous integration so that the functional and non-functional (e.g. performance) aspects of customizations/extensions can be verified. Solutions such as the Hudson and Jenkins continuous integration servers have grown more popular, and ideally an ECM platform should enable teams to leverage these tools.

  • Multiple API Strategies: An extensible ECM platform should expose multiple application programming interfaces (API) to allow the project needs to dictate the integration strategy. Ideally, the platform should provide multiple strategies such as native language (e.g. Java API), REST, SOAP, or standards-based interfaces for accessing the underlying ECM features

  • Support for standard languages such as Java, PHP or others as opposed to proprietary vendor implementations. Vendors may elect to implement support for recently introduced “hot languages” to generate interest in their products. Architects should carefully evaluate the value of the languages supported for factors such as adoption of the language, size of the developer community, the intrinsic qualities of the language and the staff’s ability to support applications written in the language.

  • Consistent internal developer and client API: A consistent and supported mechanism for extension by internal (vendor) development and external developers,which enables customer extensions to look and function like native vendor features. Vendors should support this mechanism beyond a single release and have an upgrade path that makes it possible to benefit from new releases.

  • Deployment: The ECM platform should support multiple deployment strategies, from simplistic single server to high-availability active/active and disaster recovery, from on premise to cloud-based. It should support complex deployment configurations designed for application validation (e.g. test to staging to production). In addition, the platform should allow deployment of customizations and extensions in a predictable and controlled way across all environments without impacting core platform functionality.

  • Performance Benchmarking: The platform should have regular benchmark data published and allow teams in charge of implementation to define their own performance tests based on their specific use cases and application needs.

Stay tuned to learn about other challenges and requirements, and especially our the client-side of applications also matters in a platform!