◄◄◄ 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. It doesn’t matter if your currency is the Afghani, Baht, Balboa, Birr, Bolivar, Boliviano, Cedi, Colon, Dalasi, Denar, Dinar, Dirham, Dobra, Dollar, Dong, Dram, Escudo, Euro, Forint, Franc, Francs, Gourde, Guarani, Guilder, Hryvnia, Kina, Kip, Koruna, Krona, Krone, Kuna, Kwacha, Kwanza, Kyat, Lari, Lats, Lek, Lempira, Leone, Leu, Lev, Lilangeni, Lira, Litas, Loti, Manat, Marka, Metical, Naira, Nakfa, Ngultrum, Oro, Ouguiya, Pa'anga, Pataca, Peso, Pound, Pula, Quetzal, Rand, Real, Renminbi, Rial, Riel, Ringgit, Riyal, Ruble, Rufiyaa, Rupee, Rupiah, Shekel, Shilling, Sol, Som, Somoni, Sterling, Sucre, Sum, Taka, Tala, Tenge, Tugrik, Vatu, Won, Yen or 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.

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:

“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?”

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

<time passes….>

“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?”

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

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

“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….>

“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?”

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

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

“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….>

“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?”

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

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

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

<time passes….>

“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?”

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

“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”

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

When Were They Created?

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

What Was Used to Create Them?











Common Sense






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



Air, Water, Nespresso, Earl Grey, Toast, Ham Eggs & Chips, Bombay Sapphire, Johnny Walker Black Label, Baileys, Whiskers, Paper, Ink, Blood, Sweat, Tears.


PF2 Book, POET Book, PEAF Book, PragmaticEA Website

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 ;-)”

Who Created Them?

A simple man.

My career began at the age of 16 in 1978 as an Electrical and Electronic Apprentice with Marconi Radar Systems (Blackbird Road, Leicester, UK) At that time I was really into electronics and had been playing with little circuits for a few years. It was really exciting. I spent my time between college and “The Factory” where I got the chance to work in many different departments. It was really exciting. Around 1980 I ended up in a Department (New Parks, Leicester UK) called TEPIGEN (TElevision PIcture GENerator) who had built the visual system for a ship simulator. Six million Pounds of custom built hardware (that had less processing power than the CPU in the phone that’s in your pocket) consisting mainly of four racks of “Picture Processors” (Motorola 68000s) driven by a PDP11. It was really exciting. The output was on three channels each delivering 40 degrees field of view which drove three large Barco projectors. Interestingly at one point there were black speckles that kept appearing on the displays, moving about in random patterns and appearing and disappearing in the same apparently random fashion. After months of software and hardware investigation the problem was identified. It was a test Radar across the apron from where our Portacabins where located that was spraying us periodically with microwaves! It was really exciting.

I began my time there hand entering the data which described the terrain and buildings and which fed the picture processors, and wrote my first program in DEC BASIC. Over the next four years or so my programming skills grew, and I moved from BASIC to FORTRAN and then to PASCAL. It was really exciting. The ship simulator turned into a flight simulator which meant it was the biggest video game in the world. It was really exciting. So much so that I would work late into the night (sometimes 48 hours at a stretch) and go into work on Saturdays or Sundays. Right from the beginning it wasn’t so much the code I wrote that I got excited about it was more HOW I wrote the code that interested me. I would often spend hours writing a program and finally get it working, only to tear it to pieces and rewrite it in a new and elegant way, often with more features, less code and more opportunity to reuse things later. It was really exciting. Even at that time I spent more time throwing things away than I spent creating things. I believe this is where progress comes from. Sounds totally counter-intuitive I know, but most things of value are counter-intuitive!

Around 1986 the plug was pulled on TEPIGEN and I moved to another department (Fleet, Hampshire, UK) who produced a system called TELEVIEW (an improvement on Teletext and a forerunner of “The Web”) for Singapore’s Telecom Company (SingTel). I had moved on to C as a programming language. The most elegant and powerful language I have ever used. It took me a while to understand it but after reading the perfect “The C Programming Language” (Kernighan and Ritchie) the penny dropped. It was really exciting.

A brief spell at SD Scicon (1989-1991) was followed by three years working for Deutsche Bank (Singapore) where I found the best food in the world and where my architectural tendencies came to the fore. It was really exciting. Returning in 1994 I spent six years working for Eurobase Systems (Chelmsford, UK) doing Application Architecture and creating Architectural and programming frameworks.

