This blog post is about architectural guidelines for EPiServer CMS and enterprise architecture – mainly integrations patterns.
When attending EPiServer Partner days 2012 there was a presentation on how EPiServer can – and often is – utilized for integration purposes for loading and storing data from external systems. This made me somewhat uncomfortable.
Joel Abrahamsson wrote a great post on EPiServer integration patterns. It’s well worth your time if you haven’t read it. The article you’re reading now, however, doesn’t focus on how EPiServer as a platform should be used as an integrations engine, rather how it could fit into an eco-system where solid architecture integration patterns are key.
Our CMS is not an island and we are not Jack Sparrow in the enterprise world
The days when the CMS was an island of information are long gone. Integration is part of virtually very CMS site today. It ranges from simple value fetching to constructing complex data hierarchies.
When designing integrations with the CMS you must also consider the possibility of other systems also being interested in consuming the same type of data. This is where the enterprise focus comes into play.
Just to be clear: pirates & islands are still awesome
Point to point integrations
Point to point integration, or “spaghetti integrations”, are a nightmare to maintain. When you find yourselves building direct dependencies to other systems using EPiServer CMS you’ll soon also find yourself in a big bowl of spaghetti integrations with tight couplings to other systems.
Should the coupled system change its contract, be down for maintenance or suffer a catastrophic failure you’re in a bad, bad position. Point to point integrations should be avoided whenever possible.
Scheduled jobs & storing data in EPiServer CMS
Scheduled jobs are a great feature in EPiServer. They’re great for site maintenance, publishing and unpublishing pages, sending e-mail, etc.
What you should avoid, though, is implementing them to function as integration components for line of business (LOB) systems where complex business logic is introduced. What’ll happen if you do go down that road is that you’ve effectively spawned EPiServer CMS into an integrations platform which never was its main purpose. The scheduled jobs have now become responsible for updating and maintaining duplicated key business data now stored in EPiServer CMS.
When a new application is introduced that also sports an interest in the same data you might create a service in EPiServer for the purpose of making this data available. Now we find ourselves with a potential train wreck – we’ve effectively coupled the underlying LOB system with EPiServer CMS and EPiServer CMS with the system(s) that consume data from the new service.
Lego train wreck
Your alternative is to couple your new application with the LOB system and duplicate business logic already implemented in your scheduled job. Should the business logic change, though, you’ll have to make the change in every system that implements it and roll out new releases.
It looks like we’re in a bit of a conundrum. Let’s move on and see if there’s a better solution.
Fortunately there are trailblazers for integrations architecture done right. Microsoft has provided a reference architecture dubbed Three-Layered Services Application architecture.
Three-Layered Serviced Application
The architecture separates presentation, business an data into three separate layers: Presentation, Business and Data. Communication, operational management and security are cross-cutting concerns and affect all three layers.
From an enterprise perspective the UI layer consists of components that present content. This could be a website, an app or a simple console application.
How EPiServer CMS fits into the picture
EPiServer CMS in the reference architecture is a UI component. Its purpose is to consume and present data. The benefit to approaching EPiServer CMS as a UI component is that we’ve effectively decoupled EPiServer CMS from any LOB system. Business rules can be maintained in a separate layer and other systems can consume the same data.
Another benefit is that when the data changes in the LOB system, and is made available through the services, the change is available in all consuming systems. We’ve avoided creating a potential train wreck.
The architecture would therefore be represented as seen in the illustration below.
Enterprise integrations pattern with EPiServer CMS
How EPiServer CMS consumes the services is considered secondary; it can be implemented through a custom page provider or directly from a page. The options here are numerous and should be implemented as appropriate.
I hope this helps projects out there that implement EPiServer CMS as part of an enterprise solution.
Thanks for reading!