Reference Books

Focus Books

Study Guides

 

BOOK - Enterprise Architecture - A Pragmatic Approach Using PEAF

 




◄◄◄ Previous Page         

.  

          Next Page ►►►

To borrow from the introduction to The Restaurant at the End of the Universe (a book by Douglas Adams)…

There is a theory which states that if ever anyone discovers exactly what EA is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened!

This graphic shows three fundamental areas of Transformation; X, Y and Z.

Many people say it is not the labels that are important but the things that those labels represent. This is true to a certain extent, however, as POET tells us in the Introduction - language is key. Since we speak in labels all the time, it is vitally important to have a common understanding of what we mean when we use them, or at the very least, the ability to realise when we are not using the labels to mean the same thing and to act appropriately. This is especially true when a label (name or acronym) is used widely and extensively. Enterprise Architecture (EA) is definitely in that category.

There is (and has been for a long time) endless debate about what EA is. All those debates revolve around everyone putting forward their definition and then arguing about it. This approach has not taken us forward over the last 20 years, and is unlikely to do so over the next 20 years. Therefore, a more Pragmatic approach is needed. Instead of just stating what we believe EA to be, let’s consider the question from another direction.

Before we start let’s define a useful linguistic pattern, with reference to talking about eh architectgure of something. We could say that…

X Architecture, is the fundamentally important structure of the whole of X, set in the context of things outside of X that affect it, or are affected by it.

So that we can then easily say that

·         Application Architecture is the fundamentally important structure of the whole of an Application, set in the context of things outside of the Application, that affect it, or are affected by it.

·         Building Architecture is the fundamentally important structure of the whole of a Building, set in the context of things outside of a Building, that affect it, or are affected by it.

·         Aircraft Architecture is the fundamentally important structure of the whole of an Aircraft, set in the context of things outside of an Aircraft, that affect it, or are affected by it.

So, given this pattern we have labelled the diagram with 3 things. X, Y and Z.

·         A shows the fundamentally important structure of the whole of the Enterprise (including but not limited to IT), set in the context of things outside of the the Enterprise, that affects it, or are affected by it.

·         B shows the fundamentally important structure of the whole of the the IT of the Enterprise, set in the context of things outside of the IT of the Enterprise, that affects it, or are affected by it.

·         C shows the fundamentally important structure of the whole of a Project Solution, set in the context of things outside of a Project Solution, that affects it, or are affected by it.

From this, it is clear to Pragmatic that:

·         A is Enterprise Architecture (or EA for short)

·         B is Enterprise IT Architecture (or EITA for short) which is what the vast majority of people wrongly think EA is.

·         C is Solutions Architecture (or SA for short)

 

◄◄◄ Previous Page          

          Next Page ►►►

Questions to ponder...

If you cannot allocate the “EA” moniker to X, Y or Z, what box would you draw on the diagram to represent it?

What names do you use to refer to X, Y and Z?

Does everyone within your Enterprise agree? If not, what needs to be done?







© 2008-2018 Pragmatic EA Ltd