Pragmatic Enterprise Architecture Framework (PeaF)

image

Another EA framework player emerges in 2009, the Pragmatic Enterprise Architecture Framework (PeaF). I did skim and let me stress that I didn’t do a detailed analysis of the framework.

Below is the overview of the framework in their words:

PeaF has been formulated over a large number of years by understanding what works and what does not work in a pragmatic sense.

PeaF provides a quick start toolkit necessary to begin and sustain an Enterprise Architecture programme of work for organisations seeking to infuse and reap the benefits EA can bring.

What I did find interesting was this quote was in almost every document I opened on the site.

Where TOGAF is huge and Zachman is chiefly a taxonomy, PeaF cuts to the heart of what is needed to begin reaping the benefits of Enterprise Architecture. More than just a classification scheme or descriptive content, it provides a toolkit consisting of the vision, communication materials, maturity matrix, risks, plans, Metamodel, principles, processes and metrics required to hit the ground running.

I’m sure there isn’t any bitterness or hostility but it was strange to see those statements in every document. The statement I do believe is misleading and needs some tweaking. TOGAF is more of a process framework. TOGAF more than Zachman, I found references to TOGAF all over the documentation. TOGAF is very broad and can be implemented in many ways, this is intentional. That is why TOGAF is implemented in 80% of the Forbes Global Top 50 worldwide.

At first glance I am not sure how much value there is with this one. More analysis will be needed on my side. What I will say is that I didn’t find much process in the framework. That may or may not be intentional.

