Modeling Fundamentals
Models are always wrong in some ways, and they are always incomplete, missing part of the messy human complexity of the real world. But models can be useful for communication, analysis, and other purposes. This chapter explains how models are wrong and why they are useful and introduces the four business model disciplines that are explained in more detail in subsequent chapters.
There are many models described in this book, and every one of them is wrong. Every model we have ever created is wrong, as is every model you will ever build. Being wrong is part of the nature of a model. The world that we model is much richer, much more complex, and much stranger than the models that we build of it. If you are the kind of person who always wants to be right and who never wants to be wrong, you should close this book and continue with some other endeavor. Modeling is not for you.
The pioneering statistician George E. P. Box said it best: “All models are wrong. Some models are useful.”1 Sometimes people discuss whether a model is right or wrong, but that discussion is pointless since all models are wrong. Instead people should discuss whether the model is useful.
Model Fidelity
The fidelity of a model is a measure of how closely the model approximates the real world. Fidelity is an inverse measure of wrongness: a high-fidelity model is less wrong than a low-fidelity model. Your drive through Metro DC, introduced in Chapter 1, provides a good illustration. The model inside your car’s navigation system is similar to the paper roadmap, but it has some additional detail. The navigation system model includes the typical traveling speeds of the roads and highways, so it can calculate the quickest path from where you are to where you want to go. It also knows that in Alexandria, 112 N. St. Asaph Street is on the west side of the street, between King and Cameron, that the traffic on Prince Street is one way, and that you cannot turn left from northbound Royal onto King Street but must instead turn right and go around the block. Both the paper street map and the model in the navigation system approximate the real world of Metro DC streets, but because the navigation system has additional details, it has higher fidelity.
Fidelity decays over time as the world being modeled changes. The fidelity of both the street map and the navigation system model will decline as new roads are built and old roads are closed, as overpasses are constructed and new addresses assigned. The world changes, and models must be updated to keep up with the changing world. New editions of paper street maps are published annually, and car navigation systems are regularly updated with new models on DVD.
You might think that a higher-fidelity model is better than a lower-fidelity model, and sometimes you would be right. Higher-fidelity models are more accurate—not as wrong—as lower-fidelity models. But higher-fidelity is sometimes worse than lower-fidelity. Higher-fidelity models take longer for people to understand all the extra detail. They are more expensive to build because extra detail must be created and extra time spent to check that the model is right. As the world changes, models must be maintained, to keep them up-to-date with the world they model. Higher-fidelity models are more expensive to maintain: there is more detail that must be kept aligned with the changing world. As the comic Steven Wright says, “I have a full-size map of the world. I hardly ever unroll it.” Lower-fidelity models are always easier to unroll.
Modeling is always an economic tradeoff between the value that the model provides and the cost of building it. Sometimes a high-fidelity model is better, since the extra expense of the fidelity is justified by the value it delivers. Sometimes a low-fidelity model is better, since little additional value can be wrung from more fidelity.
Novice modelers sometimes try to create models that are as accurate as they can make them, as high fidelity as they can build. This is a laudable effort, but it’s misguided: a rookie mistake. Modeling is not like developing software, where fewer bugs means better code. Instead modeling is more like recording music, where there are limits to how well the ears can hear, and hence limits to how perfect the sound must be. We have more to say about the economics of fidelity and how to manage the fidelity of a modeling effort in Chapter 7.
Model Validity
Fidelity is one kind of measure of how wrong a model is. Validity is another very different kind of measure of model wrongness. A model is valid if it meets all the constraints, and it is invalid otherwise. Org charts are a simple and familiar type of business model. An org chart that has a circular reporting relationship—Patricia reporting to Michael and then Michael reporting back to Patricia—is invalid. An org chart that shows Michael reporting to himself is also invalid. Org charts require reporting relationships to go in one direction, without circular paths.
Validity is true or false. Either a model meets the constraints or it doesn’t. There is no middle ground. Validity is very different from fidelity in this respect. Fidelity is all about shades of gray. A model can be a sort of accurate reflection of reality (for its purpose), and another higher-fidelity model can be more accurate.
Validity is a property of the model itself. Does the model meet the constraints? Then it is a valid model. Fidelity is about how the model relates to the world being modeled. Is the model an accurate reflection of the real world? Then it is high fidelity. All models have these two qualities: validity and fidelity.
Classic Business Models
In Chapter 1, you were considering the acquisition of the Cora Group. Let’s now return to that story.
When you arrive at the restaurant for your meeting, Sam Coates greets you. Sam built the restaurant group and is now eager to sell. He wants to show all the good things about it. Your job is to analyze it, to understand it well so that you can recommend whether it should be acquired. You need to weigh how much it is worth and consider the difficulties of replicating its success in other cities.
Sam starts your tour of the Cora Group by showing you an org chart, showing who reports to whom. In the org chart, shown in Figure 2.1, there are five general managers, one for each of the five restaurants, and a director of operations who oversees some services shared among the five. A few diagrams show all the names, the positions, and the reporting relationships. The org chart he shows is a kind of business model, a model of his business. It is certainly a simple representation; you can understand it all in a few minutes.
Sam then explains the plans for new menus. The team working on that project includes the five head chefs, one of the general managers, and the director of operations. But this cross-restaurant team is not shown anywhere in the org chart, and the members of the team report to different parts of his organization. The underlying reality of even this small business is much more complex than that shown in the org chart model, since the org chart includes permanent reporting relationships, not cross-functional teams assembled for ad hoc projects.
Sam next shows you financial statements. He presents a balance sheet and an income statement for each of the last few years, showing how his business has grown and how profitable it could be as part of your company.
Sam’s income statement is shown in Figure 2.2 in dollars. It shows the revenue of his company, the expenses to achieve that revenue, and the resulting income. Income statements are always over some time period, a year, a quarter, even a month. In Figure 2.2, Sam shows annual revenue, expenses, and income for each of the last three years.
The financial statements Sam shows you are a different business model of the same business. The org chart focuses on the employees and the reporting relationships. The financial statements focus on how much money the restaurants are earning and what financial assets and liabilities they have. The two business models serve different purposes, and they are complementary.
Financial statements and org charts are classic business models. Financial statements have existed since the development of modern accounting in Renaissance Italy 500 years ago. In all likelihood, org charts date even earlier, to the first large armies and governing bureaucracies in ancient Egypt, China, or Persia.
But some questions about the business cannot be answered with these classic business models. For example: What are Cora Group’s non–financial goals for this year, and how are you trying to achieve them? Neither the accounting models nor the org structure help with an assessment of the goals and strategies. The classic business models do not provide a complete picture of the business. We need different business models to answer those questions.
Four Model Disciplines
Recently four newer business models have become important, models that complement the classic models. These new models do not displace financial statements and org charts. Income statements are not going away, not in our lifetime. Instead the four new models focus on some different parts of the complex reality of business. Just as a financial statement and an org chart can show two views of the same business, these new models open up some new views of business—new views for new purposes.
The four new models are business motivation models, business organization models, business process models, and business rule models. Business motivation models describe business goals and the means to accomplish those goals. What are we trying to achieve at Cora Group? What strategies are we using to achieve those goals? Business organization models describe what groups exist and who interacts with whom to get the work done. Who at Portia interacts with the third-party bakeries? Business process models show the step-by-step tasks to accomplish the work. How does our waitstaff serve the customers through a dinner? How do we hire a new assistant chef? And business rule models describe the laws, policies, and other guidance that constrain the work. What health rules do we enforce? What guidance do we give our waitstaff on how to satisfy unhappy customers? Together these four kinds of models describe much that is important about Portia, or about any business.
Each of these four kinds of models is a model discipline. A model discipline includes a set of constraints for determining whether a model is valid. The constraints are different from one model discipline to another. For example, the constraints for business process models are different from the constraints for business motivation models. A valid business process model of hiring a new assistant chef at Portia is not a valid business motivation model of anything.
We describe each of the four model disciplines in Chapters 3–6, with one chapter on each discipline. Some of our description is about the validity constraints for the discipline. For example, Chapter 3 describes business motivation models, and some of Chapter 3 is about explaining what makes a valid motivation model and when a model is invalid. The rest of Chapter 3 is devoted to explaining how to build a business motivation model and how to interpret a motivation model once one is built.
Each model discipline has a different focus, different questions that it can answer, and different analyses that it supports. When modeling a business, you usually build models in several different model disciplines, to look at the business from different angles. Recall that you examined both financial statements and org charts for Cora Group acquisition: models from two classic disciplines.
The four new business model disciplines complement each other. With a business motivation model of Cora Group, we can look carefully at the goals and influences that have led to the company’s success. With a business rule model of the same restaurants, we can examine the particular policies they use to guide menu creation and customer service, and how those policies lead to a good customer experience. The two models provide different perspectives on the same business.
The four model disciplines also complement the classic accounting and organizational disciplines. Some people believe that everything important about a business is reflected in the accounting—in the dollars and cents of the income statements and balance sheets. That is true, if you wait long enough. Everything important eventually shows up in the accounting, but sometimes not until it is too late to fix. For example, a restaurant can have good books this year but be slow to seat and serve guests. This will lead to customer dissatisfaction and lower demand. Accounting will show this next year, as the revenues decline. A business process model of how people are seated and served will illuminate the problem today.
Maturity and the Model Disciplines
The four model disciplines are powerful—particularly in combination, describing a business using all of them—but all four are still evolving. In this book we describe a snapshot of current best practices, but we expect best practices to continue to improve over the coming years.
By contrast, accounting is the gold standard of business model disciplines. Accounting is mature, with a long history and hundreds of thousands of professional practitioners around the world, accountants who focus their efforts on creating and interpreting accounting models. Over its history, accountants have developed Generally Accepted Accounting Principles (GAAP), a framework for how to create accounting models for different real-world situations. GAAP is a standard for accounting fidelity, for judging when an accounting model is an accurate enough reflection of the company modeled. GAAP is a kind of threshold for fidelity; if a financial statement complies with GAAP, it is high enough fidelity for professional accountants to put their seal of approval on it.
Perhaps each of our four model discipline should have thousands of professionals and its own GAAP. There should be a business process GAAP that governs whether a particular business process model is an accurate enough reflection of a business process as practiced by a specific organization. Such a business process GAAP might include guidance—for example, that an unusual situation that occurs 0.1% of the time need not be modeled, but if the situation occurs 5 percent of the time, it must be modeled.
No such business process GAAP exists. Business process modeling is not mature enough yet. Until then, we must content ourselves with degrees of fidelity, without any professional consensus about how much fidelity is enough. Until consensus is achieved we must rely on our own judgments.
Wrong But Useful
At the beginning of this chapter, we introduced George Box’s dictum, “All models are wrong. Some models are useful.” We discussed why all models are wrong, but we ignored the second half of the quote—that some models are useful. Now it’s time to examine model usefulness. In particular, we will look at some model shortcomings that make an otherwise useful model less useful or sometimes not useful at all.
To be useful, a model must have enough fidelity for the intended purpose. But fidelity alone is not sufficient. Models are read and interpreted by people, sometimes by the same people who built the model, and usually by others as well. As we described in Chapter 1, models can be useful for eight purposes:
All eight require human interpretation. (Direct execution also involves computer interpretation.) And to be interpreted by people, a model must be understandable.
Some model disciplines are inherently difficult to understand. For example, the US Department of Defense uses the IDEF family of languages for both business modeling and data modeling. Most people find IDEF diagrams difficult to read and understand. IDEF requires much training, not just to create the diagrams but to interpret a diagram created by others. As a result, IDEF is not widely used outside the US military and its contractor community. In contrast, the four model disciplines described in this book have been engineered for easy understanding, so people can read a model created by others with little or no training.
Too Big to Understand
An overly large model is not useful: it cannot be comprehended, and so the purpose of the model will not be achieved. Consider Figure 2.3, a diagram that shows strategy alternatives for Adelina—one of the Cora Group’s restaurants—and the consequences of the different alternatives. This Adelina strategy example will be explored more thoroughly in Chapter 3, but for now, notice the size and complexity of the model. There are 14 model elements in Figure 2.3 and 18 associations among these model elements. Parts of the model are understandable on their own, but the whole is too complex to understand all at once.
If a model is too big to be understood, it will be ignored. If you hope to train some people with the model, they will fail to learn what you are teaching. If the model is to be analyzed to transform your business, the analysts will ignore the model and rely on their own judgments and biases. If the model is to serve as requirements for software development or implementation, the resulting systems will not match the business need. An overly large model is a bad model: It cannot be comprehended, and so the purpose of the model will not be achieved.
Large models like Figure 2.3 are common; in fact we have seen many models that are much bigger and more complicated, some with over 100 model elements in a single diagram. Beginning modelers often build models that are too big and too complex; they often ignore the limits of human comprehension.
How big is too big? A useful rule of thumb is that a model should have no more than nine elements. Nine is about how many things a typical person can keep in her head on a good day [Miller, 1956]. Beyond nine, people often get confused. And if the model you built confuses the people who read it, the fault is yours, not theirs. Your model is not easy to understand.
Of course the world is more complex than can be shown with nine elements. Adelina does have three alternative strategies, each with its own consequences. In fact there are more. There are other consequences of these three not shown in Figure 2.3 and other strategy alternatives not depicted. There is always a tension between complexity and comprehension, between the great complexity of the world and the human limits of comprehension. In Chapter 7 we describe three solutions to this problem, three approaches to resolving this tension.
The Appeal of Attractive Models
Model aesthetics matter. Attractive models are easier to understand and more readily accepted than ugly models. Attractive models are therefore more useful.
Consider the business process model shown in Figure 2.4. This is a valid business process model, and it is simple enough, but it is ugly. The process shows the activities performed by a server, a bartender, and a cook in taking drink and dinner orders in a restaurant, preparing them, and serving them. Figure 2.5 shows the same business process model after a makeover; it has the same modeling elements and flows, but they are arranged in a manner that is visually appealing.
Why care about the attractiveness of a model? The people who read and interpret the business process model aren’t going to care if it looks good. They just want to read it to do their job: understand the new process, analyze the old one, or check compliance that the work performed in the organization actually matches the activities in the model. So why does model attractiveness matter?
Model attractiveness matters because people will have emotional responses to the model they see. Their emotional responses will affect their ability to understand the model and will influence their acceptance of it. In our experience, attractive models are much easier for people to understand and accept than ugly models.2 Attractive models are therefore more useful.
This should not be surprising. Don Norman describes a similar phenomenon with user interfaces of software applications—that people find attractive user interfaces easier to understand [Norman 2004]. Model diagrams are visual. In a sense, the diagrams are the user interface to the mathematics behind the model. So, just as attractive user interfaces are easier to understand and are more effective, attractive model diagrams are easier to understand and accept.
The unconscious emotional response to an attractive model has another effect: It makes the model more persuasive. As described in Chapter 1, models are not just used for communication. They are also used for persuasion.
You don’t have to be a graphic artist—or hire one—to make a model attractive. Some simple care with the size and placement of model elements, and with consistency in labeling will accomplish most of what you need. Many modelers today pay little attention to aesthetics, so some attention to graphics will make your models much better than most.
Modeling Tools
Most business models today are created using software applications. Some models use special-purpose modeling tools that exist just for creating business models. Other modelers use general-purpose diagram drawing tools (such as Microsoft Visio™) that are used both for creating business models and for many other diagramming uses. Either approach can work. Both the special-purpose modeling tools and the general-purpose diagramming tools support the creation of models and the saving of those models to disk. Both provide functionality to make models attractive: fonts, colors, and model element layout.
But the general-purpose drawing tools have some serious shortcomings for modeling. When you draw a business process model in Visio (for example), the activities in the model are just rectangles. Visio will allow you to make one rectangle red or make another one smaller, but Visio offers no special support for recording the typical duration of an activity or for noting the subprocess behind an activity. Visio understands the activity as a rectangle in a drawing, not as an activity in a business process.3
The special-purpose modeling tools are better for business modeling. These tools understand business activities as activities, not as rectangles. Durations of activities are supported, as are subprocesses behind an activity. If you use one of these business modeling tools, you will find it quicker and easier to build, maintain, and analyze your models. Models built with a special-purpose modeling tool are more useful.
Special-purpose modeling tools also make it easier to build valid models. Because the drawing tools understand your business process as just a collection of rectangles and lines, they don’t complain when you do something wrong— for example, when you connect a strategy to an activity with a sequence flow. Visio won’t warn you that your model is invalid. But the special-purpose business modeling tools understand activities as activities. Some will warn you when you create an invalid model, like spell checking in a word processor. Other business modeling tools will prevent you from making an invalid model, in the way that a spreadsheet will prevent you from creating a circular reference.
For business process models, the special-purpose tools offer even more. Many tools support business process simulation, allowing you to experiment with prospective business processes to see what happens. Some tools support direct execution in a business process engine, allowing you to turn your business process model into executable workflow. Some tools show the status of a business process by monitoring external applications.
Using a drawing tool to construct your business process models is a bit like using a shoe to drive in nails. It works better than your fist, but you will be happier with the result if you use a hammer.
The Landscape of Business Modeling Tools
There are many special-purpose business modeling tools, and the modeling tool marketplace changes quickly, with new vendors, new products, and new releases of existing products every quarter. We don’t describe the vendors and products here because the marketplace will change between the time we write these words and the time you read them. (See our companion site bridgelandzahavi.com for some reviews on modeling tool products.) Instead of describing the vendors and products here, we describe some of the features of these tools. Today, none of the modeling products have all the features we describe, but we expect this to change; in the future the features described here will be common to all the special-purpose business modeling tools.
Aesthetics, Multiple Disciplines, and Validity Checking
We earlier discussed the curious power of attractive models and the importance of tapping that power by making your models look good. Most of the tools support making attractive models. They have the usual palettes of drawing functionality: color and shading, inclusion of image files, alignment and distribution, and so on. They are not professional graphics applications—there is no need to recreate the complex functionality of Adobe Illustrator in a business modeling tool—but they have the basic functionality. Some of the tools can also rearrange a model to make it more attractive—for example, making business processes flow from left to right and top to bottom.
Some of the existing tools support a single modeling discipline. For example, there are numerous tools that support only business process modeling and not the other three disciplines. Some tools support multiple disciplines. These discipline-crossers have the right primitives to create models from two business model disciplines, three disciplines, or even all four, allowing you to create a business process model, a business motivation model, a business organization model, and a business rule model.
Most of the tools check for model validity. Validity checking can be done by highlighting invalid parts of a model either as it is built or as a command that can be run to find all the invalid parts. Some modeling tools actually prevent modelers from creating invalid models at all.
Publication and Application Program Interfaces
Business modelers work with a modeling tool to create models and analyze the models they create. But every model built by a modeler will be consumed by others, probably a great many others: business analysts who analyze the models, managers who use the models to make decisions, and trainees who read the models to understand the business. These consumers of business models do not have any modeling tools loaded on their desktops, and even if a tool is installed, they do not know how to use it.
To make models accessible to this wider audience, many of the business modeling tools have publication functionality. A model can be published to a variety of accessible formats: to HTML for inclusion on a website, to PDF so it can be read in Adobe Acrobat™, to Microsoft Help™ files, or to Microsoft Word™ so it can be part of a larger written document. Some tools also support publication to XML, so a model can be transformed into other formats.
Sometimes a business model is embedded inside a larger software application. For example, a business process simulation can be accessible on a website, allowing users to try different scenarios and see the simulated results. Some business modeling tools support this kind of mash-up of business modeling with other functionality by providing a runtime application program interface, an application programming interface (API) that allows other software to access the functionality of the model.
Model Analysis
Business models are often analyzed to learn about the model and (more important) to learn about the business being modeled. Let’s consider one kind of analysis: examining business rules that neither support any goals nor are formulated based on any strategies. (We introduce goals and strategies in Chapter 3 and business rules in Chapter 6. For this example analysis, consider goals to be what the business is trying to achieve, strategies as how the business is trying to achieve its goals, and business rules as individual business directives.) Any business rule that has no connection to goals or strategies deserves a second look. Does it need to exist, or could it be repealed? Are there goals or strategies that have not been modeled that would justify this rule?
For example, one of Portia’s4 business rules is: It is prohibited that a reservation is taken more than 7 days in advance. Our analysis discovers that this rule is not justified by any of Portia’s goals or strategies. Now we should investigate whether this rule makes sense. Is there an unarticulated reason for this rule—perhaps there aren’t enough people to answer the reservation phone calls and so we want to reduce the number of calls? Or perhaps Portia staff enforces this restriction for no good reason, simply because they always have done so, and we should now repeal it.
Questioning unjustified business rules is just one analysis method— one of many. Just as a socket wrench set has sockets of many sizes, business modeling tools often have built-in support for many analysis methods. Some tools even allow a modeler to create her own analysis method, to aggregate the model elements in new ways to derive new kinds of metrics, or to search for model elements with particular characteristics. Model analysis is described in Chapter 10.
Simulation
Sometimes it is difficult to understand the implications of a business model, particularly complex business models and models that have many interacting elements. Simulation is a technique for running a model to get a deeper understanding. Many business modeling tools support simulation. A model that simulates is more useful than one that does not.
Twenty years ago computer simulation was an arcane topic, understood and experienced by only a few specialists. Things have changed. The emergence of mass-market simulation video games like SimCity™, The Sims™, Zoo Tycoon™, and many others has transformed the public understanding of simulation, taken it from the arcane to the commonplace. Every teenager—and every parent of a teenager—has tried his hand at being mayor of a simulated city, at managing a simulated family, or at creating and managing a simulated zoo. Simulation is entertaining, and simulation games are a growing part of the modern entertainment industry.
The objective of SimCity is to create a city. A player can create roads and rails, place police stations, build a power grid, and zone real estate as residential, commercial, or industrial. As a result of his actions, the city prospers or declines, crime rises or falls, simulated people live, shop, commute, and work, and so on.
Thanks to simulation games, many people are familiar with simulation. But what is simulation, really? First, simulations are based on models. Within SimCity is a model of a city: houses, neighborhoods, roads, rail, parks, and malls and the interactions of people who live in those houses, travel on those roads and trains, play in those parks, and shop in those malls.
Second, a simulation shows how a model behaves over time. Things happen in SimCity over time: houses are built, existing roads become congested, crimes are committed, and neighborhoods improve or slide in disrepute. These changes are not scripted; the decline of a neighborhood in SimCity is not preordained by the application. Rather, things happen the way they do because of the gradual interaction of all the elements of the city model over time. A nearby district fills in and people start commuting through the neighborhood, leading to more traffic on the streets. The neighborhood becomes less desirable because of all the new traffic. Some crimes occur, and the local police station is a bit too far away to respond. Then more crimes are committed.
SimCity is a playable simulation. As a mayor, you manage the city. You open new police stations, rezone neighborhoods, create parks, and change tax rates. Depending on your actions over time, a range of behaviors can be produced: crime can rise or plummet, the citizenry can be prosperous or destitute, and they may drive cars or ride subways.
Some business simulations are also playable, like SimCity. A player can steer her business over time, changing prices, improving product design, or developing new products. Typically these simulations are played either as part of a corporate training course or to give the player some insight into a new strategic environment.
But most business simulations are not playable. They are simulated purely for understanding behavioral results of a new process or strategic environment. Simulation becomes another method of analysis. Usually many different simulation runs will be made of a nonplayable simulation, to explore a space of possibilities, and the results will be summarized in graphs or statistics.
For example, you might create a business process model of how Portia customers experience the restaurant. A customer arrives, perhaps waits for a table, is seated, orders a meal, pays, and departs. Of course, the customer’s quality of experience will be affected by the food, but it will also be affected by delays and customer service. Simulating the process model will reveal where delays are present and allow us to experiment with alternative techniques—more servers, fewer reservations, etc.—to reduce those delays.
No one is playing this Portia simulation. Rather, this nonplayable simulation allows us to better analyze and understand the process.
Chapter 11 describes how to build business model simulations and how to use the simulations once they are built.
Traceability
In examining a model, it’s always useful to ask about the purpose of individual model elements. Why do we enforce this rule? Why do we perform this business process task? The answers to the questions of purpose are usually model elements in other models. We enforce this rule because of a particular strategy we are working.
Traceability is connecting model elements between models, explaining a model element in one model by referring to a model element in another. Traceability answers “why” questions—questions about rationale, purpose, and intent. Some business modeling tools support traceability.
Consider again the business process model shown in Figure 2.5, the process that shows how the waitstaff at Portia takes a dinner order. Why does the server take the drink order first, rather than asking about drinks and dinner at the same time? At fast-food restaurants, takeout restaurants, and many other places, food and beverages are ordered together. Why do the servers at our restaurant work first on the drinks and only then on the food?
There could be many reasons for sequencing beverages first. One reason is that customers will drink more if they are served drinks first, and drinks are high-margin items for the restaurant. Another reason is that Portia aspires to be the kind of upscale place where customers stay for hours. At more sophisticated restaurants, taking the drink order and dinner order at the same time is considered to be rushing the customer and is inconsistent with a high-end image.5
Figure 2.6 shows part of the restaurant’s motivation model—the goals Sam and his staff are trying to achieve at Portia and how they are trying to achieve those goals. Asking for drink orders first is a tactic, a short-term course of action that is meant to channel effort toward objectives or goals. Other tactics are also shown in Figure 2.6: describing wines that suit the food the customer orders as well as offering wine samples.
All three tactics channel efforts toward the objective of increasing wine sales by 10%. The tactic Ask for Drink Orders First6 also channels efforts toward the goal of maintaining a civilized atmosphere.
Of course, this is only a small example. A more complete motivation model for our restaurant would include many more tactics, objectives, and goals as well as other motivation model elements such as influencers and threats. Business motivation models are described in Chapter 3.
The activities of Figure 2.5 are connected to the tactics, objectives, and goals of Figure 2.6 through tracelinks. Figure 2.7 shows the activity Take Drink Order (from Figure 2.5) tracelinked to the tactic Ask for Drink Orders First (from Figure 2.6). That tracelink explains why servers at Portia take drink orders first: It is a tactic of the restaurant, a tactic that channels effort toward both the goal of maintaining a civilized atmosphere and the objective of increasing drink orders by 10%.
Note that tracelinks are not relationships between whole models. We are not tracing the whole business process model to the whole business motivation model. Rather, we are tracing two individual elements of the business process model to a single element in the motivation model. We are not answering broad questions about the purpose of the business process model. Instead we are answering narrow questions about the purpose of serving drinks first.
Traceability is useful for understanding the impact of a change. If we change this tactic, what activities must be changed? By examining the tracelinks that point from activities to the tactic, we can determine which ones are affected. With the right tracelinks in place, we can continue our traceability walk, looking at which systems support the activities that are affected by the changed tactic.
Traceability is a bit like the index to a book. You can look up “Frederick the Great” in the index of a history of Prussia (for example) and find all the references to him in the book. In a similar way you can examine the tracelinks to a model element and find all the other model elements that are dependent on it.
Models change over time to reflect changing ideas of strategy, business processes, organization, and policy. For example, a goal might initially be active, as the organization works to achieve it. After the goal is achieved, it is no longer an active goal for the organization. But the goal wants to be retained rather than removed from the model. If it is removed, you have lost the knowledge that it ever was a goal as well as the fact that it was achieved. Some modeling tools support model version control so that you can keep track of what model elements are active today.
Traceability is explored further in this book, in Chapters 4–6. For example, Chapter 6 is about business rules and describes how rules trace to business process elements, business organization elements, and business motivation elements.
Model Deployment
Business models are sometimes used to drive software development. For example, an insurance company might model its claims approval business process as a first step to writing an application that supports that business process. Of course, that is a rather slow method of assuring alignment between the model and application: Software development takes at least months to complete and can take much longer. Much can change in the claims approval business process between the time that process is modeled and the time the application is ready for use.
There is a faster alternative way for our insurance company to use its business process model to drive its software; it can deploy the model. When a model is deployed, it is directly executed as software. For example, a business process model can be deployed as workflow. Users of the software are not even aware that they are working with a deployed business model. To them it feels like any other application.
Of course, the business model by itself is not enough. To deploy a business model, we need a special-purpose deployment engine, an application whose sole job is to execute business models (of a particular discipline) and turn them into functioning software.
Let’s consider an example. When an insurance claim completes an activity in the claim process, the deployment engine uses the claims business process model to figure out what to do next. If the next step is approval of a repair estimate to be performed by a claims adjuster (for example), the deployment engine queues up the work for the claims adjuster. Her approval will cause the next activity in the process to be queued up for the next person in the process. To the claims adjuster the business process model no longer looks like a model. Instead it looks like part of the software application she is working in.
Business rules can also be deployed. A business rules engine will notice when a travel expense policy rule is violated, will log the name of the employee who violated the policy, and will ask the individual to explain why she violated the policy. To the woman who violated the corporate expense policy, the business rule model no longer looks like a model. It looks like part of the expense documentation application she is using to record her expenses.
Model deployment is a new and radical use of business models. It is described in more detail in Chapter 12.
Business Modeling Standards
Several business modeling standards have emerged in the last few years. But what is a standard? A standard is a technical agreement by many people and many software applications. For example, HTML is a standard. Thousands of people agree on what the various tags in HTML mean, and thousands of software applications have knowledge of those tags embedded within them.
Business modeling is becoming standardized. Standards are useful because they provide a degree of independence between customers of business modeling technology and vendors of that technology. Without standards, a customer is vulnerable to vendor lock-in: their existing modeling tools vendors can raise prices freely and even reduce quality. The customer can do little but accept the worse state of affairs. Changing vendors is too painful. All of their existing models won’t work in the new vendor’s technology.
Standards change the nature of the game between customers and vendors. When multiple vendors support the same standard, it is easier for a customer to switch to a new vendor. When customers have the ability to switch, modeling vendors must keep prices reasonable and raise the quality of their software and service. The power of vendor lock-in is reduced.
Standards allow different modeling tools to communicate. For example, consider the deployment of a business process. A modeler can add some activities to a business process model using the modeling editor on his laptop. When this newly changed process is ready for deployment, it must be uploaded to the business process execution engine, a different application, running on a server somewhere. But how is the model communicated from the modeling editor to the execution engine? How do the two applications communicate about the model? A standard business process modeling language is the best means of communication between these two applications.
Standards also make communication easier between people. When a modeler explains a business motivation model she built to a modeler colleague, that communication is easier if they already agree on what an objective is, what a tactic is, and how tactics and objectives relate to each other. The communication can focus on the details of particular objectives and tactics rather than on what they mean. They can focus on the content rather than the form. A standard for business motivation models is a good route to that common knowledge; the two modelers can learn the right standard and then communicate with anyone else who also knows the standard.
The State of Business Modeling Standards
In the 1980s and 1990s, there were few business modeling standards, and the standards that did exist were not widely used. But in the last few years, good standards have been created and are becoming widely adopted.
Each business modeling discipline has a somewhat different standards situation. Business process modeling is the most mature of the four. There have been several proposed standards in the past. Business Process Modeling Notation (BPMN) and Business Process Definition Metamodel (BPDM), are two industry standards that are further discussed in Chapter 5.
The standard for business motivation models is the Business Motivation Model (BMM). BMM is a new standard describing an important space that has seen little attention from tool vendors until now. BMM is described in Chapter 3.
The standard for business rules is Semantics of Business Vocabulary and Business Rules (SBVR). SBVR is described in Chapter 6.
The newest of the four disciplines is business organization models. There are no adopted standards yet for business organization models. Organization models are described in Chapter 4.
Many useful business modeling practices are not yet standardized. For example, BPDM does not yet support business process simulation. Similarly, BMM does not support strategy simulation. Every year new modeling practices are created. A new practice must prove itself and become widely adopted before the standards bodies are interested in incorporating it. In Chapters 3–6 we point out what aspects of business modeling practice are not yet part of the standards.
Business Modeling and Enterprise Architecture
An enterprise architecture is a description of an organization’s entire information technology systems and the processes, people, and strategy that accompany those systems. In recent years, many organizations have embarked on enterprise architecture efforts. Since 2001 (or according to some observers, since 1996) the US Federal government has been developing an enterprise architecture of the entire business of the Federal government. Considering the size of the Federal government, that enterprise architecture is an enormous endeavor.
Enterprise architecture—often abbreviated EA—is different from the business modeling we explain in this book, but there are some overlapping concerns and techniques. And many of the same vendors of business modeling tools also sell enterprise architecture tools, sometimes effectively targeting the same applications at the two different markets.
Enterprise architecture has a much broader scope than business modeling. EA is concerned with the whole enterprise, capturing all the business processes, all the applications, all the data, and all the IT infrastructure in an enterprise. EA is about creating an inventory that includes everything, something comparable to an asset inventory but focused on IT assets and the business processes they support rather than physical assets such as furniture and buildings.
In contrast, the scope of business modeling is tightly focused on a particular business problem. For example, a business modeling effort might look at why it takes so long to purchase new equipment and how that procurement process could be shortened. To tackle that problem, business modelers would model only the procurement process, not the personnel recruiting process or the expense reporting process. A motivation model might be built, but only for the motivations that are relevant to procuring new equipment.
Sometimes business models are created for deployment. For example, a business process model might be deployed in an execution engine. But not every business process in the enterprise is modeled and deployed, at least not all at once. Typically the processes whose execution will generate the most value are deployed first.
Because business models are focused on a particular problem, they are much smaller than enterprise architecture models. They are also much more detailed, with all the nitty-gritty that is important for solving the problem at hand. Because enterprise architecture models endeavor to span the enterprise, they have much less detail about any business process. They can’t afford much detail if they are to cover everything.
The broad inventory scope of enterprise architecture supports asking questions about overlap and redundancy, Why do we need three different financial management applications? Can we migrate to a single application and lower our costs? Why do we have different processes for recruiting nurses, recruiting physicians, and recruiting staff? Can we combine the processes and simplify our work?
In addition to eliminating existing redundancy, enterprise architecture models can help to avoid creating the redundancy, or at least avoid adding to the problem. For example, the US Federal budgeting process requires that agencies justify their IT spending. The justification needs to include how the spending helps the agency’s mission and how the spending fits in the existing enterprise architecture. Central budgeting authorities use these justifications to see where a proposed new system is redundant with another system in another agency. They turn down budget requests that would create redundant systems.
Sometimes enterprise architectures are used to provide a long-term picture of where an organization should be headed: to socialize a roadmap. An enterprise architecture can provide many stakeholders with a common picture about the business processes the enterprise will use and the technology that will be adopted to support those business processes.
Enterprise architecture always includes technology, inventories of the applications and infrastructure owned and used by the enterprise. Often these applications and infrastructure are traced to the business processes they support. Business models by contrast are sometimes traced to technology models and sometimes they are not. Sometimes business models stand by themselves, without reference to any technology. It all depends on the focus problem: why the business model is being built.
Because enterprise architectures are cross-enterprise inventories, they are built to last. An EA model is intended to be updated every quarter or every year as things change. Business models are sometimes updated with the business, and sometimes they serve their purpose and are discarded. Again, it depends on the focus problem.
Business models are different from enterprise architecture models, but the two kinds of models play well together. In particular, existing business models can serve as components of a newly created enterprise architecture model. Most enterprise architecture modeling exercises include business process models. Instead of creating new business process models for just this purpose, you can reuse existing business process models originally created for other purposes. A similar situation exists for motivation models. Some enterprise architecture efforts include modeling the goals and strategies. If an existing motivation model already exists, the existing goals and strategies can be reused for the enterprise architecture.
In organizations that have created an enterprise architecture, it is useful to tie new business models to the existing enterprise architecture. Model elements in a business model are traced to model elements in an EA model to show how the focused business model fits in the larger enterprise whole.
The business modeling techniques described in this book are largely applicable to enterprise architecture as well. For example, the techniques in Chapter 5 of creating detailed business process models for analysis also apply to the high-level business process models that are part of an EA. The techniques described in Chapter 7 of keeping models simple and understandable also apply to enterprise architecture.
A business model is a map of a business, a simple representation of the complex reality. A business model can be valid or not, depending on whether it adheres to the rules of its modeling discipline. A business model can be of high or low fidelity, depending on how accurately it models the business.
To make business models more useful, we use specialized tools for creating them. These tools support us in building useful models—models that are valid, simple, attractive, and of high fidelity. We usually analyze the business models we have built. Often we simulate them. Sometimes we deploy them into an execution engine.
There are four business modeling disciplines: process modeling, motivation modeling, rules modeling, and organization modeling. Each discipline has its own standards describing what valid models are and what they mean. Chapters 3–6 explain the four modeling disciplines in detail, starting with business motivation models in Chapter 3, models of what the business is trying to achieve and why.
1Box was not referring specifically to business models. His work was in the application of statistics to the design of chemical experimentation. But his keen observation about the nature of modeling resonates with all of us who create models.
2To some extent, attractiveness is culture-dependent. An appealing model in Norway might or might not look good in Japan. But even if the particulars of what makes a model look good vary, the importance of model aesthetics seems to be universal.
3Out of the box, Visio is a drawing tool, but it can be augmented to become a specialized business modeling tool. In fact some business modeling tools have been created as Microsoft Visio add-ins. These tools do support activity durations and the subprocesses behind activities.
4As you may recall, Portia is one of the Cora Group restaurants.
5Outside the United States, the norms of a civilized atmosphere are different. In France, for example, wine is ordered only after dinner selections have been made.
6In this book all model elements are shown in bold.