The artefacts defined in PEAF constitute the EA Meta-model and some of its content such as Principles.

There are many Meta-models that already exist (for the reasons defined above) and the lack of a Meta-model has never really been a reason why EA initiatives fail. For this reason, PEAF does not concentrate on defining a complete and detailed Meta-model (no point reinventing the wheel). However, PEAF does defines some important things that are usually missing and also exposes a higher level structure that people can use to understand how the detailed Meta-models they wish to use fit and relate.

Unfortunately, this is not an easy task because all the myriad Meta-models out there do not share any common backbone or structure (such as MACE and MAGMA). Even if you can figure out which parts of which Meta-models you wish to use, integrating them into a whole is also fraught with difficulty, again because there is no common meta-meta-structure (such as MACE and MAGMA).

This is exacerbated by Tool Vendors not providing facilities for the importation and separate management of different Meta-models from different sources along with the functionality to then present and manage and use them as a coherent whole.

This whole problem area is an area that Pragmatic is currently working on, driving Meta-model providers to structure their Meta-models around a Structural Ontology (MACE), a Transformation Ontology (MAGMA), all expressed at different levels of abstraction (Enterprise Context, Contextual, Conceptual, Logical, Physical, Operational) and driving Tool Vendors to think about how to then use them and allow people to use and manipulate them.

This will be a long and hard road (some say impossible), but one that will reap fantastic benefits for Enterprises globally. These 2 things (doing the impossible and fantastic rewards for customers) are the things that mean it’s something that Pragmatic has a passion to do.

In the meantime, Pragmatic will continue to map existing Meta-models to MACE and MAGMA to provide Enterprises with, at least, a starting point to understand how they relate and therefore how to adopt them.

Enterprise Strategy (aka Business Strategy)

A strategy is really just a high level plan and answers four basic questions:

1)    Where are we?

2)    Where do we want/need to go?

3)    Why do we want/need to go there?

4)    How will we get there?

I say “should” because many “Strategy” documents produced by Enterprises are not Strategy documents at all based on this definition. The only thing that makes a lot of them “Strategy” documents is because they have the word “Strategy” written on the front!

Although we use the term Enterprise Strategy (and urge others to do so) many Enterprises refer to this as Business Strategy. The term is in widespread use and there is nothing wrong with that per se. But as time has passed since it was first used, IT happened! More importantly people have begun (unfortunately) to refer to IT and “The Business” (as PEAF does - because you cannot ignore reality however wrong it may be from a purist’s perspective). The word Business has come to mean “everything in the Enterprise that is not IT”. This distinction is reinforced with terms such as Business Analysis and Business Analysts who work 99% of the time purely on the people and process issues of a solution, leaving the IT issues to someone else. So the term Business Strategy would seem to intimate that there is a separate IT Strategy (another slight misnomer as explained below). In addition the term Business is not very general to refer to the whole (do people refer to the Army as “The Business”?) and so we prefer to use the word Enterprise hence we use the term Enterprise Strategy instead of Business Strategy because it is, after all, the Strategy of the Enterprise - aka a high level plan of where we are, where we want to go to, why we want/need to go there and how we are going to get there.

Transformation Strategy (aka IT Strategy)

Although we use the term Transformation Strategy (and urge others to do so) many Enterprises refer to this as IT Strategy. This has happened because most of the Transformation happening in any Enterprise is IT Transformation. The difference between Transformation and IT has become blurred and confused.

¨      Plate A (Normal View) illustrates a (flawed) mental model that many people have. It takes the view that the Business Strategy is written and then thrown over a wall to those IT bods to figure out the IT strategy, and out of that there then comes projects - generally IT projects because most transformation with is all or mostly about changing IT. Effectively the proper Roadmapping phase is lost or, if not lost, limited to IT.

¨      Plate B (Pragmatic View) illustrates the Pragmatic view where the Business and IT strategies are formulated together. They are (should be) inextricably linked and must be formulated together as each feeds on the other. The IT Strategy is shown smaller because the Business Strategy is much bigger! The Business Strategy includes, Methods, Artefacts, Culture and part of Environment (IT - which is itself a sub domain of the larger Technology domain) while the IT Strategy only covers the IT part of the Technology Part of the Environment domain. Thus the Business Strategy and IT Strategy come together to make the Enterprise Strategy which then flows into the Transformation Strategy (the high level plan of how the required Enterprise Transformation will be undertaken)

It should be noted here that we are walking a fine line between the words I would like to use and the words I have to use because of history and the way people generally use them (rightly or wrongly).

¨