Document Your Enterprise Architecture using Conceptual Modeling

woensdag 16 december 2015 | Likes: 0 | Comments: 0

Mark Paauwe

VP Product Development

Dragon1 Inc

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 work only contract workers
  3. Switching from fossil fuel to green energy in your company
  4. Digitization 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 nano technology.
  10. The self-driving internet aware car

The other way around I suggest to use enterprise architecture only for fundamental strategic changes and use enterprise modeling for less drastic changes.

But in order to be able to control these kind 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 that enterprise architecture is synonym to documentation, but that is not true. Enterprise architecture is always present, even if you do not document it. Enterprise Architecture is the Total Enterprise Concept applied onto the Enterprise Structure. You need to model and document the enterprise architecture (the total enterprise concept) in order 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 Bridge between Enterprise Strategy and Enterprise Transformation you can take look here.

Architecture is about translating Function into Form

Everyone know that (physical and digital/enterprise) architecture is about the translation from function to form. There are even architects that say that form must follow function. In the world of enterprise architecture things are not that different from building architecture.

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

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

Hospitals are a good subject because they both have building architecture 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 over stocks. 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 with creating architecture, you first need to know onto what structure your architecture applies. And you need to know what sub structures or systems your structure consists of.

Your organization is maybe 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. P.S. 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 the field of enterprise architecture that means concepts). So we need to create a current state and a future state enterprise functions model. We do that by interview the stakeholders and doing some desk research.

Below is an example enterprise functions model.

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

Enterprise Concepts Model (as Reference Architecture)

Now before you as architect can project concepts onto functions, you of course need to 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 a 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 of the enterprise strategy. You can view that as the set of needs and requirements of the enterprise stakeholders. And if it is not clear enough you must interview stakeholders for more detailed needs and requirements.

Enterprise Concepts/Functions model

Suppose you have done your job correctly. Per need or requirement for a function, you were able to select one or more concepts. 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 match these with requirements and needs of the stakeholders. First of course needs, then requirements, then concepts. And normally your stakeholders do not know of 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). You need to document 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 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 to 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 only high level) using the architecture (total concept). The functional model from the Program of Requirements is used as background and is translated / transformed into a conceptual model, logical model, physical model 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 architecture design assignments. Owner/Client often holds the budget and mandate 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 the 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 need and requirements of stakeholders. The owner/client gives the GO / NO GO.
  • An ability is the possession of the means, talent, skills to do something, like a task or an activity, on your own. An organization is often able to sell products on their own on earth (but maybe not anytime, anyplace and constantly). Ability often is about a quality-aspect and not often 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 products anytime (any second, constantly) anyplace on earth. Capability is not often is about a quality-aspect and often performance-specific (SMART). Are you capable of selling your product to anyone?
  • A disability is the lacking of the possession of the means, talent, skills to do something, like a task or an activity (you can’t do it either way). Any organization today has a disability of selling products in outer space because of lack of infrastructure and facilities. No organization can do it on their own or with the help of distributors.
  • A core activity is an activity in which you are specialized, unique in and utmost competitive for in the market. Normally 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 provides users with the ability to document the maturity and roll out 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 use of a new or undocumented repeated concept.
  2. Repeatable - the concept is at least documented sufficiently such that 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 in accordance with agreed-upon metrics.
  5. Optimizing - concept management includes deliberate concept optimization/improvement.

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

Also Dragon1 defines the roll-out scale. Roll-out scale says how much percentage of an area is compliant to a certain maturity level (for instance the concept of service orientation is at maturity level 3 but only for 50% of the applications). 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 its is unknown (m=?) and (s=?%).

A visualization rule in Dragon1 is, that if the planned level of maturity of 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 at high level a usable overview of enterprise architecture. Why should you document your Enterprise Architecture (current state and future state)? Pretty simple: to be able to control fundamental strategic changes better. What we use here is conceptual modeling as provided by the Dragon1 open EA Method. And 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 EA Tool and EA Method to document their Enterprise Architecture in a relatively short period of time. You can do it alone or with a team. Every stakeholder in your organization will appreciate it and will make use of 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 their principles. Stay tuned for the blog about Solution Architecture where I am diving into concepts, principles, elements and components.