Over the next few weeks we'll be taking a look at the challenges and requirements for a Modern Content Platform. In this first part, we'll introduce you to the underlying architecture designed to address these complex business requirements and take a look at how this model provides a truly flexible and extensible solution.
Enabling Content-Centric Processes and Applications
Some organizations have made significant advances in leveraging ECM tools. However, in most cases, use of the technology is still not optimal. Why? Many consider ECM a stand-alone tool instead of a middleware component that provides services capable of supporting an extremely diverse set of business functions from invoicing to case management.
For example, a human resources department may need a technology solution to assist in executing the new hire process. This is a content centric process. A resume, a potential employee profile and interview feedback are all potential content types. The scenario may be even more complex. There may be a requirement to automatically provision an accepted candidate in the user directory, or integrate with a web content management system or other business processes. No “boxed” ECM application is likely to meet these requirements perfectly. This is a content-centric application. Instead of custom developing a solution using a lower level framework (e.g. Hibernate for persistence) the organization could benefit from the capabilities of a content platform for managing the process.
Although electing to adopt a content platform versus a traditional ECM application has a number of benefits, some architects may question how to best integrate the components into their technology portfolio. The diagram below illustrates one possible architectural model for organizing content-centric applications using content platform components.
In this model, the ECM platform exposes services such as workflow, authentication and access control and auditing via one or more interfaces that can be used to build custom content applications or integrate with existing packaged and enterprise applications. In addition, the content platform also provides direct access to stored content via standards-based interfaces (repository services). The content platform can be used to build content-enabled applications that leverage either the content directly or the set of high-level services provided by the content platform.
In this model, a user interface layer offers frameworks to expose its services to different user interface technologies. These frameworks can be leveraged to create custom interfaces from the platform that adapt to the organizational context, making user adoption smoother and reducing the user learning curve.
A platform should be architected in a modular and flexible manner. It should expose an entire framework for use by developers, and not simply a content repository. Many ECM tools tend to be architected around the content repository only, providing no additional layers. This is a more traditional approach, inherited from the client-server era.
A platform should also provide a comprehensive set of services, from low-level directory services to high level user interface services. This is the design of a platform that supports integration. It is designed to be extended and assembled by developers making solutions from the platform.
Whether this model is implemented or an alternate ECM design strategy, a componentized, platform centric approach is the key to delivering truly flexible ECM. ECM evaluations and adoption discussions should move away from specific applications and functional implementations that assume requirements and toward one of content frameworks that can be easily customized and extended at the repository, platform and user interface level to work in the manner that is most appropriate to meet organizational needs.
Next up: Part 2 will go more in depth focusing on modularity and interoperability. Stay tuned for more!
Roland Benedetti for Contentgeeks.net (@rolandbenedetti on Twitter)