For a number of years now I’ve been the lead architect for what can reasonably be called a system-of-systems interoperability effort across a portion of the US Department of Defense (DoD). It’s not an integration effort because there is no intent to combine the systems or formally link them together. The intention has been more to enable them to reuse each other’s components and / or to exchange data as needed.

To enable this, we created an enterprise reference architecture. We defined it using the DoD Architecture Framework (DoDAF). We created it, reviewed it with stakeholders, updated it based on their feedback, and published it. We’ve updated it roughly quarterly for nearly a decade, publishing and sharing it with all who were interested. And then we graded the various programs that fell within its purview on how well they conformed to the guidelines in the reference architecture. We even published an annual report on their progress to senior leadership could gauge the effectiveness of the effort.

And it failed. The affected systems do not interoperate any better than they did a decade ago. They don’t reuse components to any significant degree. And they largely ignore the reference architecture in the process.

There are a number of reasons for this failure. Many of those reasons can be put down to perverse incentives in the DoD procurement system; others can be attributed to the fact that the office publishing the reference architecture has no budgetary authority over the programs it is trying to govern. But there is one reason that is even more fundamental: the discipline of enterprise architecture as it is currently practiced is based on flawed assumptions.

I am far from the first person to conclude that enterprise architecture is not delivering on its promises. People have been pointing out that enterprise architecture has failed for over a decade. More recently, others have declared that enterprise architecture is dead. But for all of the articles I have read that are in a similar vein, most just dismiss the entire field as either a failure or obsolete in the face of changes in the software development process such as Agile and DevOps. There is a more compelling argument to be made that the problem with enterprise architecture is that we’ve been doing it wrong, such as the argument made here.

I have come to the conclusion that the problem is not with the idea of enterprise architecture, the problem is with the execution of enterprise architecture projects and the frameworks that are used by most enterprise architecture projects. Toward that end I have been devising a new way of doing enterprise architecture. More to follow in the coming weeks and months.