Information Technology Reference
In-Depth Information
pair order. Some of the dynamic schemata will also need to be updated to
represent the new paths and artefact states in the enterprise processes.
The consequences of changes to the information objects will flow through
more or less automatically to the computational specification, which already
bases its view of business objects on the information objects. However, it
will also need to flesh out the dialogues involved in interacting with the new
agent role, and design work will be needed, for example, to extend scheduling
algorithms and interactions with the logistics supplier to support the new
activities.
In this particular example, the engineering specification is unlikely to be
significantly affected because it deals with reusable solutions to the problems
of providing interactions, and the kinds of interaction with the new agents
are not fundamentally different from those that are already being supported.
However, new solutions may be needed if introducing novel styles of compu-
tation implies that there are new problems to be solved. One area that might
need some extension is security, as the balance of trust and threat may be
different from what was previously accepted.
Finally, the technology specification will need to be extended to describe
the new form of terminal needed in the agencies and to capture the enlarged
configuration that results.
At each step in this process, change will be triggered by the discovery of any
inconsistencies. Where there are established patterns of correspondence, these
can be used to discover when new elements in one viewpoint require addition of
corresponding elements in another viewpoint to maintain the pattern. Again,
this change propagation can be automated using suitable tools.
13.4 Avoiding Synchronized Transitions
Even in the smallest distributed systems, it is dicult to make changes that
need to be applied to multiple components at the same time; for configurations
of any significant size the strategy of turning everything of updating all
components and then restarting is both too disruptive and too high a risk to
contemplate. It is taking a step into the unknown, and is just too much like
a novice attempting Olympic ski jumping. Any practical evolution strategy
needs to be based on the application of incremental changes in such a way
that it is possible to introduce any particular kind of change to the individual
component systems one at a time. Even with the best planning, problems will
be encountered, and it must be possible to roll back local changes as these
problems are identified.
One way of achieving the required incremental development is to ensure
that the interfaces that are bound together in a design always comply with
the so-called no surprises rule. This states that no component should ever be
