Document Enterprise Architecture using Conceptual Modeling

Every organization is confronted with fundamental strategic changes

Enterprise Architecture is a management instrument you can use to manage and control fundamental strategic changes or enterprise transformation. And when I say fundamental strategic changes, I mean:

1. Robotization of the production processes
2. The shift from people on the payroll to working only contract workers
3. Switching from fossil fuel to green energy in your company
4. Digitalization of information
5. Cloud Computing and Big Data
6. Mass Customization
7. Switching from Brick and Mortar to 100% digital company
8. Becoming a Smart Company: making optimal use of new technology
9. 3d printing and nanotechnology.
10. The self-driving internet-aware car

The other way around, I suggest using enterprise architecture only for fundamental strategic changes and use Enterprise Modeling for less drastic changes.

But to be able to control these kinds of enterprise transformations with enterprise architecture, you first must know what your current state (as-is) architecture is before you can argue or justify a future state architecture.

In this blog, I will present to you some key Enterprise Architecture overviews that can be created by any enterprise architect for any organization. I am using the Dragon1 open Enterprise Architecture Method and Dragon1 Enterprise Architecture Tool to create the visualizations because they best serve this activity.

Some people think enterprise architecture is a synonym for documentation, but that is untrue. Enterprise architecture is always present, even if you do not document it. Enterprise Architecture is the Total Enterprise Concept applied to the Enterprise Structure. You need to model and document the enterprise architecture (the total enterprise concept) to gain control over it. To enable everyone to document their enterprise architecture, I wrote this blog.

If you want to read about Enterprise Architecture as a Bridge between Enterprise Strategy and Enterprise Transformation, you can take a look here.

Architecture is about translating Function into Form

Everyone knows that (physical and digital/enterprise) architecture is about translating from function to form. There are even architects who say that form must follow function. In enterprise architecture, things are not that different from building architecture.

In building architecture, a building needs to serve certain functions with certain capabilities for its owner/client and stakeholder's needs and requirements. For instance, a hospital needs to serve functions like research, cure, and care, with the capabilities of 1000 patients per day, 5000 car parking per day, and 3000 supplier deliveries per day, for stakeholders like the patients, public, government, hospital board of directors and pharmaceuticals.

Building architects consider these things, so they design a hospital structure containing a big, smart, efficient parking lot, restaurant areas, cozy bedrooms, etc... for the modern stakeholders 'requirements. The building architecture contains concepts like Green and Hybrid Parking, Food Ordering Points, Intelligent Bedrooms, and Robotic Room Cleaning.

Hospitals are a good subject because they have building and enterprise architecture.

Suppose your stakeholders need to save money on food in the hospital. They may come up with a requirement that suppliers keep control of overstocks. in that case, an enterprise architect can choose the concept eProcurement for the business function Purchasing.

Important to mention is that a functions model is not part of the architecture, as architecture is a total concept of a structure where every concept can or should be (able to be) projected onto a function.

First your Structures then your Architectures

Stop, wait a minute. Now, let us do things right. Before you start creating architecture, you must know what structure your architecture applies to. You also need to know what substructures or systems your structure consists of.

Your organization may be unique for its combination of structures, so make sure the owner/client and stakeholders of your organization recognize the organization by its structure model.

The following figure shows a simple overview of common structures within the enterprise structure. Note: Make sure you put up definitions of everything you use in a model.

An Architecture per Structure

Now, you need to define an architecture per structure. Also, it could be your work with solution architecture. Solutions are slices of enterprise architecture, so each solution architecture contains the same sub-architectures as the enterprise architecture.

Your Enterprise Architecture Framework may look something like this:

Do not forget to define what you mean with every architecture you recognize and who is the owner of it. Also, it could be that if you have more than one IT Infrastructure, you also have more than one technical architecture (technical total concept) or IT architecture.

Enterprise Functions Model

As we said before, an architect needs to translate functions into forms (in enterprise architecture, that means concepts). So, we must create a current and future state enterprise functions model. We do that by interviewing the stakeholders and doing some desk research.

Below is an example enterprise functions model.

Maybe in your discipline, an enterprise functions reference model exists (= not equal to reference architecture) for your type of organization. Be sure to use it wisely.

Enterprise Concepts Model (as Reference Architecture)

Before you, as an architect, can project concepts onto functions, you must have a set of concepts to choose from. This Concepts Overview is what you can use for that. You might even call it a Reference Architecture when you can refer to successful usage of the concept in other organizations.

Enterprise Stakeholders Needs and Requirements

So now you have a possible set of concepts to choose from, but you do not know if they are necessary for the enterprise. To know that, you must have an overview and insights into the enterprise strategy. You can view that as the set of needs and requirements of the enterprise stakeholders. If unclear, you must interview stakeholders for more detailed needs and requirements.

Enterprise Concepts/Functions model

Suppose you have done your job correctly. You could select one or more concepts per need or requirement for a function. It is wise to create a diagram where you can project those concepts onto functions.

Tip: you can select concepts at best by looking at their principle (the way it works producing results) and matching these with the requirements and needs of the stakeholders. First, of course, needs, then requirements, then concepts. Normally, your stakeholders do not know or name the concepts. They say what is required.

Below is an example projection:

And, of course, you can create current state and future state versions of these models.

Dragon1 open EA Method and definitions

Here, we provide the most important definitions for concepts as part of the Dragon1 open EA method (wiki.dragon1.org). It would be best if you documented your Enterprise Architecture with conceptual modeling as well.

• A principle is the enforced way an entity or a system works, producing results. Principles are about the communication of knowledge.
• A concept is an idea, an abstraction of an implementation, an approach. The concept principles are principles that are about the way concepts work.
• A structure is a (3-dimensional) arrangement of elements and components in a construction or framework. Within enterprise architecture, we deal with the enterprise structure.
• An architecture of a structure is a special total concept of a structure. i.e., a coherent total concept with constructive, operative, and decorative concepts. An architecture always contains design concepts and their principles and realization concepts and their principles to be complete. The architecture principles are the concept principles that are valid throughout the structure.
• An architect is a designer of total concepts and supervises or guides the realization of structures compliant with that total concept. He is not an advisor, consultant, or standards agency! An architect is the moderator of a program of requirements. The program of requirements always contains a functional model of what is requested. Requirements are NOT part of the architecture. An architect always creates designs (even at a high level) using the architecture (total concept). The functional model from the Program of Requirements is used as background and translated/transformed into a conceptual, logical, physical, and implementational model by the architect.
• An owner/client is the person, group, or organization (recognized by law) having control over a structure and the changes to that structure. An owner/client gives an architect an architecture design assignment. The owner/Client often holds the budget and mandates rights and control.
• A stakeholder is a person, group, or organization with an interest in the well-being of a structure. A stakeholder provides an architect with input (strategy, needs, and requirements).
• A function is the task a structure has. It is a group of activities sharing the same goals or objectives. A function is a purpose natural to or intended for a person, system, thing, or organization. Every structure can be decomposed into its functions. Concepts implement the wanted behavior, performance, and quality of functions.
• A need is a thing that is necessary for an organism or organization to live a healthy life or to have a profitable existence. Stakeholders have needs.
• A requirement is a need that a particular design, product, or process must be able to perform. An architect selects concepts based on the needs and requirements of stakeholders. The owner/client gives the GO / NO GO.
• An ability is the possession of the means, talent, and skills to do something, like a task or an activity, on your own. An organization can often sell products on its own (but maybe not anytime, anywhere, and constantly). Ability usually is about a quality aspect and is not frequently performance-specific (SMART).
• A capability is the extended ability to do something, like a task or an activity (with the help of others). Distributors can make an organization capable (enabling) of selling any product anytime (any second, constantly), anyplace on earth. A capability is not often about a quality aspect and is often performance-specific (SMART). Are you capable of selling your product to anyone?
• A disability is the lack of the possession of the means, talent, and skills to do something, like a task or an activity (you can’t do it either way). Any organization today has a disability in selling products in outer space because of a lack of infrastructure and facilities. No organization can do it on its own or with the help of distributors.
• A core activity is an activity in which you are specialized, unique, and of utmost competition in the market. Usually, a core activity is an ability (doing it all on your own) and not a capability (needing to use suppliers).

Concepts Maturity and Roll-Out Scale

Dragon1 open EA method and the Dragon1 Software allows users to document the maturity and roll out the scale of a concept or principle and other entity classes like 'ability', 'capability', and 'rules'.

Dragon1 aligns with common levels for maturity:

1. Initial (chaotic, ad hoc, individual heroics) - the starting point for using a new or undocumented repeated concept.
2. Repeatable - the concept is at least documented sufficiently, so repeating the same steps may be attempted.
3. Defined - the concept is defined/confirmed as a standard business concept.
4. Managed - the concept is quantitatively managed following agreed-upon metrics.
5. Optimizing - concept management includes deliberate concept optimization/improvement.

To indicate the maturity of an entity class (like a concept), you use (m=..). Where you will fill in the level on the dots. You can see an example of this in the EA Concepts overview above.

Also, Dragon1 defines the roll-out scale. The roll-out scale says how much percentage of an area complies with a certain maturity level (for instance, the concept of service orientation is at maturity level 3 but only for 50% of the applications). The Roll-out scale is documented with (s=..%). Where you fill in the percentage on the dots. Normally, you would both indicate the maturity level and roll-out scale and also if it is unknown (m=?) and (s=?%).

A visualization rule in Dragon1 is that if the planned level of maturity of the roll-out scale is not equal to the current level, the shape is colored red. Likewise, with orange and green (planned is equal to current).

Conclusions and Recommendations

In this blog, I have shown that with a set of five diagrams, you can easily model and document a usable overview of enterprise architecture at a high level. Why should you document your Enterprise Architecture (current state and future state)? It's pretty simple: to control fundamental strategic changes better. We use conceptual modeling as provided by the Dragon1 open EA Method. We have used the Dragon1 Enterprise Architecture Tool to create a consistent and manageable set of diagrams.

I can advise everyone to use Dragon1 as an EA Tool and EA Method to document their Enterprise Architecture relatively quickly. You can do it alone or with a team. Every stakeholder in your organization will appreciate it and use the diagrams to support their strategic decision-making or do compliance reviews (for standards) and impact analysis with it.

Our next stop is to detail every concept in its elements (logical functional entities) and define its principles. Stay tuned for the blog about Solution Architecture, where I will dive into concepts, principles, elements, and components.