Advisor

An EA Metaframework

Posted May 11, 2016 | Technology |

Like me, you are probably aware that there are a very large number of architecture frameworks. And like me, you may wonder whether we really need them all. It is certainly something that I have struggled with over the years.

A conversation I have frequently with clients about architecture frameworks usually includes some or all of the following questions:

  • Which architecture framework should I use?
  • What are the benefits in using TOGAF? What are the weaknesses of TOGAF? (Here you can substitute any other framework in place of TOGAF; for example, Zachman, Department of Defense Architecture Framework, Pragmatic Enterprise Architecture Framework, Information FrameWork, and so on.)
  • How can I combine the best bits from the ABC framework with the XYZ framework?
  • Should I create my own frameworks? How do I do this?
  • Are frameworks actually useful or practical?

I’m sure you get the general idea.

An EA metaframework is a concept and tool that I use to help answer all of these questions. I started using the term four or five years ago after coming across a book in our local library. I was walking past a shelf that had a book on prominent display with a title that leapt out at me: Metaframeworks: Transcending the Models of Family Therapy. I don’t know anything about the field of family therapy, but I felt a strong affinity with the concept. It is worth quoting from the overview:

This breakthrough book takes you beyond the theoretical boundaries that currently constrain family therapy and leads instead to an innovative approach. The authors analyze the different orientations of family therapy schools and provide a foundation for understanding the fundamental concepts that underlie all approaches. By integrating these multiple models of therapy, or metaframeworks, you can improve the flexibility and comprehensiveness of your treatment, without having to abandon your training.

The idea is very simple, and when applied to EA it means that instead of being limited by a particular framework or approach, architects can apply the fundamental concepts that underlie all approaches. Combining multiple models of EA into a metaframework allows architects to extend their capability and skills, and at the same time it unites divergent techniques into a coherent and integrated way of thinking about enterprise architectures.

A metamodel defines the constructs, relationships, guidelines, rules, constraints, and theories that apply to a model. In the same way, an EA metaframework defines the factors, constructs, relationships, guidelines, rules, constraints, and theories that apply to architecture frameworks.

In essence, what a metaframework does is to take all of the things that you find in architecture frameworks, then shifts them up a level to describe them as types of things. This is all getting a bit philosophical, so let me give you some examples:

  • All architecture frameworks refer to domains and subdomains. The most common high-level domains are business, data, application, and technology. If you have read some of my work with Cutter, you’re familiar with these other high-level domains: the organization, the environment, and the social domains. Then there are subdomains — such as product, process, event, and business rule — which are commonly part of the business domain. These are all examples or instances of domain. So an EA metaframework must include the notion of domains and subdomains. Closely connected to this is the idea of separation of concerns.

  • All architecture frameworks include the idea of moving from the current state toward a target architecture. So an EA metaframework must include the notion of architectural evolution, which includes other important concepts such as architectural states, roadmaps, timelines, and capabilities.

  • All architecture frameworks include the progression from an architectural blueprint through to implementation or realization. An EA metaframework covers this with the levels of architectural understanding. These levels describe the different types of architectural understanding — as an idea passes from the architectural realm, into the solution or design level, then on through the development or implementation level, and finally to the operational or systems level.

The idea of a metaframework isn’t really anything new. It is simply a way of describing something that enterprise architects need to do. For example, whenever the architecture team combines techniques from more than one framework or approach they are using the concept of a metaframework; they may not be using it explicitly, but it is always there, at least implicitly. And again, the notion of a metaframework is present whenever an architect presents information about the architecture using more than one stakeholder view or viewpoint.

But something has changed in recent months, which is the growing recognition that it would be really useful to document and record exactly what is meant by a metaframework, together with a simple explanation of how it is used in EA. Earlier this year, I posted the following comment on my blog: “Instead of creating yet more architecture frameworks, EA practitioners need to collaborate more to describe the EA metaframework — the underlying foundation that is common to every EA framework and approach.” Since then I’ve received overwhelming encouragement and support for the idea of an EA metaframework.

In a recent Advisor, my colleague Cutter Senior Consultant Balaji Prasad suggested that “Maybe what we need is a “meta-architect” — someone who architects architecture itself, so that we can break the silos that the silo-breakers build?” I think he is absolutely right. And maybe we also need an EA metaframework, to establish EA as a true professional discipline; one based on a common synthesis of theory and practice that is drawn from all EA frameworks and approaches, rather than a discipline that is predicated on a single, silo framework.

About The Author
Roger Evernden
Roger Evernden has been an enterprise architect since 1984, specializing in the highly practical use of EA to manage organizational transformation. Mr. Evernden acts as advisor, mentor, and coach on EA initiatives, leads training workshops, and writes regularly about strategy and architecture. He provides a unique combination of training and tools to help architects and their teams throughout an EA program and at each capability level. Mr.… Read More