Common methods for Enterprise Architecture used at present have been around for ages already. Although these methods have made a strong contribution to the development of the architecture discipline, they have reached the limits of their abilities. It is time to make a leap forward and for that we need a new generation of architecture methods. What characterizes architecture methods of this new generation?

Architects currently working with methods like TOGAF®, an Open Group standard, DYA or IAF might not realize it, but these methods stem from the early days of the architecture discipline. DYA originated in 2001 and the first version of TOGAF dates back to even 1995! Of course, these architecture methods are not dinosaurs that forgot to extinct. TOGAF produces new versions that are the result of lively discussion at The Open Group.

But an architecture method is like a car model. With annual facelifts you can adjust to the latest fashion, but you cannot hide the fact that the basic product reflects the spirit of the time in which it was developed. Car models, including those of the better car brands, reach their end after a decade or so. The automotive industry is used to this and knows that this cycle requires high investments, but also brings new opportunities. Enterprise Architecture is no different!

Let’s take a look back in history. The notion of Enterprise Architecture emerged in the mid-eighties. In that period, people like Zachman discovered that systems development models together create a coherent view on the enterprise. Thus arose the first architectural frameworks. This is the first generation of architecture methods, although a “method” was barely recognized.

The need for a repeatable process to develop and use architecture models emerged in the nineties. This is the time when the famous TOGAF Architecture Development Method came about, later followed by the concept of the strategic dialogue in DYA. This process-oriented approach to Enterprise Architecture was a great leap forward. We can therefore speak of a second generation of architecture methods.

A shocking discovery is that since then not much more has happened. Of course, methods have evolved with the addition of reference models and techniques for creating models. The underlying content frames have improved, now including architectural principles and implementation aspects. But all this is merely facelifting. We are still working with basic designs dating back more than a decade.

In order to make a leap forward again, we must escape the current process orientation. Instead of focusing on a fixed process to develop and use architecture, we must focus on the results of architecture. But that is only possible when we realize architecture is not a process in itself but an aspect of the overall change process in an organization. After all, governments and companies are constantly changing. An architecture method should therefore not be self-contained, but should be fully integrated in the change process.

A third generation architecture method has no fixed processes but focuses on essential architecture tasks, and integrates these tasks in the change methodology used by the organization. It provides a limited set of clearly defined architectural products that can be used directly in the change process. And it recognizes clearly defined roles that, depending on the situation, can be assigned to the right stakeholders. And that is certainly not always the Enterprise Architect. The key of a third generation Enterprise Architecture method is not the method itself but the way it is integrated into the organization.

Erwin Oord, Principal Consultant Enterprise Architecture and Managing Partner at Netherlands based ArchiXL consultancy, has a rich experience in applying and customising Enterprise Architecture methods in both public sector and business organisations. Being co-author of a successful (Dutch) guide on selecting appropriate architecture methods, he is frequently asked for setting up an architecture practice or advancing architecture maturity stages in organisations. In his assignments, he focuses on effective integration of architecture with business and organisation change management.

You should define the first two generations of EA before talking about the third.
What is DYA, own method?

“The key of a third generation Enterprise Architecture method is not the method itself but the way it is integrated into the organization.”
Where does this leave TOGAF ADM? Do you advise Open Group to integrate it in the enterprise change process?

I would have thought obvious though that no EA transformation may or is allowed to take place outside the enterprise change process.

I started reading this blogpost with high expectations. The next generation EA. Wow, this would be exciting. However, I must admit that I am now left a bit disappointed.

You claim that “But that (focusing on the results of EA) is only possible when we realize architecture is not a process in itself but an aspect of the overall change process in an organization.”

Well, if this is shocking news to you, I’m afraid you’re still at the first generation of EA rather than the third. Integrating EA with other governance and change processes in the organisation is clearly addressed in the preliminary phase of the TOGAF ADM.

I do agree with you however that, based on our experiences (pre and post preliminary phase), integrating EA in the organisation is key to its success. There’s just nothing new about that.

I don’t agree that recent TOGAF etc updates have been “facelifting” (TOGAF 9 is particularly well rounded in ways v7 was crying out for, and helped make less ‘technical’) yet I fully agree with the wider point that a significant change – not just evolution feels right.

How do we define such change ? I don’t see concensus — so at least welcome start the debate.

Consider external factors. To me, we are ending the age where supply was constrained. The Cloud-based “as-a-Service” world turns that on its head. We still need to consider context, integration, nay requirements — but this change is fundamental.

We surely agree architecture needs to integrate with change. Should the Open Group expand its remit or partner with Programme managers and other business functions more ??

That means we integrate with non-IT communities. A simplified VIEW of frameworks will be essential (even if practitioners find such overly simplified …. we have to explain indeed sell ourselves effectively !). The crop-circle worked well but only for a sub-set of TOGAF.

Finally we should talk the language of business more. Processes, Information (… though that’s an unhelpful term; knowledge and understanding will dominate “information” or “data” in the cognitive world), Services, locations, suppliers, partners, customers. We don’t talk this language enough.

Taking that further —- finance. We don’t seem to have even tried to talk that language; surely for evidence-based structural / systems or thinkers this is inexcusible ?