
This post is actually an extended comment made on an earlier post by James Odrowski of Componentwave. It's based on his experience on a large Federal EA initiative. I thought it might have got lost in the pile of old posts, so I thought I'd resurrect it:
From our experience, the FEA and TOGAF complemented each other well. We applied them together in planning and implementing a large modernization effort for a federal agency. The TOGAF ADM provided the process for establishing a segment architecture, and the FEA provided the detailed reference models needed to initially populate each architecture domain. The individual frameworks of the FEA (PRM, BRM, SRM, DRM and TRM) provided a well-integrated reference model mapping to the ADM architecture domains (business, application, data and technology). See http://www.componentwave.com/whitepapers-2.html “Applying Architecture Frameworks for Modernization” for details. The big benefit of applying the FEA in this modernization effort is that it provided a common structure for understanding current IT assets, helped communicate a target direction, and organized the plan or roadmap for transformation. Compliance to OMB reporting requirements was a useful (and necessary) by-product. Although TOGAF was recognized in the organization, we didn’t make a lot of noise about applying the ADM, it just naturally fit as a way to organize our efforts. I think that TOGAF 9 made significant improvements in describing how the ADM can be applied, which better fit the process that we used (see TOGAF 9 “Applying Iteration to the ADM”). In our case we utilized a “baseline first” approach in order to understand the current environment and better plan the scope of the modernization effort.
John Polgreen is President of Polgreen Associates, Inc. and Associate of Architecting the Enterprise. Please download the full version of TOGAF 9 at theopengroup.org. You can also contact John at john@polgreenassociates.com or at ![]()

![]()
![]()

![]()
![]()
![]()
![]()
![]()
![]()
410-980-6287
for information on consuling services and TOGAF certification courses.
What are your thoughts? Do you have some TOGAF or TOGAF-like experiences in your agency? I'd very much like to hear your opinion.
Your comment on TOGAF providing good reporting for OMB is right on the money. The improvements you mention in TOGAF 9, especially in regards artifacts described, provides even further assistance in this area. OMB reporting can be a burden on EA teams, and TOGAF process and artifacts can go far to reduce this burden.
The decision to use a baseline first approach was driven by the major project objective to retire an entire legacy platform. Some of the key questions to answer included:
This current state information provided the detailed inputs needed in Phases E (Opportunities and Solutions) and F (Migration Planning).
I understand the concern of "boiling the ocean" or "analysis paralysis". We collected the minimum amount of current system information needed to support the above decisions and establish a "roadmap" or sequence of migration projects. I would caution against trying to collect too much detail in the baseline (particularly about existing data stores!). We made the decision to defer detailed analysis to each project on the roadmap. Another note: having experienced government staff participating on the project speeded up the effort to collect current system inventory information.
Your reply to my question is pretty much what I expected - your eye was on the customer's concern. You obviously tempered your need for detailed baseline information with TOGAF's advice to collect just enough baseline to support the target.
Thanks, Jim, for the great overview! I'm curious what it was about your project that made you emphasize the baseline architecture. There was so much problem with 'boiling the ocean' in early EA projects that the new conventional wisdom (including TOGAF's) is to emphasize the target at the expense of the baseline.