Because of my involvement in SOA/TOGAF practical guide project at The Open Group, I am getting many questions related to the use of EA frameworks in general. I just want to share some of my discussions with people on this topic here. Many enterprises have been (and are being) challenged, for example, on use of TOGAF for their real EA initiatives. The challenge is the misconception that EA framework, such as TOGAF, can be used “as is” for supporting Enterprise Architecture work. EA frameworks are “frameworks” and they are not meant to directly apply to all situations and solve all enterprise architecture challenges the same way. This means such EA frameworks must be viewed as a “guide” and needs to be customized to address the individual enterprise needs. EA framework, such as TOGAF, needs to be customized by taking into account at least two factors:

1. Enterprise or Organization needs: What is that the enterprise trying to achieve (business drivers) and what is the maturity level of the EA in that enterprise? Is the enterprise ready to undertake complete or partial business architecture to drive Information, services/applications, data, and technology architectures? Or is the focus on information, applications and technology aspects with limited business architecture effort? What level of governance is needed? How good is the existing EA processes to accommodate the applications/services development (in other words, how integrated is the EA process with the common SDLC processes)? Many more such questions need to be asked to properly customize the EA frameworks in such away that the newly customized EA framework can effectively support moving the enterprise from current state to the target state (or achieving the target business objectives). What this means is that newly customized EA framework should help in addressing current and future enterprise challenges. One important thing to note here is that the customized EA framework is not “final or static” by itself – it needs to be positioned to evolve with the enterprise needs.
2. Architectural style adopted or in use in the enterprise: For example, if the enterprise is adopting SOA style, then the EA framework must accommodate such an architecture style to be of value to the enterprise. Failure to recognize this aspect of customization to the framework leads to disconnected EA work and SOA projects. This is real and you may have experienced such a challenge – i.e. SOA and EA viewed as separate streams of work and a communication gap between the two teams created.

   In addition to the above points, one should also pay attention to the link between EA deliverables and the actual solution implementation projects. Whatever you do in EA, its value is realized only when the artefacts are deployed and show value to business (e.g. customer satisfaction, business agility, etc). The EA metrics (to measure the success of EA effort) are collected based on such values to the business. EA deliverables must guide and support the solution implementation projects. Thus, EA framework customization should include such a linkage to the solution implementation projects.

Bye for now -:)

Awel Dico