Each physical Tool tends to consist of two parts:
A Repository that stores the information.
A Tool which allows a user and other tools to manipulate that
However many tools an Enterprise uses, an overriding
principle should be born in mind, which is that people working within each
phase need access to information not only in the level associated with that
phase, but also with the information in the levels preceding and following
phases. Integration of tools is therefore key - not only within a phase but
also across phases.
To enable this (and to minimise integration overheads and
associated synchronisation problems) it is usually advisable to minimise the
number of physical tools used in any one domain (Option A), however, the number
of physical tools that an Enterprise decides to buy is a personal choice and
based on many things, not least the tools they already have and the tools
available in the market.
If two tools are used (Option B) the integration is probably
manageable, however more than two tools (Option C) can cause an integration and
If more that 2 tools are utilised a possible solution would
be for multiple tools to all sit upon and integrate with one common repository
(Option D), or if that is not possible for multiple tools with their own
repositories to integrate with one master repository (Option E).
Options D and E would also be beneficial for integrating all
tools in the entire Transformation domain, however, these options are only
possible if the Tool Vendors had had the foresight to think of them and had
made the necessary investment to provide that functionality to do so -
particularly for plate D.
The problem of these “interfaces” are largely of a technical
nature because tool vendors need to come together to agree on a method of
allowing their tools to interact. Open Service for Lifecycle Collaboration
(OSLC) is an open community trying to define a set of specifications that enable
integration of Transformation tools. Its initial focus is around software
development but the specifications should be (fingers crossed!) equally
applicable to any set of tools that need to work together cooperatively. Their
primary intention is a simple one - to make life easier for tools users and
tools vendors, by making it easier for tools to work together. www.open-services.net
What Tools do you use for
Where do they fit into Transformation
Are there overlaps or gaps?
Which of your Transformation
tools exchange or reference data used in other tools?
Which Option (A-E) best
describes your approach to the integration of tools?
How is data in different tools
How can data in one tool be
related to information in another tool
Are there any issues or
What will you do to alleviate
or solve them?
Do you have a coherent and
holistic strategy for which tools you use where and for what purpose?