Tony Baer
Open Group's TOGAF 9 makes EA more accessible
The latest release of the Open Group's TOGAF enterprise architecture (EA) framework is far more modular and better annotated than previous versions. It is part of the Open Group's strategy to make the discipline more accessible and hopefully relevant outside the choir. TOGAF 9 is a good first step, but it is only a first step. The EA community at large needs to adjust its expectations to a world that has grown hostile to long-fuse, long-payback projects. It could pick up a few pointers from the world of agile software development. TOGAF 9 is aimed at a wider audience outside the core EA community The latest version of the Open Group's EA framework, TOGAF 9, has reorganized content so that assets, such as the reference models, are in one place and easier to find. Similarly, its core process steps, which are part of TOGAF'S Architecture Development Method (ADM), consist of self-contained steps such as outlining the architecture “vision” (high-level goals); the technology migration process; and the respective architectures for business activities, applications and databases, and IT infrastructure stack. TOGAF 9 makes these steps even more self-contained, as it organizes the content and references which activities should be performed as part of these steps. In so doing, it eliminates much of the guesswork and searching necessary with previous versions of TOGAF by adopting an approach akin to the patterns used in software development. In essence, TOGAF 9 presents examples of the steps that are commonly performed with specific EA activities such as outlining business architecture or planning technology migrations, enabling architects to borrow and adapt rather than reinvent.In so doing, the Open Group has started to demystify TOGAF and the practice of EA in general to make it more widely accessible. But let's not get carried away. Making the process easier to understand is a useful step to making EA more understandable and less intimidating to the majority of enterprises out there that cannot afford the luxury of a top-to-bottom mapping of IT inside their organizations. However, on its own TOGAF 9 does not address the issue of making EA relevant to organizations and professionals outside a small, elite EA community restricted to well-funded government agencies and the Global 2000.EA must become more agile if it is to become more relevant A survey conducted at the recent Open Group conference where TOGAF 9 was unveiled revealed that a majority of attendees continue to act under the assumption that two-year paybacks for EA projects are reasonable. Outside the core EA community, such a premise is clearly unacceptable as there is scant appetite for “transformational” IT projects. Clearly the EA community needs to wake up and smell the coffee. It could take some cues from the agile software development base, which has refined practices for developing useful software with lighter processes and shorter turnarounds that emphasize usable code within weeks. We make this recommendation with full realization that agile is not a silver bullet for all software development, and that as agile scales up it also needs to add heavier processes in areas such as modeling and requirements. Nonetheless, a “lite” EA effort could involve mapping just the processes relevant to specific pain points, but doing so in a manner that automatically documents its tracks so that the teams are not constantly retracing their tracks. Consequently, we'd like to see the Open Group's next move with TOGAF involve development of patterns for lighter implementation of the steps outlined under the ADM.And while we're at it, we'd also suggest that the community stop calling this enterprise architecture, as in our eyes it implies process for process' sake. How about rapid rationalization of systems development or something like that?
