All |
Reference Books |
Focus Books |
Study Guides |
Definitions |
Intro |
PF2 |
POET |
PEAF |
Transformation
Debt |
What Is
EA |
EA
Tools |
ETMC |
Culture |
Foundation
Part A |
Foundation
Part B |
Certified
Part A |
Certified
Part B |
BOOK - Enterprise Transformation - A Pragmatic Approach Using POET

Here we see an overview of how POET and PEAF should be used
to mature the Transformation domain.
While the approach described here is changing the
Transformation domain (or more specifically the EA part of the Transformation
domain) the process described actually is the same for changing any domain,
i.e. create a Physical intermediate state model based on physical current
model, and logical and conceptual Target models. Then use that Physical
intermediate model to determine a plan to change the MACE that exists. This
fundamental approach is detailed in more detail in the Methods section.
So let’s walk through what’s happening with respect to
maturing the EA domain and the part that POET and PEAF play in that.
1
|
Here we see all the phases of Transformation, from
Strategy formulation on the left, to Transitioning into live operation on the
right.
Everything to the right of the solid black line is the
work that goes on in projects, that we refer to as doing Enterprise
Engineering.
Everything to the left of the solid black line is all the
work that happens before projects execute, that we refer to as doing
Enterprise Architecture - formulating the Project Portfolio (aka a Transformational
Roadmap) and the Target and Intermediate Business and Technical Capabilities
(aka Structural roadmap)
Let’s focus on the EA domain, consider HOW that work is
physically done, and how models of that work can be represented at different
levels of abstraction.
|
2
|
The actual EA work being done (the box at the bottom in
grey) can be represented in models at different levels of abstraction
(Idealisation/Realisation): Physical model (green), Logical model (yellow),
and Conceptual model (orange). In each model we describe information about:
·
The Methods being used to do EA (e.g. processes)
·
The Artefacts being produced and consumed by EA (e.g. project
plans, designs, requirements, etc)
·
The Culture used to do EA (e.g. the people doing the work and
the values and ethics that guide them).
·
The Environment used to do EA (e.g. modelling tools, word
processors, etc).
So let’s now consider, for a typical Enterprise, which of
these models (that describe how EA is performed) exist.
The Physical model (green) may exist in some form, possibly
in terms of RACI matrices or process diagrams, but for most Enterprises this
information is in the heads of the people performing the tasks and is not
explicitly modelled.
The Logical model (yellow) may also exist but more often
does not.
The Conceptual model (orange) will almost certainly not
exist and in most Enterprises has not even been considered.
|
3
|
If we identify a need to increase the Effectiveness,
Efficiency, Agility and Durability of HOW EA
is done, this means we need to adjust HOW we
currently do EA. From HOW we currently do
it, to a more mature way of doing EA. This increase in maturity is likely to
not be a one shot deal, but instead we will have a long term target, with 1
or more intermediate states that we wish to progress through over time. In
order to effect change we need a plan to describe exactly how we will effect
that change.
|
4
|
In order to create that plan to physically change, we need
to determine the physical model of what that intermediate state needs to be,
and this physical model needs to be created in the context of what currently
exists (the current state).
|
5
|
In addition, this Physical model needs to be created in
the context of a longer term (
VERY IMPORTANT ) logical model, which in turn needs to exist in
the context of a longer term and wider scope ( VERY IMPORTANT ) Conceptual model.
But why are these Logical and Conceptual models needed and
why are they so important?
Because they define the bigger picture both in terms of
time and scope.
¨
Without a Target Logical model, any changes will tend to ignore
future changes, meaning any changes may be good today, but compromise
tomorrow.
¨
Without a Target Conceptual model, any changes will tend to
ignore how this part fits into the wider domain, which means we could be
improving HOW EA is done but negatively
impacting other parts of the Transformation domain, thereby optimizing the
part (EA) but de-optimising the whole (Transformation).
|
6
|
So how should the ( VERY IMPORTANT ) Conceptual model be created?
If you already have a Conceptual model (Capability model)
for Enterprise Transformation of appropriate maturity, then you have no need
to create one or modify it.
If you do not have one of appropriate maturity, then you
need to create one (from best practice) for example, by taking POET and
performing the 5‑10% modifications required to make it your Capability model
for Enterprise Transformation (XOET), while at the same taking into account
any existing Conceptual model that exists.
|
7
|
So how should the ( VERY IMPORTANT ) Logical model be created?
If you already have a Logical model, of appropriate
maturity for EA, then you have no need to create one or modify it.
If you do not have a Logical model, of appropriate
maturity for EA, then you have to create one (from best practice) for
example, by taking PEAF and performing the 5‑10% modifications required
to make it your Logical model for Enterprise Architecture (XEAF) , while at
the same taking into account any existing Logical model that exists.
|
Don’t forget, while we are explaining how POET and PEAF
should be used, this overall method is exactly the same irrespective of the
domain you want to change.
|
Questions to ponder... |
Does this approach look familiar? | What approach does your Enterprise take when maturing parts of it? |
|