The use of Tools tends to grow out of the need people have
to deal with the volume and complexity of the information they use to do their
jobs or for people to be able to do things that they could otherwise not do.
Configuration Management Tools grew out of the need to deal with the complexity
and volume of the information in operations. Software Tools grew out of the
complexity and volume of the information related to Software. Requirements
Management Tools grew out of the complexity and volume of the information
related to Requirements, etc, etc.
The Green boxes with Blue lines, indicate areas where
specific tools could fit. Before we start executing projects, we are dealing
with the whole Enterprise at the Contextual and Conceptual levels, and so it is
logical (and possible) for us to use one tool to do so. However, as we move
into project specific areas of greater detail at the Logical Physical, and
Operational levels, it is more usual to use tools that are specifically
designed to satisfy a particular discipline, such as Requirement Management
tools, Analysis & Design tools, Testing tools, Project Management tools,
Configuration Management tools, etc.
A tool could be as simple as a pen and paper but as the
complexity and volume of the information rises, it is more common to use
software based tools because (if used correctly, because “A fool with a tool is
still a fool”) they reduce the maintenance burden and can provide analysis and
visualisation functions that would otherwise not be possible. The information
people use to do their jobs with respect to Enterprise Transformation splits
into two fundamental types, Structural information and Transformational
Information as defined by MACE and MAGMA. In order for people performing a role
at each level of the Transformation Cascade™ to be effective and efficient,
they need access not only to the primary information at their level but also,
in decreasing amounts, to the information at other levels.
Many Enterprises buy many tools, but these tools are usually
bought as point solutions, without much consideration as to how they integrate
into a whole. POET shows the scope of information that each tool requires
access to, and thereby shows the large amount of overlap of information between
tools. Each tool must not only be able to deal with the information that is
required as an output for that phase, but each tool must also be able to relate
that information to information at the level above (which provides the context)
and to the level below (for impact analysis). In this way a coherent approach
to selecting an integrated transformation tool portfolio is required.
POET provides the framework to enable Enterprises to take a
coherent and holistic view of the Tools used for Enterprise Transformation.
This may in fact, require the sub-optimisation of some or
all of the tools!
A logical view may be to use one tool for the Enterprise
Architecture Model and one Tool for the Enterprise Engineering Model. However,
since there is (by definition) more detail in the Engineering Model it might be
more logical to use multiple Tools at that level. It would also be logical to
think that those tools may be aligned more around the Disciplines and Roles
used rather than levels themselves.
While these lines may be moved for individual Enterprises
based on their needs and maturity, it should be noted that what is of more
importance is how the interfaces between these tools work as shown by the red
boxes. It is critically important that all the tools used for Enterprise
Transformation work together cohesively as a whole. No information is an island,
and although different roles may concentrate on working on one particular type
of information and use one particular tool, what is crucially important
(because Context is King™) is that people can see their information of
interest, in the context of other information.