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 are faced with the upcoming Robotization for instance. The companies today 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 be able to communicate about the enterprise.
To be doing enterprise architecture and not with enterprise modeling, you should take into account 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 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.
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 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 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 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 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, 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 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 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 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 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. 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, Automation, Transparency, Accountability, and 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 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 concept's principle will not work.
You as an architect have the job of making sure the concept is implemented at the maturity level and rolling out the scale that is needed or required by the strategy. You need to draw sketches, principles detail diagrams, 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. 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 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 success in fundamentally changing 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 fundamentally change the organization, do enterprise transformation with it, or manage risks in major 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 the 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. With projects, the missing elements and components are implemented to make the concept principles 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... 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 fundamentally change your organization, do some serious enterprise transformation, or manage risks in major programs of change. You 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 starting using one.