Are You Waiting for Fundamental Strategic Changes that Never Happen?
Many organizations today start using enterprise architecture frameworks and enterprise architecture tools 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 are only enterprise models and enterprise modeling tools and do not touch architecture? Maybe they are fooled by Enterprise Modeling labeled as Enterprise Architecture?
We all face the upcoming Robotization, for instance. Today's companies are human-based enterprises, but soon we will have robot-based enterprises. For these kinds of enterprise transformations, we need a quality instrument to accompany them.
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 to communicate about the enterprise.
To be doing enterprise architecture and not with enterprise modeling, you should consider the difference between the conceptual, logical, and physical levels 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 model the logical enterprise structure (the arrangement of elements). Physical enterprise modeling would be modeling the physical enterprise structure (the arrangement of components).
Most enterprise architecture frameworks and tools today support only logical and physical enterprise modeling, not conceptual enterprise modeling.
Architecture Metaphor: Flying with a Car
If you expect to realize a goal using a certain instrument or approach, you 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, so you buy a car and drive to the airport.
Once there, you enter the runway, take a deep breath, and race as fast as possible to reach 300 miles an hour to 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 for not checking the facts: did someone already before me successfully use this instrument?
Modeling is not enough - Conceptual Modeling though
An Example of Enterprise Architecture
Suppose an organization wants to change how they produce peanut butter cans fundamentally. 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 the 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, put it in small bags, and ship it directly to online ordering websites' distribution centers. This way, consumers can buy more green products, know where they come 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 a modeling architect? You will not be able to 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. At that conceptual level, some concepts and principles enforce the current state to stay in 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 genuine Enterprise Architecture, i.e., conceptual enterprise modeling, and have a tool that supports you in doing 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. Per concept, look into how they work and produce results (these are the concept's 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 example, it is the Green Production Strategy Map.
Sometimes the strategy reveals concepts (approaches, abstractions of implementation, ideas) like Shared Service Centers, Centralization, Digitalization, Cloud, Big Data, Customer Intimacy, Mass Customization, and Smart Plants. However, 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, information, and technology concepts that enable the strategy. You can combine all the concepts 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, Automation, Transparency, Accountability, and 360 client view.
If you take Business Process Management and look at the principle of business process management, you will notice the elements of which it consists and the result they produce if all elements are in place and working together. Also, if one element is missing (like ownership of BPM or performance indicators), the concept's principle will not work.
You, as an architect, make sure the concept is implemented at the maturity level and roll out the scale that is needed or required by the strategy. It would be best to draw sketches, principles, detail diagrams, and artist impressions of the total concept, per concept, and the corresponding concept principle. You may enter the next phase if the owner/client and stakeholders are happy with your Conceptual Architecture Design.
4. Modeling the Future State enterprise structure or solution structure The Logical Architecture Design is what you create now. That is where the known territory is entered: modeling the elements of the concepts at the 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 the 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 must tell the engineers or project workers how to design in detail or build solutions and structures (using guidelines, rules, and standards).
If you do all the above, you will for sure realize success in fundamentally changing an organization or be able to contribute to managing risks in major programs of change.
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 wise. 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 change the organization fundamentally, do enterprise transformation with it, or manage risks in significant change programs. 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 the tactical management level do, at the strategic level of the organization, nothing will ever change.
Sometimes, of course, there is a success. However, that often concerns experienced lead architects leaving behind the enterprise architecture method, frameworks, and tools. From their natural behavior, they start looking at the organization's higher-level business concepts and IT concepts, exploring the principles (the way concepts work and produce results) of the concepts, and making a projection of the principles on the organization's current situation. The missing elements and components are implemented with projects to make the concept principles work.
Conclusions and Recommendations
Many 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 support modeling products, services, processes, applications, etc... 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 and money and, in the end, increases the enterprise performance and quality.
But if you want to change your organization fundamentally, do some severe enterprise transformation or manage risks in significant programs of change. It would be best if you had a real Enterprise Architecture Tool and Enterprise Architecture Framework.
So I recommend everyone: write down your expectations, goals, and objectives you want to realize with an Enterprise Architecture Tool and Enterprise Architecture Framework before buying or starting using one.