Information Technology Reference
In-Depth Information
First, we need to build a plan based on the loose coupling of high-level views,
with conversion by interceptors at the domain boundaries to solve detailed
incompatibilities, and then follow this up with an incremental campaign of
rationalization and alignment. This is a good strategy because time is of the
essence. The CIO of a new telecommunications startup once told us, of the
record, that they had \the most modern legacy system in the business" be-
cause time pressure had forced them to clone the billing system of one of their
competitors, rather than deciding all the detail of what they really wanted.
The most dicult part of this process is likely to be predicting who the
major stakeholders will be and how responsibilities will be assigned in an
organizational structure that is very likely to be fluid for some time. This
suggests that there are benefits in aiming for a looser coupling than usual
between the viewpoints. It also places emphasis on tools again, this time in
support of the refactoring that is bound to follow.
Refactoring is also a key ingredient in divestiture, but here the sequence
is reversed. Once the possibility of detaching some business unit has been
identified, its interactions with the rest of the organization need to be codified
and then processes refactored to weaken mutual dependencies. Domains need
to be established clearly, and interceptors introduced, not because of any
deliberate intention to introduce incompatibilities, but because the domain
boundaries will become points at which the assumptions of trust change, and
so management controls will be needed.
It is clear that this topic is more a management issue than a technical one,
so the reader should look to sources in those areas and we say no more on the
topic in this topic. However, we do stress the importance of having a proper
architectural framework, like ODP, providing a robust enterprise model for use
as a roadmap when planning and carrying out any such large-scale transition
activity.
13.6 Version Control
As we indicated previously, the management of system evolution takes us
beyond the scope of the ODP reference model, since the model concentrates
on capturing one particular design for the system. However, considering how
to support system evolution raises a number of significant issues, and it should
already be clear that there is a requirement for powerful modelling tools to
support evolution.
One of the limitations of current specification languages and tools is that,
like ODP, they concentrate on a single specification of the required enterprise
system. In the future, these tools will need to be integrated with powerful
version control mechanisms and evolution planning aids, so that a designer
can produce a revised version of the system specification to support proposed
