2013-06-06

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.