Like Web 2.0, the innovation involved in Enterprise Architecture (EA) is more about improving how we use what we already have than inventing something entirely new. While some very specific aspects of those improvements require highly specialized knowledge, most of them are common sense after all the mystery is stripped away. The trick to keeping something as potentially complex as Enterprise Architecture from becoming “rocket surgery” is to drop the confusing parts and explain the concept plainly so people can recognize the benefit. Because there are many different types of organizations with a variety of roles, the more tools we have to communicate the value and core processes of Enterprise Architecture the better. The Pragmatic Enterprise Architecture Framework (PEAF) is one useful tool that can enable you to do just that.
PEAF vs. TOGAF: How They Compare
Besides the obvious exception of highly-specialized vertical frameworks, one key to a good EA framework such as Enterprise Architect by Sparx Systems is adaptability through flexibility. TOGAF takes the approach of tackling many levels and details with the expectation that those that don’t fit a given enterprise should be dropped, replaced or modified.
It is often easiest to understand something new by comparing it with something familiar. Comparing any EA framework to TOGAF makes the most sense in this discussion because:
- TOGAF is probably the most widely recognized EA framework.
- I am more familiar with TOGAF than other frameworks.
There often is a perceived preference when one product is compared with another, but that is not the intention in this comparison. The purpose of comparing PEAF with TOGAF is to simplify the description of PEAF rather than to imply a superiority of one over the other.
PEAF as a Rocket Scalpel
The introduction to each of the PEAF process documents states that PEAF achieves its framework goals by “cutting EA to the bone.” A frequent (and easy) comparison to illustrate this claim is with TOGAF 9. TOGAF has seven parts, the core part being the Architecture Development Method (ADM), which contains 8-10 phases (depending on how you do or do not include the Preliminary and Requirements Management aspects). PEAF, on the other hand, consists of three processes and four “products.” PEAF aims for the sweet spot of being not so lightweight as to be incomplete and not so large as to be difficult or intimidating.
EAF achieves part of its streamlining by using plain, direct language. For example, the Agile Manifesto (not an overly wordy document itself) includes “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” The PEAF Foundation Vision product covers the principle of agility very accurately with only four words: “Change faster with less.”
The Three Processes of PEAF: Prepare, Implement and Operate
What could be simpler than the three PEAF processes: Prepare, Implement and Operate? With both PEAF and TOGAF, a successful Enterprise Architecture requires dedicated Enterprise Architects to communicate and drive the value proposition that EA. In the case of PEAF, credit must be given to staying on message (“Cutting EA to the Bone”).
The Prepare process may be where PEAF excels the most, as the outcomes are very similar to the TOGAF ADM Preliminary and part of the Architectural Vision phases. It essentially calls for gaining buy-in from the business folks and then determining the starting point and direction for the Enterprise Architecture.
Whereas in the Prepare process agreement is reached to do something about EA, the Implement process is where the infrastructure is built to do something about EA. The process is very direct, and following it will also lead to an understanding of how PEAF manages to reduce the number of processes so drastically at the top level of the framework (i.e. sub-processes): Six in the case of the Implement process, five more in the following Operate process. The use of sub-processes supports that all-important first initial of the PEAF acronym: Pragmatic. These pieces would fall apart if left at the high-level, and the sub-processes are just the thing to move many enterprises from wanting to do EA to being ready to do EA.
Equally pragmatic is the straight-to-the-point, acknowledge-the-elephants-in-the-room language, such as this bold, red text in a highlighted box about communication and education:
“If it is not done, or done badly, your EA initiative WILL FAIL.“
Forewarned is forearmed.
The Operate process is repeatedly referred to as “doing it.” For PEAF, that means doing Enterprise Architecture — and only Enterprise Architecture. There are no detailed models of how to choose an ETL or recommendations of languages to create models of business processes. Instead, the Operate processes focus on what are common architecture activities from an Enterprise viewpoint.
The PEAF processes are designed to streamline adoption and support by minimizing complexity and using plain language to make the concepts immediately understandable on the first reading by any audience. Another nice tool to ease the adoption process is the inclusion of high-level project plans for each stage of the process. Adding familiar tools to clear language should help drop the barriers of resistance most Enterprise Architects face on a regular basis.
The Four PEAF Products
Rather than speculate why PEAF’s collection of data, educational text, and templates are labeled “products,” I will explain how the Foundation, Culture, Model and Governance products relate to the three PEAF processes.
- The PEAF Foundation product contains the tools to prepare an organization for EA. It tracks very closely to the concept of the Preliminary phase of the TOGAF process. Keeping with the theme of PEAF, it is split into four easily-digestible documents ranging from 9 to 21 pages in length. The short lengths make it easy to take the material as is and present one document per meeting.
- The Culture product stands out in comparison to other frameworks because of its head-on approach to the people issues that are part of establishing, evolving and maintaining a viable enterprise architecture. This is something that everyone who works in a business larger than one person should read and learn from.
- The Model product is described this way in the literature: “The main artifact of EA are the models which allow information to be gathered, viewed and analyzed.” While the spirit of that statement maps to how ADM is described for TOGAF, the model itself more resembles (though not a perfect simile) Part IV of TOGAF — the Content Framework — with bits of the TOGAF Part V thrown in. The Model product is another clear example where the goal of PEAF is to create a basis to build up rather than an all-encompassing framework to pick and choose from.
- The Governance product consists of principles meant for direct adoption into an existing governance process, and templates for creating your own governance process. It is a very straightforward guideline that contains solid governance concepts such as (paraphrased) follow the principles, business and IS must be proactive in IS planning, and (literally) decisions should be made to provide maximum benefit to the organization as a whole.
The products and the processes are interdependent to create the whole of the Pragmatic Enterprise Architecture Framework. An enterprise can attempt to use one without the other, but to do so requires either some adequate replacement (just as TOGAF suggests that any piece can be replaced by another piece with the same purpose) or an eventual collapse of the effort.
PEAF Not a Standalone Tool — That’s a Good Thing
Discussion threads seem to be longer when enterprise architects are commenting, and for good reason. There are many different approaches to EA and there is no single approach that will work for everyone. I first stumbling across PEAF in one of these lengthy threads and was impressed by the fact that everyone in the thread seemed to agree that PEAF either was or could be a useful tool in their work. And, while this thread was in a PEAF-focused forum, I was further impressed that no one seemed to think of it as a standalone solution. I find that impressive because if one were to find an EA framework that could stand entirely on its own, it would either be too complex to be practical or too contextually specific to be widely adoptable. But, then again, I’m no rocket surgeon.
