Active Knowledge Modeling

I was recently invited to the second  Practice of Enterprise Modeling (PoEM) conference, in Stockholm, 18-19 November. This post introduces the topics that I will talk about there. The objective is to communicate some of our lessons from 15-20 years of enterprise modeling and enterprise architecture development, to highlight advances made, important ideas that were largely forgotten, and to point out directions for future practice development. Some of the lessons presented below are obvious to enterprise modeling practitioners. They are included here because outsiders coming into the field sometimes get them wrong. Other lessons may be more controversial, and they may not be applicable in every situation.

The proceedings of the conference are available from Springer Lecture Notes in Business Information Processing. The presentation is available here (pptx). 

The Context of Enterprise Modeling

Over the last 25 years, enterprise modeling has evolved from a loose collection of business oriented modeling practices to comprehensive frameworks for enterprise architectures. What was initially a combination of industrial and software engineering methodologies applied to enterprise design and development, is today dominated by the concerns of IT development, management and governance.

Enterprise modeling brings together a wide range of practices:

• Enterprise architecture and IT governance
• Business process management
• Product design and engineering, manufacturing
• Quality management
• Project management
• Organizational learning, organizational development, knowledge management
• Software development, requirements engineering
• Interoperability
• Conceptual data modeling
• Visualization
• Service-oriented architectures
• Collaboration and groupware
• Model-driven applications and portals
• Domain specific modeling and metamodeling

PoEM focuses on practical modeling experiences rather than theoretical frameworks within each of these disciplines. From communities of practice we learn that innovation often occurs at the boundaries and intersections, so this is a fertile ground for innovation in business and user-centered modeling.

Lessons Learned – Scope and Focus

First, let us look at four lessons that concern the scope of enterprise modeling and enterprise architecture:

1.      Don’t reduce enterprise architecture to IT architecture.
2.      “What can we automate” is not always the right question.
3.      Don’t frame business problems as IT problems.
4.      Discuss purpose, scope and level of ambition throughout the architecture’s lifecycle

Some companies that provide enterprise application integration (EAI) describe their IT level integration platforms as enterprise architectures, and the people who develop them as enterprise architects. There is a clear danger that EA will go the same way as “business process”, and be hi-jacked from the business domain to the IT domain. IT architectures are more tangible than business architectures, and to most developers, architecture means diagrams like this:

A typical architecture diagram from a software engineering perspective

The 2nd lesson deals with the scope of enterprise models. When applied in requirements analysis, enterprise models too often describe just the internal processes and structure of the envisioned IT support, and the scope of the model is aligned with the automation boundary. Enterprise architectures should bring together business and IT architectures, and be utilized for organizational design and problem solving as well as IT development.

The 3rd lesson can be illustrated with the problem of interoperability. Interoperability is generally framed as a data integration problem, and the techniques proposed help you map data from different sources in order to translate between incompatible formats. Sometimes a common format such as a standard is applied, and semantic research is concerned with developing more “intelligent” techniques for data manipulation. The root of the interoperability problem, however, is found on the business level. Different disciplines, functions, and companies have developed different terminologies and conceptual frameworks that fit their own local practices. In order to solve interoperability problems, we need to perform a thorough analysis of their work practices, with significant participation by users. Enterprise modeling frameworks that tolerate ambiguity, inconsistency, and incompleteness is a much better fit for these social realities than the precise mathematical notations of the semantic web.

Another common symptom of lesson 3 is the practice of blaming the technology when something goes wrong, even when the reasons for the failure are human, social, or business-driven. This is a commonly reported problem in knowledge management and collaboration tools, where the availability of knowledge sharing tools is irrelevant if the business culture does not reward sharing.

Lessons Learned – Modeling Practice

In the overall practice of enterprise modeling, these lessons should be highlighted:

5.      Don’t confuse analysis and design.
6.      Keep models and languages as simple as possible.
7.      Don’t let the language be a straight-jacket.

