Information Technology Reference
In-Depth Information
said. \But look here," said Claire, \we can't add all that into the application
design, or we will lose sight of the application architecture. It will be a mess.
And we don't need the application and infrastructure teams to duplicate each
other's work."
Marcus banged the table. \Hold on now. You are all talking at once. Alex,
you haven't spoken yet. What's your take on what you have just heard?"
Alex stood up and walked over to the ipchart. \I think you have all made
good points." He said. \This is a very large design, and there are conicting
requirements, needing different focuses and levels of detail. The best way to
handle it is to divide and conquer; you should identify the key stakeholders,
and then describe the problem from their points of view. If you can identify the
right stakeholders, the different views can be largely independent, and so they
can be worked on in parallel. The framework I want you to work with is called
ODP, and it stresses ve such viewpoints." He sketched a diagram on the chart
with ve arrows converging on the design problem. \These correspond roughly
to organizational responsibilities in a situation such as yours, namely business
processes, systems analysis, data integrity, infrastructure and intellectual or
physical resources. If you each start with your own focus and the level of
detail you need, we can then link the different views together to describe the
complete problem."
\What I would like each of you to do is prepare an outline of the require-
ments as you see them, and then we can see how they t together and move
on from there."
\OK then," Marcus said, \let's do it, and meet again on the 28th to see
how well it works. That's all for now; I've got to talk to the nance people
again." He stood up and stalked out of the room, leaving the discussion going
on; it was still going on hours later.
1.1
The ODP Reference Model
The aim of the Reference Model for Open Distributed Processing (the RM-
ODP) is to provide a framework for specifying and building large or complex
systems; we call the systems being produced ODP systems. These systems
may be classical IT systems, information systems, embedded systems, business
systems, or anything else in which we are interested.
If a system is at least moderately complicated, it is useful to extract the
description of its structure and external properties from the details of its com-
ponents or subsystems. If this abstract view concentrates on the distillation
of general principals, it is called an architecture. When presented in a way
that is useful for the derivation of a whole family of future systems, it is called
a framework. Hence, when describing a business system supporting a broad
range of applications, it is common to talk of an enterprise architecture or an
