What if Organizations are fooled with Enterprise Modeling labeled as Enterprise Architecture

dinsdag 15 december 2015 | Likes: 0 | Comments: 0

Mark Paauwe

VP Product Development

Dragon1 Inc

Are You Waiting for Fundamental Strategic Changes that never Happen?

Many organizations today start using enterprise architecture frameworks and enterprise architecture tools in order to do enterprise transformation more successfully or to have more control over the risks in major programs of change.

That, of course, is a good thing. But what if that fundamental strategic change never happens or succeeds? What if risks are not controlled? What if the enterprise architecture frameworks and enterprise architecture tools they are using, in fact, are only enterprise models and enterprise modeling tools and do not touch architecture? Maybe they are fooled with Enterprise Modeling labeled as Enterprise Architecture?

We all are faced with the upcoming of Robotization for instance. The companies today are human based enterprises, but soon we will have robot based enterprises. For these kinds of enterprise transformation, we really need a quality instrument to accompany that.

This blog is about the difference between enterprise modeling and enterprise architecture.

I will explain that enterprise architecture is about the total concept of the enterprise structure and that enterprise modeling is about creating a simplified version of reality in order to be able to communicate about the enterprise.

In order to be doing enterprise architecture and not with enterprise modeling, you should take into account the difference between the conceptual, logical and physical level of addressing transformation and risk controlling challenges.

Conceptual enterprise modeling would be modeling enterprise architecture (i.e. the conceptual enterprise structure, an arrangement of concepts). Logical enterprise modeling would be modeling the logical enterprise structure (that is the arrangement of elements). Physical enterprise modeling would be modeling the physical enterprise structure (that is the arrangement of components).

Most enterprise architecture frameworks and enterprise architecture tools today support only logical and physical enterprise modeling and not conceptual enterprise modeling.

Flying with a Car

If you expect to realize a goal using a certain instrument or approach, one should also look at successes achieved in the past. Not only believing the vendor or the hired consultants.

A metaphor - Suppose you want to fly from New York to London and the most trustworthy vendor and credible consultant advise you to use a sports car to do that, in most cases you believe them, you buy a car and drive to the airport.

Once there you enter the runway, you take a deep breath and race as fast as you can to reach 300 miles an hour so you can lift off. But guess what happens: you do not lift off.

You may blame the car, the vendor and the consultant. But who you should blame is yourself by not checking the facts: did someone already before me successfully did use this instrument?

Modeling is not enough - Conceptual Modeling though

An Example of Enterprise Architecture

Suppose an organization wants to fundamentally change the way they produce cans of peanut butter. Today they get peanuts from all over the world, ship them to production plants over water, put them in glass jars and ship these jars all over water, over the world to distribution centers for supermarkets.

In the future, a possible scenario is that the farmers turn the peanuts into peanut butter right away themselves and have it put in small bags and ship the peanut butter directly to distributing centers of online ordering websites. In this way, the consumers can buy a more green product and know where it is coming from and directly support farmers.

Now one could model at a logical level the current state and future state of these processes, applications and it infrastructure components. But where does that take you as modeling architect? You will not be able to really change the current state into the future state using the future models as a blueprint for the solutions.

Why not, you might ask? Well, you are not looking at the concepts at the conceptual abstraction level above the logical level. In that conceptual level, there are concepts and principles that enforce the current state to stay in some kind of equilibrium. Many parties in the current state have agreed to work in a certain way and if you want to change things, you need to be aware and address all (or enough) of these forces in your environment.

What you need to do is real Enterprise Architecture, i.e. conceptual enterprise modeling and have a tool that supports you in doing do so.

1. Modeling the Current State Enterprise Architecture or Solution Architecture You should first identify and explore the current business (production) concepts, information (exchange) concepts and technology concepts. And per concept look into how they work and produce results (these are the concepts principles). You must not invent new concepts yourself but look them up in literature.

2. Modeling the Enterprise Strategy or Solution Strategy Next you need to know the strategy (mission, vision, needs, requirements and the issues in the current state). And create a strategy map with it. For the example, it is the Green Production Strategy Map.

