Model-Based Business Engineering - A Positioning
How do we understand Model-Based Business Engineering? The document formulates some basic positions for further discussion.
1 Model-Based Business Engineering
Models are omnipresent. They serve as base for building, analyzing, optimizing Business Processes, Business Decisions, IT Systems and much more. Models support many working techniques in Business Analysis. How can we expect good results for all this, if the base is already wrong, ambiguous, not sufficient or just not readable? How can we develop Business Processes or organizations systematically and for long term use if we have no knowledge about the relevant views?
Despite modeling often don’t get the needed attention. Questions as “Are you still drawing pictures, or do you manage already?” are raised. The need for professional and efficient model development is not recognized. Often a wrong understanding of models and missing methods are the reasons for this. The document describes our understanding of Model-Based Business Engineering. Further documents will explain more details and some typical techniques.
Business Modeling is not Business Management. But without models, it is not possible to manage your business.
On the other end of the spectrum, we find self-appointed gurus promoting a single concept or notations as the silver bullet. Individual model elements or special improvements of standard notations are discussed vehemently. Model-Based Business Engineering sees (standard) notations as an essential mean. Which notations and concepts are best suited depends on the model subject, our goals, and the involved stakeholders. Notations alone don’t help. Singular concepts bring only isolated improvements. We need multiple views for a successful business change. A good method is important.
Model development got a bad reputation in some business areas over time. Too expensive, not goal-oriented enough, key stakeholders not addressed, unsystematically, not maintainable are some of the arguments. The root cause is a non-systematic and unplanned approach. That’s why we emphasize the “engineering” part of the definition of Model-Based Business Engineering. Models need to be developed in a goal-oriented, planned, and repeatable way. We use proven techniques, learn from other disciplines, and apply soft-skills to ensure involvement of the stakeholders.
2 Model-Based ...
We talk of Model-Based Business Engineering, not of Model-Driven Development. Models are needed for many working techniques in the scope of Business Process Management. But they are “only” an essential mean to an end. The business problem “We don’t have enough models.” doesn’t exist.
2.1 Why models?
A model describes a „thing“ before we build or change it. They help us to measure properties of the subject of interest. The “thing” or better the subject of interest is a system or a process or a business capability or an entire organization. “If you can’t describe it, you can’t build it.” arguments John Zachman. I would add, you can’t maintain it too.
Describing the subject of interest gives us the opportunity to think and decide which properties it should have. The model contains not only pure information about the subject itself. It also contains information about design decisions, knowledge sources, and other relevant secondary information.
Models are base for the definition and realization of Business Processes and other organizational aspects. They are especially base for maintaining and ongoing development of these assets over a long period. This implies that the models need to be maintained and governed over the lifecycle of the object to keep model and reality in sync. Else the effort to create models is not justified.
2.2 What is a Model?
Customers or workshop attendees tell me sometimes that they don’t use models. I’m sure that they do. They just mean they don’t use formal models. Formal models have very different forms and contents. Everybody is using some kind of model.
A model is an abstract description of a subject of interest. We highlight some properties of the subject. Which properties we want to show depends on the subject, but even more on the stakeholders' interest addressed.
Models describe a few properties of the model subject, e.g., the flow of a Business Process. Models describe complex relationships between single elements of the model elements, too. E.g., a model of a Business Capability showing different aspects of the Capability in context.
Models come in different forms. Not all models are formal models. Not all models are visual models. A table or a textual description can be a model. It is important to keep proven and successful descriptions of an organization. Existing descriptions or description forms should be enhanced, combining them with new formal notations.
2.3 Presenting Models
2.3.1 Formal Notations
We think about the visual standard notations of the Object Management Group (OMG) as Business Process Model and Notation (BPMN) or Decision Model and Notation (DMN) first when talking about formal models. Visual notations are the preferred form today. Many tools support the OMG notations.
The advantage of formal model standards is that they define not only a notation but also a standardized exchange format. These exchange formats allow the transfer of models between different modeling tools but also between the modeling environment and other environments, e.g., for simulation or reporting and evaluation.
It is easier to conceive and understand a visual model. But a model is much more than a picture. The visual information is never complete. Much information about the model elements is hidden behind the picture captured and stored in our model repository. The standard notations define a set of attributes for each element. We can and should extend these attribute sets with additional properties we need for our intention. The visualization shows one particular aspect of the subject of interest. The picture shows us this aspect and helps us to navigate and find other relevant information easily.
The description of the model elements contains more than the intrinsic attributes of the subject of interest (primary model content). It also includes information about design decisions, assumptions, restrictions, or knowledge sources (secondary model content).
2.3.2 Informal Presentations
Many informal presentation forms exist in addition to the standard notations. On one hand, they are often easier to use. At the same time, they lack tool support. Examples for such informal presentations are the “North Star Concept” by Roger Burlton of Process Renewal Group or the “Business Model Canvas” by Alexander Osterwalder. We find such presentations mostly on higher levels of abstraction. As with the standard model notations, the visual (core) part is not very expressive and will be completed by other (secondary) information.
Language is important in all types of model presentation. Models are used to communicate between humans. Models are created from language. It should be possible to translate it back to language. For the visual part of the model, we define naming conventions. The detailed description of the elements always contains textual parts. The secondary information uses mainly language information.
Language offers a large degree of freedom to formulate. To avoid ambiguity and misunderstanding, regulated language specification is used. We specify which content should be included. We give guidelines on how to formulate and present information. E.g., we specify a table format and ask for specific information. We came full circle: Combine proven presentations with new concepts.
Some content is presented textual only. An example is RueSpeak™ by Ron Ross – an approach to present business rules in natural language.
2.4 Model and Model Output
A common misconception in model development is that model and model output are seen as the same. That’s wrong. This misconception is amplified by some modern web-based modeling tools. This is not about how to access the model but about specific content and different presentations for different stakeholders. The fact that everybody can access the model in the intranet/internet ignores the fact that we need different views for different stakeholders. Model and Model Output have different target audiences and different goals. They overlap in some parts. The visual presentation is usually the link between both.
|Modeler is main stakeholder.||Different Stakeholder: Management, QA, Compliance Officer, Operator, Worker. ...|
|Should be maintainable in an easy way and long term||Should be understandable; should comply with the user experience|
|Should be consistent||Should be adoptable to new views and formats|
|Focus on single views||Focus on combination of different content, compiled from single views|
|Must contain all information for the requested outputs||Different formats needed: HTML, PDF, MS Word, ...|
|Should be evaluated and analyzed easily||Should be easy to find relevant information|
Table 1: Model vs. Model Output
The model output addresses in form and content our stakeholders first. Often the requested form doesn’t allow easy maintenance. The different stakeholders request very different presentations and different content for the same model subject and the same level of abstraction. TOGAF defines the concept of View and Viewpoint. The different outputs need to be generated from the same model. The outputs don’t define how we structure our models and the model repository.
The structure of Models and the Model Repository has to support maintenance, long term use, evaluation, and other requirements. The structure has to support model governance. Other issues as access rights and collaboration have to be taken into account.
The model output determines which content we need in our model repository. The question for stakeholders and their views is the start for the modeling effort.
2.5 Content, Comprehension and Form of Presentation
2.5.1 What should be in a Model? Primary and Secondary Model Content
A model should reflect all relevant views on the model subject. E.g. for a Business Process we are interested in the flow of activities, the details of each activity, the participants in the process, and their communication. To understand all this, we need additional information. E.g., What is the scope of the process? What did we assume? Which information and which process context is given? We summarize these parts – content, assumptions, restrictions – as Primary Model Content.
To make sure the model is easy to understand and traceable we need more information. This is not information about the model subject per se but results from the modeling and design process. These are knowledge sources and design decisions in the first row. This helps us to understand where the information in our models is coming from – maybe from a regulation or policy, maybe from a stakeholder or a subject matter expert. This is essential information for maintenance, governance, and impact analysis of our models. During the design process, we make decisions. We prefer one option over another how the process or the capability should be built. What is in the scope? What is not? How do we plan the flow of activities? It is not only the result of the design decision which is of interest. We have to understand the rationale behind such a decision. The reasoning behind is even more important than the result itself. Which goal has a higher priority than another?
Depending on the goals of our effort, more information is maybe needed. This information is for understanding and governing our models essential too. Often this information is needed for the output for some stakeholders too.
We summarize these group of information – knowledge sources, design decisions, other information – as Secondary Model Content.
Figure 1: Primary and Secondary Model Content
2.5.2 Organizing Primary Model Content
To achieve good maintenance for our model we need a structured model repository. We follow the perspectives of the Zachman Framework for Enterprise Architecture. Model Based Business Engineering focuses on the perspectives Scope and Business Concepts. We develop and describe the requirements of the System Logic perspective too. Table 2 shows examples of typical model contents for the perspectives.
|Scope / Contexts||Process Map, Capability Map, Vision, Goals, Objectives, Heat Maps|
|Business Concepts||Business Process Models, Decision Models, Business Requirements, Business Capability Models, Organizational Structure|
|System Logic||Requirements for IT and technology support|
Table 2: Perspectives and typical model content in MBBE (Examples)
2.5.3 Secondary Model Content
The value of a model is not only in the description of the primary model content of the model subject. The design decisions, restrictions, or guidelines for the process or capability are equally important and sometimes even more. In our view, the secondary content is mandatory for a good model.
Elements or attributes for such information are not present in most standard notations as BPMN. The standard notation DMN defines the model element “Knowledge Source”. It is explicitly shown and available for impact analysis and evaluation. We have to find own solutions if the notation we choose lacks such elements. Which options are available depends also on the tool used.
The rationale behind the design decisions is in the core of Business Process Management. We document the result and the reasoning for traceability and assessment.
3 ... Business ...
3.1 Business – What is the subject of interest?
The subject of interest in Model Based Business Engineering is the enterprise. A good IT system or a single Business Process doesn’t ensure a successful organization.
The purpose of our models is the development and improvement of “Business Capabilities”.
„Business“ has many facets. We need to address the different stakeholder views on different levels of abstraction. We need to be clear about vision, goals and strategy of the enterprise before we talk about operative business processes and business decisions. We are interested in the business process flow, responsibilities, supporting IT systems, and other relevant information on the operational level. E.g., to improve processes in a warehouse, you need to know the topology of the warehouse. Therefore we talk about ”Business Capabilities”. Figure 2 shows the Burlton Hexagon for describing process centric Business Capabilities.
Figure 2: Burlton Hexagon for the description of Business Process centric Capabilities
We need to specify the different information needed, a structure for presenting the model, and a structure for the organization of the model repository. As said, we use the Zachman Framework for Enterprise Architecture as a base. Other frameworks and structures are possible.
3.2 Business and IT – What ist the role of technology in Model-Based Business Engineering
Business without IT or technology in general is not thinkable today. We discuss the “Internet of Things” or the digitization of Business Processes. Both include technical solutions as well as the business view.
IT has to be “business aware” the same way as business has to be “technology aware”. Business and IT together need to evaluate the use of technologies for better business solutions solving business problems.
System descriptions, system requirements, connection between systems and business capabilities are in the scope of Model-Based Business Engineering. Especially requirements for Business-IT-Systems are part of the approach. The development and description of the systems is not in focus. Different model-based approaches exist for this as the Model-Based System Engineering (MBSE). We understand Model-Based Business Engineering as complementary to such approaches.
4 ... Business Engineering – Develop Business Capabilities systematically
We understand model development for business as an engineering discipline. This means
• We can plan it.
• The quality of our models can be measured.
• Model development is comprehensible and repeatable.
• Models can be maintained and used long term.
• Design decisions are made with a reason
This should be obvious but isn’t so in daily practice. The request to produce models in a comprehensive and repeatable way causes discussions. We expect that the resulting models are comparable if they are based on the same information independently which team member created them. Modeling is a creative activity. The models will not be identical. We maybe do different design decisions resulting in different models. That’s why capturing this information is essential. If the result is completely different, something is wrong. We don’t follow an engineering approach.
4.1 Standard-Notations, informal Descriptions and Styleguides
Standard Notations are important to achieve the stated goals.
We experience many discussions about flaws and incompleteness of notation in social networks or at conferences. No question – all the standard notations leave room for improvements. But in most cases, they offer a better base compared to proprietary notations. They all include an extension mechanism to integrate additional attributes to cover own requirements. The defined exchange format allows to use different tools and to collaborate. All standard notations leave a (large?) degree of freedom to the modeler because they address very different usage scenarios. You have to ensure that everybody in the team has the same understanding of the concepts and the notation no matter if you use a standard notation or an own one. This includes developing a common view on the concepts but also rules on how to use the elements of the notation. Such rules reach from simple guidelines as using colors or naming model elements to more complex questions as using specific elements and attributes or defining patterns to apply. Typically, we define a Style Guide or Modeling Wiki for our team.
4.2 Modeling and Working Techniques
Many working techniques for capturing, analyzing and transforming information into models exist. We have best practices for estimating and planning model projects. Working techniques include process mining, textual analysis, techniques for interviewing, workshop organization, facilitation and many more.
Applying such techniques is important part of Model-Based Business Engineering.
4.3 Business Engineering is a People Business
We need the engagement of our stakeholders in our effort to design and improve Business Capabilities. Our models support this.
The designed processes have to be implemented. Change Management is an outstanding discipline in Business Management. Change Management uses our models to communicate Business Processes, organizational structure and planed changes.
Designing the model output requires a good understanding of the stakeholder, their requirements, expectations and experiences.
This is strongly connected to the culture of the organization. Implementing Business Processes and Business Capabilities requires a certain culture and cultural change.
4.4 Continues Improvement and Model Governance
Business Engineering is not a one-time effort. Processes and capabilities need to be improved continuously to stay competitive. We monitor processes and measure key performance indicators based on our models. We change processes and capabilities based on this results.
Continuous improvement of Business Processes and the organizational context brings the danger that models and reality are no longer in sync after some time. We have to make sure both stay in sync or we risk to lose our investment in the models. We define Governance Rules and processes for the maintenance of our models.
Burlton, Roger, Business Process Management: Profiting from Process: Incorporating Internet Strategies, Que, 2001
Zachman, John F., John Zachman, The Zachman Framework For Enterprise Architecture: Primer for Enterprise Engineering and Manufacturing, Zachman International, 2006, Electronic Book
Osterwalder, Alexander, Pigneur, Ives, Business Model Generation: Ein Handbuch für Visionäre, Spielveränderer und Herausforderer, Campus Verlag, 2011
Ross, Ron, Pitschke, Juergen, RuleSpeak® Satzformen, Business Rules in natürlich sprachlichem Deutsch spezifizieren, Business Rules Solutions, LLC und BCS, Dr. Jürgen Pitschke, Version 1.1, 2009
This material may be used freely on an in-house, non-commercial basis. Commercial re-use or re-transmission of any portion of this material is prohibited without written permission of Dr. Juergen Pitschke, BCS - Dr. Juergen Pitschke. Contact BCS - Dr. Juergen Pitschke for licensing and re-use arrangements. Please include this notice in all reproduction.