Enterprise modeling is used for analyzing the current situation, and for designing future solutions to identified problems, as in to-be business processes and architectures. Analysis should focus on identifying the most important elements, dependencies and aspects of a domain. Often however, people perform a lot of synthesis during analysis, constructing complex structures of the elements, such as business processes and organizational hierarchies. Too much structuration during analysis is dangerous because the model will contain a lot of noise, e.g. non-essential relationships for completing the business process, alongside the critical dependencies that need to be taken into account when designing a solution. It also makes the approach more conservative, as relationships included in a representation of the current situation often are carried over into the future design.

This leads on to the 6^th principle, simplicity. The experience of enterprise modeling can be quite alluring to business professionals, and often models will end up including a lot of details not strictly necessary for the analysis and design activities they are too support. In order to improve stakeholder involvement, the architect may choose to include all kinds of details in the models. The activity of model pruning, of cutting out dead-ends and infertile branches, should not be forgotten. This is especially important for the central architecture views. A common condition is analysis paralysis, where decision making is continuously postponed in order to create a better foundation and justification.

Enterprise modeling research also tends to violate the simplicity requirement.  Countless papers are produced with extensions of modeling languages in order to more precisely represent some additional aspect. Often the added value is small, as the most important concerns could already be represented in existing languages. The cost in terms of increased complexity, on the other hand, is large. Validation that takes this issue into account is rare.

When we tried to develop a common language for interoperability across enterprise modeling tools, we experienced some of these issues. One example was the modeling of decision making, which was at the core of some modeling languages, but peripheral to others. In order to incorporate decision making in the common language, we needed to represent concepts like decision making process, decision authority and responsibility, decision dependencies, decision decomposition, alternatives etc. In the languages that did not emphasize decision making, these elements would be represented by more general constructs for process, role, relationship, information structures etc. The straightforward approach would be to add subtypes for all the decision making concepts to the existing general enterprise modeling concepts. Instead, we defined a single “decision making” type that could be applied to most constructs in addition to their core type, using multiple classification. A decision role would thus be members of both the decision making and the role types, and a decision making process of both the process and decision making types, etc. By separating these aspects, we greatly simplified the common language, and made it easier to implement model interchange. Now the tools that did not specialize in decision making could simply ignore that classification. In general, we have found aspect orientation and modeling of properties that can be dynamically attached to instances, superior to the conventional object-class-oriented method in terms of simplicity, flexibility and interoperability.

Lessons Learned – Model Structures 

During modeling we have experienced a few common challenges:

8.      Beware of hierarchies, they are often local to a viewpoint and not shared by everyone.
9.      Beware of matrices and streamlined frameworks, often you need to break the system.
10.   Beware of leaving important things out at the boundaries.
11.   Don’t confuse views with the underlying architecture elements.

Multiple, aspect oriented classification of model elements is important in order to allow overlapping hierarchies and multiple views for different stakeholders’ perspectives. In the model below, we show 10 different classification structures that an Equipment object is located in during engineering of an oil platform. This is just an excerpt, there are even more perspectives. Different roles (triangles) perform different activities in relation to the equipment element, and categorize it differently according to their needs. There is thus no single “correct” way of defining the element. For procurement, the important thing is the lead time from order to delivery of the equipment, while for process engineering it is the system and what flows through the equipment (e.g. oil, gas or water) that is important. For the piping discipline the location of the equipment inside an area structure is most critical, while the yard is concerned about when and how the equipment is to be hooked up to surrounding pipes, control system etc. To interoperate, these roles need to agree on the identity of the equipment, but not its type or class. Classification-oriented approaches to industrial ontologies should thus be questioned.

Different roles categorise the same element differently

Lessons Learned – Model Content

With respect to the enterprise model content, we often found that

12.   Product models are more important and fundamental than process models.
13.   Processes are better understood by focusing on the decisions to make, the issues to solve, and the results to produce, than on the administrative ordering of steps (cf. project and case management).
14.   Multi-dimensional analysis, combining e.g. processes with the data it manipulates and the organizational roles responsible, is superior to single-dimensional data modeling and business process modeling.
15.   During decomposition, don’t expect to “go all the way down” using a single modeling language. Another language is likely to be a better match for detailed models than the one used for high-level overviews.
16.   Aspects that can be separated on one level of detail may be inherently woven together on another level. Products, processes and organization models do for instance become thoroughly intertwined in work execution.
17.   Relationships are the most important kind of element in most models.

For managing dependencies, relationships should be modeled at the right level of detail. If every element is related to every other element, you’re at a too high level of abstraction. If there is a clear one-to-one correspondence between two sets of elements, you have probably included too much detail.

Below we have tried to illustrate lessons 9, 13-16. The triangle illustrates the work breakdown structure of processes to subprocesses in an engineering project. The enterprise in question first divides the project into phases and stages (time), and into main engineering disciplines (organization), in a matrix structure as illustrated on the top right. For a given organizational role in a given project stage, a process model defines the activities and their interdependencies. However, for detailed monitoring, management and coordination, the activities of the process model are broken down further according to the product structures, so that the activity “3D design of piping” in the process model is decomposed first into separate activities for each area in the plant (cf. the multi-dimensional classification structure above), and then further into individual tasks for the design of each pipe in each area.

Different aspects controlling the work breakdown structure on different levels

In a previous post, we discussed how the product structures are more important than the process models for coordinating this work. Dependencies between product elements, like the connection between a pipe and a pump, lead to dependencies between the activities that deal with the pipe and the pump. In the early phases of conceptual design, the product structures are not yet fully defined, and the engineers work with documents more than structured product models. In this case it is the information structure of documents that defines the low-level tasks and their interdependencies.

Lessons Learned – Conduct

Finally, here is some advice for how an architect should behave:

18.   Be open, humble, and willing to expose your mistakes.
19.   Take charge, set directions.
20.   Don’t listen to management.
21.   An architecture that is not actively used will die. Motivating stakeholders to participate, is an ongoing challenge.

Some architects treat the architecture as their own property, and see organizational stakeholders primarily as sources of information. Other inexperienced architects see themselves too much as enablers, and become followers of the whims of strong forces in the organization. Managers are of course important stakeholders, and generally also important sources of information for an architecture. We should however be cautious, as relying to one-sided on management perspectives can make it difficult to capture the concerns of the core, value-adding work performance. A typical result is business process models that include several activities for administration, planning, monitoring, reporting, reviewing, quality control, setting up, and closing etc., but very few details about how the actual work is to be performed. Management views should be complemented by operational views.

Future Directions

In the short term, the future development of enterprise modeling practice is likely to remain dominated by enterprise architectures for IT management. In this area, standardization of modeling languages is beginning, e.g. BPMN, and it will probably be a major trend in the next five years. Compared to e.g. UML, enterprise modeling deals with a much larger scope of content, and aims to support a much larger set of practices. Standardization will be more difficult in this domain. Whether any single dominant vendor will emerge with a strong enough position to establish a de facto industry standard, is difficult to tell. If we end up relying on a poorly suited metamodeling framework from another domain, such as UML/MOF, the complexity of even a limited general purpose enterprise modeling language may prevent its use in practice.

Over the past decade, more and more EA frameworks have been proposed, often targeting different industries and application areas. Most proposals position themselves with reference to general purpose frameworks such as Zachman and TOGAF, but further alignment is hampered by the great complexity. A simplified TOGAF core should probably be established as a first step towards a consolidated, extensible standard EA framework, capable of supporting domain specific extensions. The core framework should include the definition of standard modeling concepts, but it is difficult to predict whether the framework or the language standard will arrive first.

Industrial design and development is in need of a language for capturing and sharing knowledge throughout the entire product lifecycle. While interoperability is becoming a reality between the tools used in the later stages of product development, conceptual and functional systems design is still not integrated. In these early stages, documents, rather than structured data/models, are still dominating. To develop enterprise modeling languages for conceptual and functional design is thus a major challenge for future research.

Finally, we see enterprise model driven applications as a promising approach to construct more customizable, agile, modular and service-oriented IT solutions. Pilot solutions applying what we call “active knowledge architectures” (AKA) show that applications can indeed be put together from simple building blocks, using high level enterprise models. AKA execution environments combine

• Model-driven data definition and management,
• Model-driven process, task, and rule execution,
• Model-driven views and user interfaces,
• Model-driven role-based filtering and access control.

From this perspective, standard enterprise modeling languages should be aligned with industry standards for data exchange. More information about our ideas for future modeling approaches and model-driven applications is found in the other posts on this blog.