Enterprise CMS and Service Orientation

By Ghosh Palash Sep 20, 2011

Organizations have been constantly evolving and adapting the last few years to find a cost-effective innovative business model what will provide sustainability and create more business value. Certainly cloud, mobile and social remain key areas of focus in CIO/CTO's office. Product vendors and System Integrators (SIs) are constantly working to support organizations to achieve their business goals with the help of cutting edge tools, technologies and services in these three areas.

On the other hand, service orientation is not a competing business model or architectural style at all, rather this style is complimentary to cloud, mobile and collaboration. Many large organizations have already started their journey of service orientation few years back and have matured enough to handle some of the complexities around it with a strong governance model, whereas some organizations are at an early stage of SOA maturity.

I will not focus on generic SOA principles and its implementation in this article. So much has been written and talked on SOA. Rather I will try to restrict myself to the subject ‘how SOA is relevant to ECM'.

Setting the Context

It has been more than a year since I wrote an article on ECM & Portal integration - '5 Things to Consider when Integrating your Content Management System and Portal'. I received very interesting responses, comments and questions publicly/privately on this. Obviously that led me to believe that large organizations and product vendors, especially those using best of breed ECM & portal platforms and building ECM centric custom applications and frameworks, are really looking for this kind of integration solution. I will take the opportunity and try to answers some of the fundamental questions I have been asked like:

Why do we really need another set of custom services/wrapper service? Services are already shipped with the ECM product. Why can't we go ahead and directly use those from portal/client application instead of building another custom layer/wrapper on top? Frankly speaking, some readers were even bit upset. They think 'this is all mere wastage of time building reusable custom ECM services'.
How can we manage/maintain these custom ECM services?
Implementing SSO is killing us and this is too complex a deal. Too much of understanding, skill-set, effort is required to implement this. Is there any cookie-cutter approach?

All are very interesting questions indeed and all are very relevant questions. Before I start answering those above, I'd like to point out very clearly that no one architectural pattern exists that can suit and solve all business problem(s) for all organization(s). Every organization has a different way of functioning and will be dealing with different levels of complexity and tools, technology situation. So, architecture decisions will be driven by many business factors and non-functional criteria existing in that specific business house.
Readers should have a basic understating of tools/technologies related to ECM, SOA and SSO.

ECM Custom Service/Wrapper Service — We Really Need Those?

If you look closely, all the leading ECM vendors enable basic fine-grained content management services in the form of SOAP or REST (Native or CMIS) to expose the ECM product functionalities/features. So now the question arises why those fine grained services cannot be consumed directly from the client application/custom solution? Well, there is no one liner easy answer to this. It all depends on the business context of the enterprise where the solution would be deployed.

First of all ask yourself, do these fine grained services provided by ECM vendor bring any business value for your enterprise directly or indirectly? Let us not get confused with Web Services and true SOA services. Do these fine grained services (provided by the ECM vendor) satisfy some of the basic principles what you generally follow while defining your SOA services for your enterprise like:

Reusability
Coarse-grained (With optimal granularity)
Composite
Encapsulation (Hiding the implementation details)

If the answer is ‘no’ and we are talking about a large organization where different business unit(s) will be consuming the ECM services, you probably would like to build a coarse-grained, reusable custom ECM service layer. The reasons are two-fold as we make the decision for building custom/wrapper ECM service layer. Let's do a deep dive to understand the reasons with a specific set of business and technical examples.

Business Reasons for Custom Service/Wrapper Service

Sometimes large enterprises use more than one content management system due to lack of IT governance and decentralized IT decision making. So over the period of time, the organization builds silos. Sometimes, organizations inherit this kind of situation through merger or acquisitions. But business may like to do their content centric operations in a transparent and seamless fashion from their business application or portal while content is being managed in different disparate repositories/content management systems. So there has to be generic and composite content related services and those need to be designed/built across these varied repositories to serve the business. (Note: An effort towards consolidation and coming out with an 'Unified' infrastructure and repository in a virtualized environment/private cloud might be another approach/possibility to deal with this kind of situation, but it will depend on cost along with other factors like tools/technology maturity in the ‘ECM Cloud’ space .)
In some cases, for good reasons large organizations run different repositories/content infrastructure (mostly from same vendor) for varied business functions (DMS, XML Content Management, Transactional Content Management, Digital Asset Management etc). But the business interfacing application may need to access and consume the ECM services from all content repositories simultaneously. So, you may need to build composite services.
You will always find that a set of content centric business functions is of common nature across the different business units of an organization. The way (logic) content does get into the repository and consumed by different organizational business units may have similar pattern. As example, when you are bringing content from different parts of the organization, you might have a common rule to attach a Lifecycle policy specific to each business unit and initiate a workflow process. Besides organization wide common rule, we may need to implement business unit specific logic for content related operations.
Let us take another example, in a typical auto claims case management system, the claimant likes to initiate and track its claim via a self service portal and mobile device. An adjuster also like to see the claimant policy information and body shop address using his mobile device. So, we need to consume same service via different channels.
If you are a product or service company building an insurance solution, you may need to build a set of common ECM services for creating and retrieving content at different stages of insurance lifecycle (like new business, underwriters, policy holder services, claims processing) based on certain predefined rules.

Fine grained ECM services shipped with ECM vendors cannot handle all alone the above custom needs. You have to build business logic with the help of the fine grained services that come with an ECM vendor to get true business value out of them. Now you need to really decide whether you would like to write this business logic — at the client end or it would be the ideal candidate to write, manage and maintain those as 'ECM Services'.

I would vouch for writing this logic as ECM services especially in the case of large enterprise and product development situations. The reason is not only for commonness and reusability, but this also could give an opportunity for easy maintenance, registration, discovery, strong governance and can be even supported by a chargeback model if required.

Technical Reasons for Custom Service/Wrapper Service

Now what are the technical reasons behind building reusable ECM services having Organization/Departmental business logic built on top of OOTB services provided by product? All the leading ECM product vendors provide fine grained exposed APIs in form of Web Services to connect into the content repository and do the varied ECM operations. Now just think about a large organization where you share your content repository and expose the WSDL (Web Service Definition language) across the business units for consuming the services from their respective clients. Well, you can still go ahead and do that, but you would like to think about the following implications: