Managing Change With Real Enterprise Architecture

Future technologies are great, but how to manage the risk of implementing them as process, product or service?

This page discusses the Dragon1 theory on how to use real Enterprise Architecture to manage change.

Read this page first before doing the Dragon1 Architecture Game Plan.

It will create a common mindset amongst people to create interactive visualizations together on Dragon1 and have them used by stakeholders to manage change.

Learning Objectives

  • What is Change?
  • What is Mainstream Enterprise Architecture?
  • What is Real Enterprise Architecture?
  • What is an Architecture Framework?
  • What is an Architecture Design Assignment?
  • What is a Program of Requirements?
  • What is a Total Concept?
  • What is an Architecture Principle?
  • What is a First Principle?
  • What is Current State and Future State (AS-IS and TO-BE)?
  • How to use Interactive Visualizations to Manage Change?

What is Change?

Drones will cause more change and impact than we can imagine right now in 2016.

Change is something we all come across. Every day the organizations we work in or we work for are different from the day before. This because the needs of people change, because of new legislation and because of new scientific discoveries and technologies from the industry, etc. The smartphone is an example of a huge change in everything. The smartphone changed many things, like the way we solve cases in crime. All stories in movies now are different because of the possibilities of the smartphone.

In organizations many changes (or transition or transformation) we want to manage, for instance introducing a new product, business process or information system. In all these cases we want to manage the change: to set goals, measure and check progress and (re)direct the projects. Some of these changes are fundamental, drastic, ground breaking, changing the rules of a complete industry. In that case we call the change an innovation: think of Google, AirBnB and Uber.


In organizations we also define RISK. Risk is defined in Dragon1 as the costs of failure. We want to manage the risk during a change. In other words we want to minimize or mitigate the cost of problems we encounter during the change. Suppose we need to replace a software application. That could cause disruption of services to customers, which could cause fines, penalties or even law suites. Did you know that most product introduction fail because of compliance issues with legislation? So that is an important Risk to manage. Many organizations today are having a problem with introducing digital products and services, because they don't know how it will impact their real world products and services. Think here: Microsoft with MS Office Desktop software versus the Amazon AWS and Google Cloud with MS Office 365.

Managing Change

The introduction of the smartphone still has huge impact of change in all of our business processes and IT systems.

Did you know that in 2016, 70% of all projects fails and did you know that 90% of yearly targets of strategic goals are not reached? One could say that these two facts make it clear that every director and manager needs Enterprise Architecture.

Managing change, transformation or transition is what puzzles a director and a manager. How to do it? How to deal with risks, budgets, showstopper? How to keep the stakeholders calm? How to have suppliers collaborate with the employees and with each other? How to deal with the change in processes, applications, technology and CULTURE? All these questions and so few answers.

Managing Change of Workforce

Note that not only the products, services, processes and IT technology changes, but also the workplace and workforce. In our organizations today often four different generations are present that bring along four different types of culture and these four different generation vary from presence impact everything. And how are you going to manage that change?

Enterprise Architecture (EA) is, correctly used, a management instrument that can act as a bridge between Strategy and Transformation. This because Enterprise Architecture is a total concept for a structure and documented as integral Business/IT design. 'EA can act as a bridge', because if you do not apply Enterprise Architecture properly, it won't act as a bridge.

So for a director and a manager Enterprise Architecture is of usage to help change, transformation, programs and projects succeed.

Strategy -> Architecture -> Transformation

The Dragon1 Enterprise Performance Framework

Strategy is defined (in the Dragon1 open EA Method) as 'a coherent set of goals and efforts for directing an organization'. Transformation (Business Change in the picture above) is defined as 'a process of profound and radical change that orients an organization in a new direction taking it to a much higher level of effectiveness'. Architecture is defined as a total concept for a structure and Enterprise Architecture as total enterprise concept for an enterprise structure.

With these three definitions you can actually tie the three words together: Strategy provides the WHY and WHAT of where the organization should be heading. Architecture converts it into a grand integral business/IT design to build the new organization. Transformation is the actual process of changing the organization piece by piece using the grand design.

Managing Change without Enterprise Architecture

Too often deliverables from different projects don't fit together.

As strategy and transformation are done and taking place in almost any organization, but without doing enterprise architecture, we see that many programs and projects are started up all using their own vision and design, blueprint and roadmaps to realize. One can call this unstructured decentralized transformation. This causes a lot of programs and projects to fail. The alignment between projects is impossible and the results of the project do not amplify each other, but rather block each other. Showstoppers are around every different corner.

If a change is not that complex one can succeed by accident or by being lucky without using Enterprise Architecture. In all other cases Enterprise Architecture can be seen as prerequisite for success. So the challenge is, how to apply Enterprise Architecture so that it leads to coordinating all programs and projects integrally?

Mainstream Enterprise Architecture

Enterprise Architecture today is practiced in two ways: as real Enterprise Architecture and as Strategic IT Management & Consultancy (a.k.a mainstream Enterprise Architecture).

