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.