Sitecore Helix – Supporting Integrations

This blog will outline how it is possible to identify, separate and isolate dependencies on external systems, by introducing an Integrations module group. See here for more information about module groups in Helix.

But why do we need a Integrations module group?

Any feature that requires integration to achieve its purpose, will introduce additional challenges relating to stability and additional system knowledge, than a standard feature layer module.

Stability

Helix is built on a number of principles that help deal with stability, the Stable-dependencies principle and Stable-abstractions principle for more details see my blog post.

Features that rely on 3rd party systems are by nature more unstable than any other feature/foundation modules. As it is not usually possible to control when external systems change, upgrade or fail. Therefore, quality assurance, test, and automated deployment for the website cannot protect against this type of change or failure.

System knowledge

Working with a 3rd party system, such as CRM, ERP, Marketing Automation, DAM, SolR, Custom API, etc. requires additionally system specific knowledge. So it is a good idea to use abstractions to hide the system specific complexities for several reasons:

1. The web team might not have the specific system knowledge.
2. The web team should not be distracted by the additional complexities of all the integrations.
3. The team responsible for implementing the integration may have limited Sitecore knowledge and should not be distracted by the rest of the web solution.
4. It is good practice to separate modules by their responsibilities by splitting the presentation and the retrieval of data from the external system.

Integrations Module Group

The intention/purpose of the Integrations module group is to clearly define which modules have a dependency on an external system and ensure they are only responsible for that integration to the external system.

Example

This solution is responsible for selling a wide variety of courses. The customer has its own custom course catalog API and a complex legacy enrollment system.

The following diagram shows the module architecture for the solution.

In the foundation layer the following modules were introduced to provide abstractions. If you are not familiar with IoC and Abstractions see my earlier post.

• Course Catalog
  • Defines the abstraction/system agnostic logical data module for the course catalog.
  • Acts as an abstraction between the website and Custom Catalog API.
  • It helps to focus on the ideal model that supports the business objectives.
• Enrollment
  • Defines the abstractions to support the process of initiating attendance on a course at a specific school and shopping cart.
  • Acts as an abstraction between the website and the enrollment legacy system.
  • It helps to focus on the ideal model that supports the business objectives.

In the Integrations Group in Features layer the following modules where introduced

• EXT Course API
  • Responsible for getting data provided by the EXT Course API.
  • Provide the implementation of the Course Catalog (foundation layer) abstractions.
  • Responsible for caching the course catalog, as the API only supports periodical batch retrieval.
• EPOC Enrollment Management
  • Responsible for integration of the functionality provided by the EPOC Enrollment Management SDK.
  • Provide the implementation of the Enrollment (foundation layer) abstractions.

In the Features layer the following modules where introduced

• Course
  • Responsible for the presentation of the course catalog, retrieved via the course catalog abstractions defined in the foundation layer.
• Enrollment
  • Responsible for presentation and controlling the process of initiating attendance on a course and displaying the shopping cart, using the abstraction  defined in the foundation layer.

Additional Bonus

Once the integration code is isolated in a single module and only responsible for the integration, it is easier using dependency injection to achieve the following:

1. Update external system, as the code to change is clearly defined and separated from the presentation and website logic.
2. Provide the ability to support more than one version of an integration (i.e. different sites use different version)
3. Move the integrations modules to an integrations platform, if it is the domain model for the customer business.

I hope this blog post gives you some ideas on how to isolate and remove the complexities introduced by integrations from your Sitecore solution, Alan

In my next post, I will explain why and in more detail how to isolate the SolR integration.