The Pragmatic Family of Frameworks


◄◄◄ Previous Page         


          Next Page ►►►

Why Were They Created?

Because I care. Because I care about Enterprises. Because I care about the people who Direct, Operate, Transform and Support Enterprises. Because I am angry about how much time is wasted. Because I am angry about how much money is wasted. From the Afghani to the Zloty, I guarantee you are wasting it. Big time!

This work was inspired by all those who seek to make the world a better place rather than those that seek to own it.

When Were They Created?

PEAF was initially launched in November 2008 and POET in 2014.

Where Did They Come From?

All Pragmatic Ontologies and Frameworks were created from observing failure. That is:

¨      Seeing why people fail

¨      What problems they encounter

¨      Providing things to reduce the risk of others failing in the same way

¨      Providing things to alleviate the problems people have.

Around 2002 I began to be interested in something called “Enterprise Architecture”. The term started to appear more in publications and people started to talk about it more - although from listening to them there never seemed to be a concrete definition of what it actually was that everyone agreed with (some say that’s still the case today!). Using logic and common sense I could surmise that it was not Project level Architecture (because that already had a name - Solution Architecture) and therefore it must be something at a “higher level” - not just bigger. Something related to:

¨      What goes on before projects execute and before Solution Architects start working on those projects.

¨      Enterprise Centric, or more specifically Enterprise Transformation Centric, rather than Project Centric and/or IT Centric.

At that time it all seemed to be a bit of a black art (some say it still is!) and so, being an Architect and not wanting to reinvent the wheel (others call it being lazy!), I surmised that there must be something out there (a bit like Prince or ITIL or MSP for example) - a framework - that might help people to “do” EA by:

¨      Helping people understand what EA was.

¨      Helping people increase the maturity in how an Enterprise “does” EA.

So, I consulted the mighty Google (sorry Oracle!). Google told me about something called Zachman and something called TOGAF. And so I went off to investigate further.

From what I could tell, Zachman’s message seemed to resonate well with me in terms of general thinking I had built up over the preceding 20 years, namely:

¨      You can’t change what you can’t see - hence the need to model things - in a structured way.

¨      There must be Phases involved in Transformation to get from Strategic intent at the top down to real physically deployed things at the bottom.

These basic messages haven’t changed and are as valid today as they always were - although the important distinction between Enterprise Architecture and Enterprise Engineering that Pragmatic makes today was not (and still is not) recognised in Zachman (despite my attempts to do so). But, whilst these fundamental things (modelling and phases/levels) were a good start, they were much too high level to provide any practical help in using them (which is what a framework is supposed to do) and so I invested more time looking into the much more detailed TOGAF.

As I looked into TOGAF, the first thing that struck me was “Where the hell do I start?”. The material was immense, complex, confusing, very dry, hard to consume and offered no guidance about how to adopt it. So, assuming it was my ignorance that was the problem I booked myself on a TOGAF course. Within the first 2 hours of the first day it became clear that it was centred around Project level IT centric Architecture.

Nothing wrong with Project level IT centric Architecture, but not Enterprise Architecture.

Fantastic for those Enterprises that had still not figured out that the complexity of the IT landscape had grown to such a level that using Architecture as a discipline on IT Projects (Solution Architecture) was almost mandatory (unless you wanted to waste a shed load of money and deliver a shed load of bad IT to customers), but not Enterprise Architecture.

Great for those Enterprise that wanted to formalise their Solution Architecture discipline, but not Enterprise Architecture.

Great for those Enterprises that wanted to continue to treat “The Business” as a second class citizen to “IT”, but not Enterprise Architecture.

At least not the Enterprise Architecture that logic and common sense dictated to me.

Anyway, I got through the course, passed the exams and became TOGAF Certified. Over the next few years I worked at various organisations and my TOGAF certification served me well in terms of getting me job interviews and most of the subsequent contracts. Having got a contract (because I was TOGAF certified) I then endeavoured to first discover how much and what parts of TOGAF were being used. The conversation (over many days, sometimes weeks) usually went something like this:

K: “Hi Allen, I’m new here. I’ve been told that you use TOGAF, can you tell me what parts you are using and which you aren’t?”

A: “Hi Kevin, Errrmm, Yeah sure - you need to talk to Steve, he’s the one that did the training.”

<time passes….>

K: “Hi Steve, I’m new here. I’ve been told that you use TOGAF, can you tell me what parts you are using and which you aren’t?”

S: “Hi Kevin, Errrmm, why are you asking me?”

K: “Allen told me you did the training and you would know.”

S: “Err yeah, but I was only one of the twenty people who did it, I wasn’t the main person. Listen - I’m a bit busy on this CRM project at the moment, can you go and ask James about it - I think he was the main guy.”

<time passes….>

K: “Hi James, I’m new here. I’ve been told that you use TOGAF, can you tell me what parts you are using and which you aren’t?”

J: “Hi Kevin, Errrmm, why are you asking me?”

K: “Steve told me you did the training and you were the main guy so you would know.”

