Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

PEAF Simplifies the Rocket Surgery of Enterprise Architecture : Page 2

Call it pragmatic, call it streamlined, but don't call the Pragmatic Enterprise Architecture Framework (PEAF) TOGAF lite.


advertisement

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.



Scott Nelson plays the roles of development manager, architect, project manager, and portal evangelist on any given day, and blogs lessons learned at Head in the Web when they are not suitable for Developer.com or DevX.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap