The first post elicited quite a few great comments, so here's part deux.

To the right is a sanitized example of a hierarchical federated EA model*. At the top level of EA Framework reside the Reference Models. These models are quite flexible and can accommodate multitude of notations and purposes - some examples would be SOA Reference Model (from OASIS, for instance) or PMI Reference Model better known as PMBOK. In short, these are the "meta" portions of what we do and how we do it. They provide the vocabulary and rules of engagement. Whether they are acknowledged formally - or not, as the case may be - these models are in use in every single for-profit and non-profit entity.

Within these reference models reside Reference Architectures. So why are Reference Architectures valuable? The real value is the glue that they provide between conceptual realm of Reference Models and the two Brick and Pattern layers below. The Reference Models have a level of complexity that is difficult to translate into working process and technology. The value of Reference Architecture is in complexity reduction that is suited for implementation. For example, a Security Reference Architecture would contain Architecture Patterns (logical solutions for technical security capabilities like Authentication, Authorization, Access Control, et al) and Physical Patterns (here's how our organization implements role-based access control in J2EE-based application layer or here's how our organization implements authorization for .NET-based application layer, etc.)

ROI of any such Reference Architectures to an organization can then be tracked through the adoption of these patterns in both pre-project and project activities. While concrete value is through implementation, to quote Deming: "In God we trust; all others must bring data." If these patterns are implemented, but nobody collects metrics to validate and update ROI for Reference Architectures, it never happened. Also, collecting useful metrics on value through adoption must start when a project is in planning phases. Comparisons between Ref-Arch based solutions sets and point solution sets should be a part of decision-making process (that may sound like heresy coming from a former Chief Architect, but point solutions do have their place in our tool belt.) True costs and value of these decisions need to be documented and presented to the stakeholders who own the P&L that is impacted both before, during and after projects. I've never heard of a stakeholder frown during "here's how much money we saved you this quarter" portion of a regular update - as long as those numbers were backed up by agreed to and solid metrics.

That brings me to the "gray" row in the Reference Architecture Hierarchy. The color choice is apt because there is a tremendous amount of ambiguity involved in connecting Reference Architecture artifacts with Projects. Successful linkage depends on many "soft" things like organizational culture(s), human resource strategies, and stakeholder alignment - just to name a few. Without implementation of methods and processes in the "gray" row, however, there is little chance that those who promote, and sometimes evangelize, the concept of Reference Architecture will be able to demonstrate value on a sustainable basis.

AAB

* Domain Architecture Frameworks are not necessarily the same as the Enterprise Framework for some Business Operating Models. For Business Operating Models that do not require federation across business units, this may not be applicable so EA and DA levels can be combined.