From 2000 to 2011 I spent my time working for various Enterprises as a contractor. While interesting, it wasn’t very exciting, but all the time, whatever domain I worked in I was always interested in improving it. Each time this met a limit and the limit was always as a consequence of things being done less than effectively and less than efficiently in the preceding step. Hence my roles moved from Application Architecture, Data Architecture and Technology Architecture into Technical Architecture (a bit of a misnomer!) then Solution Architecture then Enterprise Architecture and finally the entire Transformation domain.

Since 2011 I have devoted my time to Pragmatic. It is really exciting.

Whilst I have never been an academic person, and never went to university (I have always preferred to “go out and do stuff”) I have recognised over the last year that Psychology plays such a vital role in Enterprise Transformation (for good or bad) and so in February 2014 I began a BSc (Honours) Psychology degree with The Open University. It is really exciting.


My MBTI is INTJ with a hallmark of Vision and categorised as Independent, Individualistic and Visionary.

INTJs tend to be independent-minded, theoretical, and original. They have great drive for their own ideas and purposes. They are sceptical, critical, determined, and sometimes stubborn. In areas of expertise, they will develop systems to organize and carry through a project with or without help.

INTJs are typically innovators in their fields. They trust their inner vision of how things fit together and relentlessly move their ideas to action. They would rather spend time on what they believe is important than on what’s popular with others.

INTJs are independent and individualistic, and others may see them as stubborn at times. They move ahead with or without the support of others, and they have a single-minded concentration.

They like using logic to solve complex, challenging problems. Routine, everyday tasks bore them. They analyse and attempt to fit pieces together into a coherent whole.

Although INTJs are usually organized and follow through, they may sometimes ignore details that do not fit with their vision of the future. If these details are important, their ideas may not work as well as they would like.

INTJs are likely to be most satisfied in a work environment that values their insights and ideas and lets them work independently. People can count on them for their vision and innovative solutions to problems in their field.

Some famous INTJ’s:

¨      Isaac Newton (Physicist) - "I can calculate the motion of heavenly bodies, but not the madness of people."

¨      Karl Marx - (Philosopher) - "Philosophers have hitherto only interpreted the world in various ways; the point is to change it."

¨      Augustus (Emperor of Rome) - "I found Rome brick and left it marble."

¨      Isaac Asimov (Science fiction writer and science writer) - "Those people who think they know everything are a great annoyance to those of us who do."

¨      Martin Luther (Theologian and Protestant reformer) - "I [am] slave to the authority of no one."

¨      Nikola Tesla (Inventor) - "My ideas have revolutionized the industries of the United States."

¨      Stephen Hawking (Physicist) - "My goal is simple. It is a complete understanding of the universe."


My DISC Profile is 7414 and categorised as Result-Oriented.

Result-Oriented people display self-confidence, which some may interpret as arrogance. They actively seek opportunities that test and develop their abilities to accomplish results. Result-Oriented persons like difficult tasks, competitive situations, unique assignments, and "important" positions. They undertake responsibilities with an air of self-importance and display self-satisfaction once they have finished.

Result-Oriented people tend to avoid constraining factors such as direct controls, time-consuming details, and routine work. Because they are forceful and direct, they may have difficulties with others. Result-Oriented people prize their independence and may become restless where involved with group activities or committee work. Although Result-Oriented people generally prefer to work alone, they may persuade others to support their efforts especially when completing routine activities.

Result-Oriented people are quick-thinkers, and they are impatient and fault-finding with those who are not They evaluate others on their ability to get results. Result­Oriented people are determined and persistent even in the face of antagonism. They take command of the situation when necessary, whether or not they are in charge. In their uncompromising drive for results, they may appear blunt and uncaring.

So putting MBTI and DISC together it says that I am a Result-Oriented Independent Individualistic Visionary. Well that about sums me up to a tee. Sounds very grand, but of course, there are always downsides. I am also an Arrogant, Inflexible, Argumentative, Intolerant, Impatient, Critical & Stubborn, Pessimistic Optimist!

Different people have different profiles, and different profiles fit into different roles in different ways. We all kind of know this but do we ever take it into account?


What are the MBTI and DISC profiles of the people in your Enterprise?

Do they all suit their roles?

Have you ever found someone to be a “difficult person” or a “loose cannon”?

If so, did their MBTI/DISC profile have any bearing as to how they were treated?



◄◄◄ Previous Page          

          Next Page ►►►


© 2008-2018 Pragmatic EA Ltd