J: “Err yeah, but I was moved off that onto this ESB project. Listen - I’m a bit busy at the moment, Dave took over that TOGAF thing - go talk to Dave.”

<time passes….>

K: “Hi Dave, I’m new here. I’ve been told that you use TOGAF, can you tell me what parts you are using and which you aren’t?”

D: “Hi Kevin, Errrmm - why are you asking me?”

K: “James told me you did the training and you’re now the guy in charge of TOGAF adoption.”

D: “Err No! That’s Chris, you need to talk to Chris”

<time passes….>

K: “Hi Chris, I’m new here. I’ve been told that you use TOGAF, can you tell me what parts you are using and which you aren’t?”

C: “Hi Kevin, Errrmm, why are you asking me?”

K: “James told me Dave did the training and he was the guy in charge of TOGAF adoption, but that Dave says it wasn’t him, it was you”

C: “Err Yeah - well I went on the course, but to be honest we never did anything about if after that, you should go talk to Allen, he knows what’s going on”

In every case, after being passed from pillar to post, it always transpired that no one was actually using TOGAF at all.

So, I began to build up my own intellectual capital (documents, checklists, presentations, spreadsheets, ideas, concepts, processes, products, etc) so that I could bring them to bear as a set of quick start artefacts for subsequent contracts.

During 2008 it suddenly dawned on me that all this intellectual capital that I had built up, actually constituted what I thought an EA framework should contain. So, in addition to cleaning up and structuring the material so others could adopt and use it easily, I had to choose a name. So, I thought, what one word would sum up my approach? A core of fundamental things - the 20% that would give 80% of the benefit - that would reduce or remove 20% of the risks that cause 80% of the failures. Cutting through all the smoke and mirrors and Cutting EA to the Bone. And so the name Pragmatic chose me.

How Were They Created?

POET and PEAF have taken more than 10,000 hours to produce in terms of physical work, born from approximately 150,000 hours of thinking. The graphics were not just drawn - like most good things they evolved - and while many of them look quite simple, it took an awful lot of work and pain to get to those simple graphics. To an outside observer, those diagrams could appear as if someone just sat down and drew them but each one has had many versions as it has evolved, coalesced, fragmented, reconstituted, gone down the wrong track, fragmented, coalesced again and then finally thrown away, only to be resurrected when a light bulb went on somewhere in the deepest darkest recesses of my feeble brain.

Elegance and simplicity takes a lot of hard work to achieve but, anything Pragmatic must be so.

“Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.”

- Blaise Pascal (“Lettres Provinciales”, 1657)

Which loosely translates to

“If I Had More Time, I Would Have Written a Shorter Letter”

In fact, the amount of things and work I have thrown away greatly outweighs what now exists.

I believe that POET and PEAF have achieved elegance and simplicity to some degree but, of course, “we don’t live in a perfect world” (as so many Managers I have worked for in the past have reminded me on so many occasions) and there is always more work to do. POET and PEAF will evolve, as everything must do, but for now, it is good enough.

With the benefit of time to think of a suitable response to those Managers, my response now would be:

“We don’t live in a perfect world?

I know - Believe me I know!

If we did, we wouldn’t be having this conversation ;-)”

What Was Used to Create Them?

Basically, common sense. It has always amazed me, how many things in business (and in life) do not seem to adhere to any common sense at all, which probably explains why a lot of things that are created to help people improve or mature something, contain a lot of common sense. In addition I have a brain split into two parts (Architecture and Engineering) that work together but also conflict a lot of the time. But it is from this conflict that progress lies.


Taking a MACE approach to detailing what was used to create Pragmatics Frameworks…


Common Sense






Air, Water, Nespresso, Earl Grey, Toast, Ham Eggs & Chips, Bombay Sapphire (Tonic), Johnny Walker Black Label (Coke Zero),  Whiskers, Paper, Ink, Blood, Sweat, Tears, Srees..


PF2 Book, POET Book, PEAF Book, PragmaticEA Website












David Bowie, Pet Shop Boys, Dean Martin, Chris Rea.


25 Buttermere, Braintree, Essex, CM77 7UY, UK.


Biological / Chemical

Kevin - Generally all of him, but mostly his brain, eyes and hands. His stomach, colon and bladder put in an appearance occasionally, with his posterior providing a supporting role :-)

Murphy the cat.


Desk, Chair, Whiteboard (Pens and Eraser).


Challenge Fan Heater, Creative GigaWorks T40 Series II 2.0 PC Speakers



Dell Latitude E6520 (Intel i7-2760QM @ 2.4GHz, 8GB RAM), 3 * 24in 1920x1200 LED Monitors, HP Officejet Pro X576, Samsung Galaxy Note III.


MS Windows 7, MS Visio, MS Word, MS Excel, MS PowerPoint, MS VBA, Paint.NET, Faststone Photo Resizer, MozyBackup, PF2


Questions to ponder...

Do you think that observing failure is a good way to figure out how to improve things?

What failures have you witnessed in the past?

What does that tell you about how to improve it?

◄◄◄ Previous Page          

          Next Page ►►►


© 2008-2019 Pragmatic EA Ltd