Enterprise patterns: eclipse

This is actually the subclause 5.5 "Making coordination explicit" from my book www.samarin.biz/book

A typical enterprise IT landscape is a set of monolithic interactive applications. Such applications usually have intra-application coordination in a very implicit way. Inter-application coordination is also implemented but in an ad-hoc manner – some changes of data stored in “Application A” should be copied to data stored in “Application B” outside the normal working hours. (Such a data transfer is implemented as a “batch”, i.e. a non-interactive or non-attended application.)

This is data-oriented coordination (see the figure below). Sometimes, an IT unit does not have the full picture of all intra-application dependencies, because they have been established in a decentralised (person to person) and, often, a “quick & dirty” way. The resultant coordination is often a complex “web”, and sometimes it is not clear which business process is affected by which applications or batches. The respect of SLAs requires serious efforts from the IT unit. Maintenance is frequently expensive since the evolution of one application may necessitate the alteration of others.

Data-oriented coordination

The use of control-oriented techniques for intra- and inter-application coordination allows the untangling of these “webs” into several (per business process) explicit cases (dealing with smaller building blocks), i.e. services but not applications, thus making your enterprise business system easier to control and evolve. 

Obviously, monolithic applications were not created for such a radical transformation. Imagine that a working application should be disaggregated into services and the coordination between them to be formally established with an additional tool. In many cases this will be a risky project without any obvious Return On Investment (ROI) and with a lot of resistance.

We recommend introducing control-oriented coordination using a step-by-step approach via the “eclipse” pattern (see figure below). At first, we “cover” only a tiny area of the whole process. Usually we start with the intra-application coordination, because this part of IT is considered as boring and not very rewarding. The first fragment of explicit coordination may be quite primitive; it is a duplication of some existing functionality which is just eclipsed by this process. Then we introduce more and more fragments. With time, we cover bigger and bigger areas by explicit coordination of existing fragments.

Use of the “eclipse” pattern for making coordination explicit 

Step by step, existing applications are transformed into services. We recommend that such transformations be carried out with great care. For example, at first, services should be implemented to copy as closely as possible the existing functionality; they are optimised and refactored only later. Modifications to applications are minimised – by preference, we just switch off some functionality.

And the recent blogpost which relates to this topic is http://improving-bpm-systems.blogspot.com/2013/05/integration-via-bpm-become-friendly-to.html

Thanks,
AS