How to Create an Enterprise Architecture Framework Diagram

What is an Enterprise Architecture Framework?

enterprise architecture framework management report

Using an Enterprise Architecture Framework as a Management Report.

Get insight and overview in your EA documentation

On the Dragon1 platform, you can generate or create manually 100% data-driven Enterprise Architecture Framework diagrams to get insights and overviews in the documentation of the architectures.

This page will inform you how to do that in about 19 steps.

The following questions are answered in this tutorial: 'Why should you start creating an Enterprise Architecture Framework?', 'What steps do you need to take to create an EA Framework, and 'What should the result of an EA Diagram look like'?

An EA Framework Definition

An Enterprise Architecture Framework, in its smallest form, is a classification scheme of types of architectures and their most important parts in a single schematic overview.

Dragon1 has defined an Enterprise Architecture Framework as follows:

An Enterprise Architecture Framework is a basic structure (like a method) grouping types of architectures that are filled with a set of key parts and tools, such as capabilities, concepts, principles, objects, reference models and view types, which can be used for documenting architectures efficiently and effectively and developing a broad range of different architectures and solutions as part of enterprise architecture.

An Enterprise Architecture Framework can often be visualized in a reasonably small but comprehensive diagram. Often, you will want to create separate diagrams or views for the various architecture plateaus (AS-IS, Plateau n, TO-BE, Envision).

Why create an EA Framework?

As an Enterprise Architect, one of your primary tasks is and should be creating AS-IS and TO-BE Architecture Framework diagrams for several types of architectures, starting with the one for Enterprise Architecture.

The diagram reveals to everyone which architectures are defined and recognized as part of the current state and future state architecture that is defined and present, but also which ones are not (yet) defined and recognized in the organization.

This is important to understand and know for the project and suppliers. For instance, if there is no definition or recognition for business architecture or data architecture in an organization, it is hard to coordinate suppliers and projects if they are implementing or changing parts of the business architecture and data architecture.

Architecture Framework States: AS-IS and TO-BE

The TO-BE version (often the ideal situation) of an Enterprise Architecture Framework is more complex and harder to create than the AS-IS version (often the realistic situation) since it requires new visions, missions, and strategic decisions. It (the TO-BE) also had a delayed effect.

The AS-IS impacts today, even if you have not created the enterprise architecture framework yet. The sooner you introduce definitions and a list of key parts and tools per architecture, the better you can manage projects and suppliers

Therefore, it is always useful to visualize the AS-IS framework and reuse the current (old) strategy aspects to create the diagram.

The available TO-BE and AS-IS architecture diagrams are extremely helpful in supporting high-level overview and decision support.

It is just sitting there, waiting for you to dust it off!

Enterprise Architecture Frameworks show the types of architectures used at a certain time, and it shows the concepts, principles, standards (norms), building blocks, metamodels, and user models that are part of the underlying architectures.

As an enterprise architect, you can decide which parts of the architecture should be part of the framework.

The below view of the framework diagram shows only the recognized architectures. This is a valuable diagram for the organization and is bound to facilitate many discussions.

Enterprise Architecture Framework Diagram.