How was Training?

more

Very positive. It made me think about what EA really is and the part I can play as a business systems analyst representing the Enterprise Architecture Office. - Business Systems Analyst, Board of Equalization, USA, Jan 2015

Recommend PEAF?

more

Yes - It's simply pragmatic, accessible and encapsulates the key tenets of EA. - Lead IT Architect, Freshfields Bruckhaus Deringer, UK, Jun 2012

  Introduction   Context   Direction   Operation   Transformation   Support   Adoption  

Desktop

Mobile




 

<< Previous <<

>> Next >>

 

A

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, which formulates the Project Portfolio (aka a Transformational Roadmap) and the Business and Technical Capabilities (aka Structural roadmap), that we refer to as doing Enterprise Architecture.

Let's focus on the EA domain and consider the information that describes how it is done...

B

The box at the bottom in grey, represents the actual EA work taking place, in terms of MACE:

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

Moving up, in the blue, green, yellow and orange boxes, we show that this real world can be represented in models at varying levels of abstraction (idealisation/realisation) - an Operational model, a Physical model, a Logical model, and a Conceptual model.

Note that The Operational model should not be confused with an Operating model.

In pink, we show a model which represents the context in which EA is happening.

So let's now consider, for a typical Enterprise, which of these models (that describe how EA is performed) exist.

C

The Operational model (the blue box) is not really applicable as it merely represents operational details such as people names, but shown here for completeness.

The Physical model (the green) box 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 (the yellow box) also may exist but more often does not.

The Conceptual model (the orange box) will almost certainly not exist and in most cases has not even been considered.

D

If we identify a need to increase the Effectiveness, Efficiency, Agility and Durability of doing EA, then 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.

E

In order to do that we need to create a Plan to describe exactly how we will effect that change. However, just wading in and changing what people are doing is not a good approach. So we need to decide on an Intermediate State physical model first. However, this physical model of what we require should not be created in a vacuum, it has to be created based on what currently exists.

F

So first we need to create a Physical model (in green) of how EA is currently performed. This may require us to create one from scratch, updating an existing one, or doing nothing if a correct and up to date one already exists.

G

Once created, this will then allow us to create our Intermediate state Physical model (in green) of how we want EA to be done. However, once again, we should not create our Physical model in a vacuum, only based on what currently exists.

H

The Intermediate state Physical model should be created in the context of our long term Target state Logical model (in yellow) of how EA should be undertaken.

This logical model is Very Important because it is here where the fundamentals of how to do EA are defined.

Unless these things are put in place, we are likely to spend time tinkering in the weeds with how we do EA (concentrating on the 80% that only provides 20% of the benefit), while missing fundamentally important things (concentrating on the 20% that will provide 80% of the benefit).

I

In addition, this Logical model should exist in the context of a Conceptual model (in orange) of how the whole of Transformation should be undertaken.

This conceptual model is Mega Important because it constitutes an Operating Model for the whole of the Enterprise Transformation domain

This ensures that all the parts (including but not limited to EA) work together in a cohesive way, thereby making sure we are always optimising the whole domain (which make require us to de-optimise the parts) rather than optimising the parts, which will almost certainly inadvertently de-optimise the whole.

J

Having created a Physical model of how we want EA to be performed (based on a logical model of how EA should be performed, based on an Operating model for Enterprise Transformation) we can then create the plan to physically change how EA is performed in the real world, which allows us to deploy the physical changes required, which moves us closer to our Target state.

So, what do you use for your Mega Important Conceptual model?

K

The conceptual model is effectively the Operating model for Enterprise Transformation.

It is well known how crucially important an Operating model is.

If you already have an Operating 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 Operating model for Enterprise Transformation (XOET)

So, what do you use for your Very Important Logical model?

L

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)

 



 

2008-2016 Pragmatic EA Ltd