Sometimes the strategy reveals concepts (approaches, abstractions of implementation, ideas) like Shared Service Center, Centralization, Digitization, Cloud, Big Data, Customer Intimacy, Mass Customization, Smart Plants. But as an architect, you would want the strategy not to contain these concepts already, but the higher level needs and requirements for these concepts. As an architect, you are supposed to challenge the strategy with architecture (but not be the strategist).

3. Modeling the Future state Enterprise Architecture or Solution Architecture Now you can select the right business concepts, information concepts and technology concepts that enable the strategy. You put can all the concepts together and morph them into a new total concept. In the previous step, I have listed some known concepts. Other concepts everyone knows but hardly ever mentioned as part of architectures are: Business Process Management, Service Orientation, Automization, Transparency, Accountability, 360 client view.

If you take Business Process Management and you look at the principle of business process management, you will notice the elements of which it consists of and the result they produce if all elements are in place and are working together. Also if one element is missing (like ownership of BPM, or performance indicators) the concepts principle will not work.

You as an architect have the job to make sure the concept is implemented at the maturity level and roll out the scale that is needed or required by the strategy. You need to draw sketches and principles details diagram and artist impressions of the total concept, per concept and the corresponding concept principle. If the owner/client and stakeholders are happy with your Conceptual Architecture Design you may enter the next phase.

4. Modeling the Future state enterprise structure or solution structure The Logical Architecture Design is what you are now creating. And that is where the known territory is entered: modeling the elements of the concepts at logical and physical level: things like processes, actors, products, services, applications, databases, networks, clients and servers you may define now and relate with each other.

5. Modeling the Enterprise Transformation or Solution Engineering As an architect you are designer of total concepts (=architecture) and supervisor of the engineering or realization of the structures using the architecture. You need to help the programs and projects by defining roadmaps for the phases, milestones and deliverables they should be targeting at.

Also remember not only to put Design Concepts and Design Principles in your Architecture Design, but also to put Realization Concepts and Realization Principles. For instance: you need to tell the engineers or project workers how to design in detail or to build solutions and structures (using guidelines, rules and standards).

If you do all the above you will for sure realize successes in fundamentally change an organization or be able to contribute to managing risks in major programs of change.

Also every step you take and every picture you make is with and for owner/clients and stakeholders. They need to approve your choices mentally and financially before you can detail your design or use it when realizing a structure.

There is nothing wrong with only logical enterprise modeling

Logical enterprise modeling, administering the products, processes, applications, clients, servers and networks in your organizations, is a wise thing to do. You can create a common overview for stakeholders. If you administer the relationships between the entities you can also do a lot of impact-of-change analyses.

What you cannot do with logical enterprise modeling is to change fundamentally change the organization, doing enterprise transformation with it, or manage risks in majors programs of change. This is because the concepts and principles ( that the entities at a logical level are part of) are not changed or modeled. You are working at another level.

To make an analogy: whatever the people at tactical management level do, at the strategic level of the organization nothing will ever change.

Sometimes, of course, there is a success. But that often has to do with experienced lead architects leaving behind the enterprise architecture method, frameworks and tools. From their natural behavior, they start looking at the higher level business concepts and IT concepts of the organization, exploring the principles (the way concepts work and produce results) of the concepts and do a projection of the principles on the current situation of the organization. And with projects, the missing elements and components are implemented to make the concept principles really work.

Conclusions and Recommendations

A lot of enterprise architecture tools are only logical enterprise modeling tools. They do not support conceptual modeling (that is modeling the relationships and fundamentals of enterprises, chains, architectures, concepts, environments, elements, components, principles and phenomena).

These tools do support modeling products, services, processes, applications, etc... In fact they often only allow you to create their predefined enterprise architecture, using their framework.

Modeling your enterprise at a logical level is a wise thing to do. It saves you time, money, and in the end increasing the enterprise performance and quality.

But if you want to fundamentally change your organization, to do some serious enterprise transformation or manage risks in major programs of change. You really need a real Enterprise Architecture Tool and Enterprise Architecture Framework.

So what I recommend everyone is: write down your expectations, goals and objectives you want to realize with an Enterprise Architecture Tool and Enterprise Architecture Framework before buying or start using one.