TOGAF 9 is a great framework. It has a robust "chassis" on which one can really build a solid Enterprise Architecture function. The only problem with it is that some parts of it are outdated. One can really see that all the parts work together quite well and it's easy to see why it became so hot some time ago. It's like an old Rolls Royce; you admire its quality and enginnering but it is no longer the most practical means of transportation for everyday life.
Take for example, the Architecture Building Blocks (ABBs): according to TOGAF's definition ABBs "capture architecture requirements; e.g. business, data, application and technology requirements" and they "direct and guide the development of SBBs" (note: SBBs are Solution Building Blocks). ABBs are therefore "logical" components. Moreover, also according to TOGAF's defintion, a building block (whether ABB or SBB) "has a defined boundary and is generally reconizable as "a thing" by domain experts".
The intention is understandable. By abstracting the "thing" into a set of functions one should in principle find ways to easily repliace it by another equivalent "thing". The thing can be a web server, a database, an application server, a CRM system and so on.
The problem is that this kind of bottom-up abstraction logic doesn't last very long, since it is driven by implementation. It's like saying that in order to move items from point A to point B one needs a truck. "Truck" would then be the ABB and the actual choice of a brand and model would be the SBB. But who says that one needs a truck? What if the business finds that hiring a transportation company is cheaper than buying a truck?
Indeed it is much more important to document that you need a transportation service with certain service requirements; this service should show up in every other area of the enterprise where it is needed. Then the decision of, say, reusing a truck that is already used by some other department in the enterprise or of hiring a transportation company instead can be supported by real business arguments. Maybe the other department would benefit from a general contract with the transportation service and get rid of its truck. Or they would just agree to share the truck. Either way what is important is first looking at the application services that are needed to support a certain business process or function, and then at possible solutions to provide these services. ABBs are an artificial construction for which I don't see any value added at all.
Furthermore by extending the service concept downwards to the infrastructure level a quite useful system map can be easily obtained. In fact the application components will use infrastructure services that are in turn provided by infrastructure components. By documenting all that you end up with a map of the business processes that require each infrastructure component via application services. This is a powerful tool to optimise the whole IT landscape.
Coming back to TOGAF 9, there is somethting else that belongs to the 1990s museum: the reference models - the Technical Reference Model or TRM and the Information Information Infrastructure Refernce Model or III-RM. Here's a quick summary of these 2 animals:
- the TRM says that applications are built on top of application platforms which use different services requiring different qualities. These are provided by an Operating System which uses network services which is built on a communciations infrastructure;
- the III-RM says that you should use a broker between consuming and provider applications.
These are quite generalistic and over-simplistic views. They are true for most (but not all) IT applications out there but what value does this actually provide? The way I see it each Organisation must produce its own set of reference models, reference architectures and patterns based on its needs and constraints. What TOGAF should be focusing on is a method to help develop these artifacts. Building them is an incremental exercise that is essentially capability-driven. For example when a new capability is identified as beneficial for the enterprise it is usually best to make a shared service out of it. Then you need a reference model for it and from the model (by mapping it to the existing landscape) you can derive a reference architecture and finally a set of patterns to guide consumers using the service.
In summary, TOGAF is a great framework as it really helps to manage the many aspects to the enterprise architecture but I think that a new model of this Rolls Royce is long overdue. The fact that The Open Group took on board Archimate as a common language looks promising, since Archimate provides an excellent way of representing a top-down and service-oriented view of the enterprise; I can't wait to see the next new major version of TOGAF.
