Can we use another Content Management System with Hybris?

I cannot remember how many times I have been asked this question. The answer to this is based on principles of design that you use to identify the application stack for your It landscape.

Why would a CMS exists in your application landscape 

Content management system has its own space in the landscape. There is a difference between an Enterprise content management system(ECMS) and a web content management system(WCMS).

Let us first list the features of enterprise CMS: 

1. Content creation and aggregation
2. Authoring
3. workflow and approval 
4. Managing and Archiving
5. content distribution
6. Archiving and version control
7. single repository of content.

The web content management exists in the landscape for a different reason:

1. Provide the POS (website) with content to display on its pages.
2. helps target and display content based on customer segmentation
3. converted a generic content to a channel specific content (HTML etc.)
4. Supports the web process with web centric content.

However this does not mean the WCMS will not have all the functionality that the ECMS has. They do exists in some form on a WCMS to create and manage content, should ECMS does not exists in the landscape. But I would question the level of maturity of those functionality on an eCommerce platform whose primal necessity is to power the e-commerce function.

Getting both to work with each other

Having made the case for both to exist in the landscape, the next obvious challange is to get them to integrate.

There are two integration patterns which has in the past worked well for me:

Option 1: Content produced in the ECMS and migrated into the Hybris PIM

As the content is produced (for product description or otherwise) the content is transferred to the Hybris PIM as an overnight feed.

Once the content is in the PIM, the component controllers can lookup the relevant content from the PIM based on the appropriate tagging

Some major advantages for this pattern are:

1. Allows content to be created and consumed from multiple sources.

2. No latency in content display

3. No dependency on availability of content system to fulfill the call.

4. Synchronization issues sorted upfront. The Website has some content to show even if the synchronization fails.

Option 2: Content produced and served by the ECMS and Hybris does a page based request to content.

As the content is produced in the ECMS, we need a web adapter to retrieve the content real time. 

The call to retrieve the content could either be done by the controller marked (1) or by a AJAX based call marked (2) by the loading page. The decision will be based on your latency and availability of the ECMS tool. Do forget to predict and manage the additional load on ECMS. The trick may be to create a simple Java/.net adapter on a open source server which can be easily clustered at low cost.

This pattern has its advantages:

1. Single source of truth for content.
2. Ease of publishing (straight from the source to consumer)
3. Should work well for large and heavy content (rich media etc.)
4. Low eCommerce tool cluster size as traffic is distributed
5. No complex synchronization

Summary

While its possible for ECM and Hybris to co-exists, the decision should rely on why we want from both the application. However the challenges revolve around integration and the nature of content that is shared across the system. Connecting content across multiple system forms a formidable challenge and in some cases also needs updating the organisational business process to manage consistency.

Hybris Extension based development

Speed Vs Complexity

We are often challenged to deliver quickly.  "develop in parallel teams" , "double the team size" is usually the battle cry. As an architect that means design in parallel and then the system that get integrated at the end. As the design and delivery challenges are won , the effort in code merges mount exponentially, especially when multiple team ended up building code in silos. I have recently faced this situation in a Hybris development project.

Traditional Hybris development

The developers in multiple teams were working on copies of the same code with limited control over who changed what.

While merging, the process included

- merging of global object definition as a super set of both the developments

- merging of facades and controllers for the web front end.

- merging of core classes caused the developer to use a file diff software to trace what has been changed.

With the current code base at a critical of 10 million lines of code - it is understandable why it took so much time to merge.

Using extensions to separate code

We found the answer to the problem with a simple re-structuring exercise. Simple !!! Not really !! The exercise was not simple - but the concept is. The burden was legacy code. However allow me to explain the concept:

  Instead of using one web extension, we create a series of extensions that can be categorized into three categories.

• web based extension that had a URL / context and can act as a channel. All the JSP's, controllers and facade are present in this extension
• Extension (web without URL) that allowed implementation of business level services and owned by a team. This extension had a one or more interface that implemented a business logic for other extensions to consume.
• integration level extension that allowed to build integration code with third party systems and can be stubbed for ease of development. 

One additional extension was created to store and manage the domain object definitions for the entire stack. This extension is tightly managed by the designers. This allowed to keep governance on the objects created, defined and persisted across the entire system thus restricting individual teams  to create domain objects at will.

Pattern Enforcement and ownership

The concept of communication was codes in one extension can call codes or interfaces either in same layers or in the layers below. This patterns enforced are:

• Facade pattern
• Chain of command pattern

Along with the pattern enforcement each team was given the responsibility to own and deploy their own extension. If a business extension is owned by the team, the team is responsible for releasing the code with the appropriate interfaces from time to time.

	Extension 1	Extension 2	Extension 3
Team 1	Own	Use	Update
Team 2	Use	Own	Update
Team 3	Use	Update	Update
Team 4	Use	Use	own

When a team launched a new version of the code, it will use the matrix to inform the necessary team for the changes and its impact. The changes are again manged by release plan as opposed to random updates.
For example , Release A will have Extension 1 (V 1.2),Extension 2 (V 2.2) and Extension 3 (V 1.0), where as release B will have Extension 1 (V 1.3),Extension 2 (V 2.2) and Extension 3 (V 1.0). The project that updates the extension 1 to 1.3 lists the service class changes and communicates the changes to other teams.

Benefits in merging

The Merging is not chaotic anymore.
From the configuration management plan  for the release, we know know which version of the code to check out. Along with the global modules, its a matter of placing the directories in the right folder, updating the extensionsinfo.xml, and running the ant scripts.
Of course the web extension may need merging of the controllers and JSPs but a different domain and and project intials appended to the jsp pages will reduce copying conflict.