Information Technology Reference
In-Depth Information
is the local centre access, and you can still use the replication transparency
dodge to avoid visible complexity there."
\OK," said Marcus, \what's the down side?" \You have to allow for the risk
and the recurrent cost. Costs shouldn't be too far from a realistic total cost
of ownership for the in-house solution, and may well be cheaper. There are
always hidden costs you miss when assessing doing a job in-house. Risks are
more dicult. You have to plan for commercial failure of your supplier, but
they are a big player. You should look at a lower quality fallback system in
the local centres and set up a commercial hedge." \You mean betting on the
commercial failure of the biggest bookseller on the planet?" asked Ira. \This is
serious dealing." \Indeed, but it has to be considered. More important, I think,
are the risks to security, confidentiality and loss of control it implies. Do you
trust your supplier to maintain a really stable service offering without changes
in the specication? There is always the risk of over-enthusiastic upgrade."
\Surely upgrades are safe?" Marcus looked puzzled again. \Improving a service
can't be a problem, can it?"
\Oh yes it can," said Eleanor, ruefully, \remember that online sales tax
system a couple of years ago? We had just got it nicely bedded down when
they upgraded it and added a whole extra level in their data model. It took
weeks to get the miscodings out of our financial data and the internal audit
people still remember all the special reconciliations."
\OK, I remember that, but the idea still sounds interesting.
Let's talk
about the detail."
12.1
What Does This Product Do for Me?
One of the practical problems in using an architectural framework like ODP
is that the world is seldom as simple as the textbooks assume. The picture
of development taking place in isolation, from requirements to deployment,
is far from reality. Rarely can a design team produce the specification of a
complete enterprise system as a self-contained activity. Usually, they identify
at least some components that are available elsewhere. The incorporation
of commercial off-the-shelf products (COTS subsystems) shows the clearest
separation of design responsibility and gives the best illustration of the issues.
However, use of legacy components involves the same problems.
In essence, the problem to be solved arises from the need to retain the
advantages of a clean architectural approach while incorporating subsystems
that have already been produced, outside your control, and based on a different
framework, or even with no clear framework at all. To be specific, how can
components from a non-ODP culture be incorporated into our ODP world?
When you purchase a COTS product to perform some function, you sur-
render control of the detailed design. On the other hand, you get a working
