How was Training?


Very comprehensive. Good coverage of topics. - Senior Architect - Applications, RMIT University, Australia, Aug 2010

Recommend PEAF?


Yes - PEAF lives up to its pragmatic goals without sacrificing value. - Enterprise Architect, UnitedHealth Group, USA, May 2010

  Introduction   Context   Methods   Artefacts   Culture   Environment   Adoption  




<< Previous <<

>> Next >>

PEAF effectively defines a Logical Model for the Enterprise Architecture domain. As such, PEAF should be used in the same way as any other Logical Model - a means to organise and orchestrate all the physical parts of the EA capability in an Enterprise together, into a coherent whole, whose focus is the end to end efficiency and effectiveness of the whole domain, not the efficiency or effectiveness of only its parts.

A Logical Model does not tell people exactly what to do, when, how and with what. If it did, it would not be an Logical Model and it would not fulfil its purpose.

Think Strategically. Act Tactically.

"How should I use PEAF?" is a common and perfectly reasonable question. However, it can be closely followed by ...

"It's too big - I can't tell someone we are going to improve the Methods, Artefacts, Culture and Environment of everyone and everything related to Transformation - it's just too big! No one is going to go for that!"

Which incorrectly implies:

We are advocating that there should be a massive project to improve the whole of the EA domain in one fell swoop.

Whilst PEAF encompasses the entire EA domain (Strategising, Roadmapping and Project Governance) this does not mean that an Enterprise should embark on improving the entire EA domain in one fell swoop.

Tactical and piecemeal changes to parts of the EA domain is a way to improve things (evolution no revolution) but these changes need to be made in the context of a wider plan and an understanding of how the part that is being changed, relates to the larger and more important whole.

Most Enterprises do make some (not enough) changes to How they "do" EA. Maybe they create some principles. Maybe they buy an EA modelling Tool. There is nothing wrong with that per se. What is wrong, and where many problems come from, is that they do so without a clear understanding of how the part they are changing is related to other parts of the EA domain. It is akin to travelling without any clear idea of where your ultimate destination.

PEAF allows Enterprises to think strategically so they can then act tactically with respect to increasing the maturity of the Enterprise Architecture domain instead of just acting tactically.

But the people in Enterprises can only think strategically if they are given time to think. If an Enterprise constantly drives its people to act and discourages them from doing anything else (because if you are not acting then you are not working) then they will be acting tactically without thinking strategically. This means that you will almost certainly win the battle. It also means that you will almost certainly lose the war.


What Logical Model for Enterprise Architecture does your Enterprise use?

If it doesn't use one, do you think it would be beneficial if it did?

Does your Enterprise think strategically and act tactically or just act tactically (with respect to improving How it "does" EA)?

What initiatives has your Enterprise undertaken to improve How EA is effected?

Where those initiatives aimed at optimising one part of the EA domain (at the expense of the whole) or at optimising the whole of the EA domain (at the possible expense of the parts).

What did your Enterprise use to ensure that those initiatives fitted into a holistic and coherent strategy?

If it didn't use anything, do you think it would be beneficial if it did?



2008-2016 Pragmatic EA Ltd