For me I did find a few issues:

  • For a pragmatic framework it isn’t immediately actionable. Meaning there are no accelerators or templates to aid in the implementation of the framework
  • Little process definition in the framework. See the Governance Process document (http://www.pragmaticea.com/docs/peaf-governance-process.pdf) as an example of this. No clear inputs and outputs, metrics, actors or descriptors where defined explicitly.
  • Assumptions were made that not all enterprises will share. Every enterprise architecture office has varying forces applied to it based on organizational, operational and cultural forces. As an example how PeaF does this, in the principles definition document (http://www.pragmaticea.com/docs/peaf-governance-principles.pdf) instead of creating a framework and process for defining your own principles they were defined for you.
  • Metric definition was fairly weak. While the questions in the Metrics Document (http://www.pragmaticea.com/docs/peaf-management-metrics.pdf) where useful for a subset of issues it doesn’t address the tough questions that will be asked about “why do we need EA?”
  • I didn’t see if there is a line up of tools that support PeaF?
  • It wasn’t obvious from the site on how the framework will grow.Is it a closed framework with no input from the community or is it open. Using the same frameworks referenced in PeaF are example of open and closed frameworks:
    • Open – Open Group’s TOGAF is completely open and is customer driven
    • Closed – Zachman framework isn’t adding any columns for anyone. This framework isn’t modified unless John Zachman wants it done.

Just like with anything, since this is a new framework the maturity is somewhat low. Without broad critique, enterprise implementation and best practices development caution and lowered expectations should be taken into account when approaching. There are some gems in the framework and does warrant further investigation.

If the guys at PeaF want to chat shoot me an e-mail I would love to get more information on the direction and roadmap of the framework.

What does everyone else think?

Share this post :      

Advertisements

0 thoughts on “Pragmatic Enterprise Architecture Framework (PeaF)”

  1. “Another EA framework player emerges in 2009, the Pragmatic Enterprise Architecture Framework (PeaF). I did skim and let me stress that I didn’t do a detailed analysis of the framework.
    What I did find interesting was this quote was in almost every document I opened on the site.
    Where TOGAF is huge and Zachman is chiefly a taxonomy, PeaF cuts to the heart of what is needed to begin reaping the benefits of Enterprise Architecture. More than just a classification scheme or descriptive content, it provides a toolkit consisting of the vision, communication materials, maturity matrix, risks, plans, Metamodel, principles, processes and metrics required to hit the ground running. “
    In order to provide some connectedness each document has the same introduction which gives a high level statement of what PeaF is and how it relates to Zachman and TOGAF. The intent was that no matter what document was read everyone who read at least one document would read this introduction.
    “I’m sure there isn’t any bitterness or hostility but it was strange to see those statements in every document.”
    Let me assure you there is definitely no bitterness or hostility. It’s just that almost always the first question people ask is – so how does PeaF relate to TOGAF and Zachman.
    “The statement I do believe is misleading and needs some tweaking. TOGAF is more of a process framework. TOGAF more than Zachman”
    I agree TOGAF has a process framework (ADM) which Zachman does not, but I also have the view that TOGAF is far to centred on Solution and Application Architecture rather than Enterprise Architecture. (I understand the next version will be much more EA focussed)
    “I found references to TOGAF all over the documentation.”
    There are references to TOGAF but I don’t think they are “all over the documentation.” TOGAF is mentioned in each document true but only in the overview which is meant to provide a consistent introduction no matter which document people read first.
    “TOGAF is very broad and can be implemented in many ways, this is intentional. That is why TOGAF is implemented in 80% of the Forbes Global Top 50 worldwide.”
    While I would agree TOGAF is broad and can be implemented in 80% of the top 50 I would also say that PeaF could also be implemented in these and other organisations. In fact the ease with which PeaF can be used to drive out the value EA brings in an organisation is much more than other frameworks which is mainly due to its pragmatic approach.
    “At first glance I am not sure how much value there is with this one. More analysis will be needed on my side. What I will say is that I didn’t find much process in the framework. That may or may not be intentional. “
    PeaF is intentionally light. It has everything required to kick of EA in any organisation very fast and nothing more. If I or others find things that are missing then I am quite open to hearing those and would update the framework.
    “For me I did find a few issues:
    For a pragmatic framework it isn’t immediately actionable. Meaning there are no accelerators or templates to aid in the implementation of the framework “
    PeaF is designed to be extremely actionable. The foundation section contains everything required to define where an organisation is wrt to EA where they want to go and the benefits and tasks required to move there in order to gain agreement to start work.
    The other sections contain all other toolkit documents from principles and governance to a Metamodel and communication slide sets, etc, etc.
    “Little process definition in the framework. See the Governance Process document (http://www.pragmaticea.com/docs/peaf-governance-process.pdf) as an example of this. No clear inputs and outputs, metrics, actors or descriptors where defined explicitly. “
    As I said above – if there is process documentation missing, let me know where because I don’t think anything is missing. I am always happy to hear of improvements that could be made. There are metrics in the Management section relating to the EA programme itself and there are metrics for all of the principles defined in the Governance section.
    “Assumptions were made that not all enterprises will share.”
    I’m not sure what assumptions you are referring to – can you let me know more on this point?
    “Every enterprise architecture office has varying forces applied to it based on organizational, operational and cultural forces. As an example how PeaF does this, in the principles definition document (http://www.pragmaticea.com/docs/peaf-governance-principles.pdf) instead of creating a framework and process for defining your own principles they were defined for you. “
    This is correct and intentional – This is a good example of PeaF being eminently actionable. It doesn’t just say you need some principles, it provides a set of standard principles that can be modified as needs. I would say that the ones defined there would apply to 90% of organisations.
    “Metric definition was fairly weak. While the questions in the Metrics Document (http://www.pragmaticea.com/docs/peaf-management-metrics.pdf) where useful for a subset of issues it doesn’t address the tough questions that will be asked about “why do we need EA?” “
    Again, not sure which metrics you think are missing but your question “why do we need EA?” is not answered by having a metric. That fundamental question is dealt with the Communication section where the Overview ppt explains what EA is, what it is not, and “why do we need EA?”
    “I didn’t see if there is a line up of tools that support PeaF? “
    This is correct. The tools section and document details a set of tools that are currently being evaluated – This is a slow process and is ongoing.
    Generally since PeaF is so concise any “EA Tool” could be used although of course we all have our opinions on which is the best or most appropriate. Indeed different organisations will have different priorities and weightings to be applied.
    It is anticipated that all the EA tool vendors will be come PeaF compliant since the starting Metamodel could be implemented in any of them.
    “It wasn’t obvious from the site on how the framework will grow. Is it a closed framework with no input from the community or is it open. Using the same frameworks referenced in PeaF are example of open and closed frameworks:
    Open – Open Group’s TOGAF is completely open and is customer driven.
    Closed – Zachman framework isn’t adding any columns for anyone. This framework isn’t modified unless John Zachman wants it done. “
    The work proprietary has very negative connotations. These connotations tend to be from an IT perspective and related to technology in that something which is non-proprietary or “open” is much better than something which is proprietary or “closed”.
    For something to be open there must be some council or group which is responsible for its evolution and protection. The reason this does not currently exist is more one of timing than a conscious decision.
    At the moment PeaF would be considered to be proprietary in that it is completely under the control of Pragmatic EA. However, we have always listened to and continue to act upon comments made regarding changes and improvements. In addition proprietary intimates that you cannot change something. For those that have become Certified, the full source of PeaF is available for them to change as they require.
    In the future, it is intended that a council of members would contribute discuss and evolve the framework, under a set of guiding principles one of which would be to make sure that PeaF stays true to its fundamental raison d’etre of being small, concise, pragmatic and free of bloat and sound bites.
    This council of members will need time to come into existence, but this will happen as the framework grows in popularity.
    It is expected that the council will be composed of End-User Organisations, Government Agencies, Consultancies, Training Providers, Tool Vendors and Individuals. In fact anyone interested in its advancement will be able to have a voice.
    As Pragmatic EA and its Founder has always stated, we are always open to any suggestions and comments, favouring negative ones over positive ones, because it is the negative comments that will continue to evolve it.
    “Just like with anything, since this is a new framework the maturity is somewhat low. Without broad critique, enterprise implementation and best practices development caution and lowered expectations should be taken into account when approaching.”
    I’m not sure maturity is low – I accept take-up is low only because its has only just been released. I think if I could explain more and you could spend more time reviewing it you may change your mind. This statement also sounds pretty damning and I’m not sure the negativity it conveys is warranted.
    “There are some gems in the framework and does warrant further investigation. “
    Praise – thanks – much appreciated 😉
    Rather than you wading into the detail yourself it may be better for me to take you through the framework that way you can ask questions and we can discuss things as we go via webex? I am just concerned that your comments that will be read by probably millions are caused by me not having the opportunity to explain things a little more.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s