Mainstream Enterprise Architecture has an IT focus. People in this case may hear the word 'architecture', but they think, will and act 'IT'. In mainstream enterprise architecture, the architects see themselves as consultants, who without being asked, provide advice to any stakeholder on what to do and how to improve things, so that IT better supports the Business Processes. But this is all often without business cases and support from the board room. A fundamentally change for instance implementing standards enterprise wide in organizations without the support of CxOs and enough budgets in projects, will not have that much effect. Before you know it, in this situation stakeholders will continuously ask WHY the architects want to have all these costly state of the art solution that no-one asked for. And you end up as architect trying to explain what is architecture and why it is needed. JUST DON'T DO THAT! Building architects also never explain what is their method and framework they use, and that is for a reason!

With mainstream EA you can certainly increase the maturity of your IT Management, Information Management and Information Security. But you won't be able to fundamentally change business models, move supporting walls, shorten time to market for products or really transform the organization enterprise wide into a digital company. Because there is also something called Human, Culture, Money and Raison d'etre (the existential reason of the company). And they are miles away from IT, but they're part of real Enterprise Architecture.

Mainstream EA produces hideous diagrams that are never used to supporting decision making by managers. Everybody knows the process and application landscape created, for instance using the ArchiMate model notation, that only the architect understands. These models maybe necessary at one point for some supplier or engineer, but they can never be the most important diagram to create as part of the grand architecture design.

Real Enterprise Architecture

Real Enterprise Architecture is what we promote on Dragon1 and what Dragon1 is all about!

Real enterprise architecture is about designing a total concept for an enterprise structure, where that total concept act as a bridge between strategy and transformation. There are various domains for with total concepts can be designed: business architecture, solution architecture, etc... A diagram that shows for which domains architectures can be designed is called the Enterprise Architecture Framework diagram in Dragon1 [read here for an example].

Architecture Design Assignment

NEVER EVER create a design without an owner/client having asked for it. Because: who is going to approve the requirement, the design and pay for the realization of it? (Know that design is another word for building plan).

For an architect the CxO is the natural owner/client. A CxO is accountable and responsible for certain parts so of the organization and has the power and privileges to change these parts.

Create a portfolio of visualization on Dragon1 of the work you have done before and use that to get an official Design Assignment or contract for an Architecture Study from an Owner/Client.

Program of Requirements

Designing a total concept for an enterprise structure is simpler said than done. You, as architect, are the moderator of creating a Program of Requirement per strategy, organization, solution or project. And in this PoR you write down mission, vision, stakeholders, strategic starting points, needs and requirements and all kinds of other things. And if you have your PoR ready and validated by the owner/client and stakeholders, you are create to create a total concept.

Total Concepts

A total concept consists of concepts. And in your PoR you will find direct or indirect demands and requests for concepts or elements and components that are part of the concepts. Of course you don't want products names and brands in your Total Concept, you restrain to elements (logical functional parts) and components (technical physical parts). You are now selecting concepts, using your experience and creativity and doing some Proof of Concepts. You draw sketches and principles diagrams and create small and smart business cases for the owner/client and stakeholders so they approve of your proposal to make the concepts part of the architecture (total concept).

Dragon1 defines that the Owner/Client tells the architect who should be seen and used as stakeholders to collect or get requirements from. Also Dragon1 defines that the architect creates a stakeholder onion diagram and collects requirements from the stakeholders, using Use Case Diagrams and Customer Journey diagrams and all kinds of sketches.

Architecture Principles

In real Enterprise Architecture, or better said, in the Dragon1 open EA method, a principle is about the way a concept works and produces results. Architecture Principles are (promoted) principles that are valid throughout the structure. So a total concept consists out of concepts and every concept has a first principle.

First Principles of Concepts

A first principle reveals or describes the enforced way the whole concept works producing results. A principle consists out of element (at logical level) and out of components (at physical level) and out of technical products (at implementational level of abstraction).

As architect you are on the search for elements and components that are present and/or are missing in the organization. With that you as architect can analyze what percentage of that concept is already available (% applied) in the organization and how mature (m=?) it is. In Dragon1 where write down the %, m, t and $ for every concept. T is the implementation time and $ is the implementation cost.

Current and Future State (AS-IS and TO-BE)

You don't need to, but you can create first an overview of the current organization at the four levels of abstraction (per domain or as a whole). And you can differ between generic overviews, medium overviews and detailed overviews. Next project or re-engineer the concepts and the principles by looking at the elements, components and technical products. As architect you definitely always need to create at one time in your project (Architecture Study) the future state of the organization. In Dragon1 we call the pictures you create at implementational, logical and physical level the Structure Diagrams. The diagrams at conceptual level we call Architecture Diagrams.

Managing the Change with the interactive Visualizations

Although it is mentioned before, here we repeat the core activities of managing:

  • Setting goals
  • Measuring and Checking progress
  • (Re)directing people and steering projects and processes

Isn't it great that with interactive visualizations created on Dragon1 any stakeholder can do all three of them?

Now we are at the point that of the intended change there are up-to-date visualizations placed (published) in the Content Viewer. This means every stakeholder (by logging in) can access the visualizations. And they are meaningful to them, because for one thing, many of the stakeholders participated in creating them.

As architect (or creator of these visualizations) you now need to promote that stakeholders use the visualizations in discussions, meetings, presentations. And if something is not correct let them comment the visualizations. Also try to get the visualization approved and have an official status. In that way you will trigger usage of the visualization almost automatically.

With these visualizations you really help all stakeholders, preventing the failure of change projects and programs.