Traditional architecture frameworks are poorly suited to defining and managing an enterprise architecture. I think that assertion has been pretty thoroughly established. As I have written here and elsewhere, we need a new approach to enterprise architecture. But I have also stated that traditional architecture frameworks such as Zachmann, TOGAF, and DoDAF still have their place. But that place is not “everything except enterprise architecture.”

Traditional architecture frameworks originated in an age of stand-alone systems, and they are still best-suited to designing those systems. I don’t mean to say they cannot be used to design interconnected systems, but that they are best suited to systems that are intended for use where the system under development is largely intended to be deployed and operated as a single system. In most cases today, that means a system that is capable of operating disconnected from other systems (even if that means somewhat reduced functionality). Good examples of this type of system are flight control systems, satellite operating systems, or even applications such as word processors or spreadsheets.

The reality of software development today is the most systems are not the kind of old-fashioned stand-alone applications that traditional architecture frameworks were built for. In an age of cloud computing where mashups are common and building a new application on a framework like AWS or Facebook is the norm and not the exception, traditional architecture frameworks are not a good fit. They’re heavyweight and predisposed to systems where requirements can be clearly defined up front. In a DevOps environment, or in an enterprise where available interfaces from many providers can be composed into ne capabilities with a little glue ware, these frameworks struggle to deliver value that aligns with the amount of work they require.

The DevOps landscape requires a new kind of architecture framework, one based on defining capabilities instead of systems. Consider the case of building an application within a framework such as Facebook. Facebook provides some set of functions, such as authentication, that you do not need to develop. Instead, all you need to do is stitch together existing functions and add a little bit of glue ware to fill in those capabilities that are not explicitly available from the underlying platform.

This kind of development calls for a style of architecture that is based on defining capabilities based on the difference between the capabilities available vs. the capability desired. Traditional architecture frameworks are not capability-focused, which suggests they are not well-suited to this kind of work. What is lacking is a means of defining capabilities and what it takes to define a capability and whether it has been completed. I will attempt to better define that over the coming weeks.