Architecture itself is not as broken as I had begun to think. The issue is not so much that architecture is broken, it is that the way we do development has evolved considerably, while our conception of architecture has not.

Architecture frameworks rest on the assumption that all problems should be approached from the same point of view: that the desired functionality must be created from the ground up. At the time most of those frameworks were developed, that was true. In the 1990s (about the time most architecture frameworks were developed), if you wanted to create a system to correlate photos to places on a map, you had a lot of development work to do. You would need to create or reuse a software module that displays maps. You would need a database to store the information correlating individual pictures to their place on the map, and you would probably want to standardize the kind of location designation (latitude/longitude, Universal Transverse Mercator, etc.) If you wanted a multi-use capability, you would need to create some means for managing user identities. You likely would have to create every capability from the ground up. If there were some libraries you could reuse, you would have to ensure they were written in a compatible language and operating system. If you were creating an application to run on Microsoft Windows, you couldn’t use a mapping package written for Unix. Furthermore, networking capabilities were variable if they were available at all. Ethernet, Token Ring, Fiber Distributed Data Interface, and other networking protocols were still competing for dominance. Any networking within the application would have to make some decisions about how to access the network and which protocols to support. And a network connection was by no means assured; most people who had a network connection were using a dial-up connection through their phone line.

Current development practices really don’t have to deal with so many complexities. There are libraries for almost any conceivable function for nearly any language and operating system. With networking standardized on Ethernet and the ubiquity of broadband connections, many capabilities can just be invoked over the network using web services. Need a map? Take your pick from Google, Bing, or many others. Need a user management capability? Facebook, Google, and a number of other companies will gladly handle your authentication and authorization needs.

What this all means for the developer is that creating a new capability no longer means creating a new system. Often, all that is necessary is to stitch together existing capabilities plus a few new modules or some glue ware and the new capability is ready. In many (if not most) cases, all of this runs over a network with the various capabilities hosted in a number of places and invoked over the network as needed. The user’s operating system is increasingly becoming nearly irrelevant with the move to cloud-hosted applications. This makes most of a traditional architecture framework either irrelevant; much of what isn’t irrelevant is overkill and is too heavyweight to be efficient when using modern development practices. This is even more obvious when employing DevOps practices.

That said, there are some exceptions. Systems that must operate in isolation, without network access or with very constrained bandwidth, often have to be built the old-fashioned way. Every function needed must be hosted locally, so thinking though all of the functions needed and how they will be accessed remains an important task. Examples of such systems include tactical military systems, aircraft flight control systems, and the systems used for interplanetary space missions. Put another way, there are some cases where we still need to develop entire systems. Traditional architecture frameworks serve these development efforts very well.

So I draw the conclusion that the problem with traditional architecture frameworks is that they only solve one problem well: the problem of soup-to-nuts development that really only applies to systems that must operate in isolation. These frameworks are inefficient for use when developing a new capability by stitching together existing capabilities with glue ware.

In short, what we need is a solution architecture framework that is tailored to developing capabilities instead of systems.