How was Training?


Good class - SR MGR IT, PPDI, USA, Sep 2010

Recommend PEAF?


No - Don't understand enough about it at the moment - Enterprise Architecture Manager, Provident Financial, UK, Jan 2015

  Introduction   Context   Methods   Artefacts   Culture   Environment   Adoption  




<< Previous <<

>> Next >>

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 repository.

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 maintenance nightmare.

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.


What Tools do you use for Transformation?

Where do they fit into Transformation domain?

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 kept synchronised?

How can data in one tool be related to information in another tool

Are there any issues or problems?

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?



2008-2016 Pragmatic EA Ltd