Business Modeling: A Practical Guide to Realizing Business Value

Paperback (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $16.67
Usually ships in 1-2 business days
(Save 75%)
Other sellers (Paperback)
  • All (8) from $16.67   
  • New (5) from $48.15   
  • Used (3) from $16.67   


As business modeling becomes mainstream, every year more and more companies and government agencies are creating models of their businesses. But creating good business models is not a simple endeavor. Business modeling requires new skills.

Written by two business modeling experts, this book shows you how to make your business modeling efforts successful. It provides in-depth coverage of each of the four distinct business modeling disciplines, helping you master them all and understand how to effectively combine them. It also details best practices for working with subject matter experts. And it shows how to develop models, and then analyze, simulate, and deploy them. This is essential, authoritative information that will put you miles ahead of everyone who continues to approach business modeling haphazardly.

• Provides in-depth coverage of the four business modeling disciplines:
process modeling, motivation modeling, organization modeling, and rules modeling.

• Offers guidance on how to work effectively with subject matter experts and how to run business modeling workshops.

• Details today's best practices for building effective business models, and describes common mistakes that should be avoided.

• Describes standards for each business modeling discipline.

• Explains how to analyze, simulate, and deploy business models.

• Includes examples both from the authors' work with clients and from a single running example that spans the book.

Read More Show Less

Product Details

  • ISBN-13: 9780123741516
  • Publisher: Elsevier Science
  • Publication date: 12/5/2008
  • Series: MK/OMG Press Series
  • Edition description: New Edition
  • Pages: 408
  • Product dimensions: 7.40 (w) x 9.10 (h) x 1.00 (d)

Meet the Author

Dave Bridgeland is currently CTO of Unisys Global Business Transformation. He has work with business modeling and simulation since 1987, and has led business modeling teams and projects at Coopers & Lybrand Consulting, KPMG, and Unisys, and has served as VP of a business modeling tools startup. Dave has created business models for many organizations, including government agencies, financial services companies, telecommunications companies, energy companies, and healthcare organizations.

Ron Zahavi has over 20 experience managing technology and strategy and integrating software and applications to meet business requirements. His expertise includes Distributed Object Technology (DOT), systems architecture, web-based systems, security, and frameworks. Currently Ron is a consulting CIO also in the Unisys Global Business Transformation team. Prior to working at Unisys, Ron was VP of consulting, a CTO and a CIO managing technology across several companies and due diligence of potential acquisitions.

Read More Show Less

Read an Excerpt

Business Modeling

A Practical Guide to Realizing Business Value
By David M. Bridgeland Ron Zahavi


Copyright © 2009 Elsevier Inc.
All right reserved.

ISBN: 978-0-08-092095-5

Chapter One

Why Business Modeling?

A business model is a simple representation of the complex reality of a business. The primary purpose of a business model is to communicate something about the business to other people: employees, customers, partners, or suppliers. This chapter answers the two questions modelers face most often: what is a business model and why create one?

What is a model? A model is a simple representation of a complex reality that serves a particular purpose. We use many models in our day-to-day life: street maps, television schedules, 12-step programs, and furniture assembly instructions. We use models all the time without thinking about them.

Consider an example. You and a colleague fly to Washington, DC, to visit a restaurant. You aren't there to eat; instead your employer is considering buying the restaurant—and the four others owned by the same company, Cora Group—and your job is to evaluate the place and offer a recommendation. The restaurant is called Portia, and it is downtown. Since neither you nor your colleague know Washington, you pick up a map as you rent your car. As your colleague drives, you interpret the map and guide her, telling her when to exit the highway and where to turn on the streets and thoroughfares.

Your map is a model. It is a simple representation of the complex reality of the city. It omits the smaller roads, the sidewalks and bike paths, the streams and electrical lines, the houses and shopping malls, the gas stations and office towers. It has just the few things you need to find your destination: the highways and major streets.

This model is built for a purpose: to find a destination while driving. If you were bicycling, you would use a different map, a model that showed the bike paths and bicycle-friendly streets. You would use a different map if you were taking mass transit, one that showed the train stations and bus routes. And if you were digging up the street to lay fiber optic cable, you would carry yet a different map, a model with the locations of the gas and power lines, existing communication cables, water and sewer pipes, and everything else you might find underground. For the same territory, different purposes require different models.

Perhaps your rental car includes a navigation system. Inside the navigation system is the same kind of model of the city's road network, functionally similar to the printed street map. But instead of you reading the model and deciding where to go, the software interprets the model as your colleague drives, telling her when to turn right and how far you are from your destination. Models can be interpreted by people or they can be interpreted by software. Often a single model is built for interpretation by both people and software.

Just as a street map is a model of the far more complex reality of a city, a business model is a simple representation of the always far more complex business. A business process model is a business model, showing who does what work and in what sequence. A business organization model is a business model, showing how different people and organizations interact with each other.

The art of building these business models is called business modeling. This book is about that art, about how to create business models and how to solve problems using business models.

But first we must disambiguate. Sometimes when people talk about the business model of an enterprise, they are talking about something different from what we mean in this book. When they say "business model" they mean what the business sells. For example, "the business model of Google is selling advertising" means that Google makes its money by selling ads, not by selling automobiles or long distance telephony.

We mean something different. In this book the term "business model" is not just shorthand for what a company sells. Instead when we say "business model" we mean a model that describes the details of a business: its goals, organizations, business processes, or business rules.


Engineers use engineering models and have done so for many years. Every bridge, car, aircraft, and integrated circuit is created using models. Models are created to communicate with customers, to show how the product will look. Models are used to communicate with the engineer's managers to illustrate issues that need management attention. Models are used to communicate between engineers with different responsibilities—for example, to plan how the electronics in an aircraft are to be powered. In engineering, models are ubiquitous.

Software engineering is a newer engineering discipline, and the use of modeling in software is more recent. Starting in the 1980s, some visionaries realized the value of software modeling. Many different modeling languages and methods were developed. Some of these languages and methods had followings, but none had mass usage. In the 1990s market demand increased, and Rational Software Corporation initiated the development of the Unified Modeling Language (UML), an attempt to unify the various modeling languages and methods. In 1997, Object Management Group adopted UML as a standard. UML is now widely used to design applications and systems. The use of UML is a mainstream practice for software engineers today.

Historically, business modeling has seen much more limited use. Of course, organizational charts and accounting models have been used since antiquity, but other than these two exceptions, business modeling has been rare until recent years. Until recently, businesspeople communicated using words, spreadsheets, and presentations, not business models.

Now this is changing. Businesspeople are increasingly using models to communicate. Over the last fifteen years, increasing numbers of people have built business models: models of the business processes of their organization, the goals and strategies, or the policies and rules.

We are seeing a progression from proprietary models and tools to new standards, the same kind of progression that occurred in software modeling in the 1990s. Business modeling is still a niche, but it is growing rapidly. In ten years, we expect business modeling to be mainstream, to be the natural and ordinary way for businesspeople to communicate, much as software modeling is mainstream today for software engineers.

How does a technology such as business modeling become mainstream? What steps does it go through on its path to widespread use? Geoffrey Moore [Moore 1991] describes a technology adoption lifecycle, a depiction of how technologies progress from their inception to wide adoption and use. The technology adoption lifecycle describes who adopts a new technology as the technology develops. Initially a new technology is promising but rough around the edges. It is only adopted by innovators—people who experiment with new technologies, shape them, and improve them. As the technology improves, it is adopted by early adopters, who use a new technology to achieve a competitive advantage before the technology is solid or complete. Once a technology is mature enough, it is adopted by the early majority, a large group of people who welcome new technology once it is mature. After the early majority comes the late majority, who will only use a technology after it is widely adopted by others. Finally there are the laggards who are skeptical and only adopt a technology when they feel the large costs of being left behind.

The technology adoption lifecycle is a good framework for understanding the rise of business modeling, just as it was a good framework for the rise of software modeling in the 1990s. As shown in Figure 1.1, software modeling has penetrated much of the market now and is well into the early majority stage. The market penetration of business modeling is still early. Business modeling will go from a rapidly growing niche activity to a rapidly growing mainstream activity.

What's driving the growth of business modeling? Why is it changing from a small niche activity into an increasingly mainstream technology? There are several drivers for the growth of business modeling. One driver is the changing economics of corporate information technology. As information technology (IT) budgets decline, IT organizations are using business models to align IT initiatives with business needs.


In the late 1990s money flowed freely to corporate IT organizations. Companies raced to develop new applications, to integrate their existing applications and make them available on the Web, and to prepare their legacy applications against the risks of Y2K. Businesses competed in terms of how much they spent for IT, believing that every dollar spent would lead to competitive advantage and increased productivity. Wall Street analysts cheered them on, reporting the latest IT progress of the companies they covered.

Those days of exuberance have long passed. Since 2000, IT organizations have suffered declining budgets. Businesses now compete in terms of how little they spend for IT, preferring to direct their dollars other purposes: new business development, acquisitions, or stock dividends. Every IT expenditure must be carefully justified with the business benefit created by the expenditure.

Since 2001, we have helped corporate IT organizations use business modeling as a way to justify their IT expenditures. Using business models, they have connected the details of their desired IT spending with their business goals, business processes, and business rules. They have used business models to communicate the value of their IT plans. They have used business models to ensure alignment of those plans with their business needs.


Outside the cubicle farms of IT is the larger business that IT supports. During the last ten years, businessees have employed business modeling independent of the IT organization, for their own reasons. One reason is business transformation. Business transformations have become more common since 1995. Business models make those business transformations easier to manage.

Forty years ago, most businesses changed slowly. Martin Mayer [Mayer 1997] tells a story from the early 1970s of a retiring banker who was asked to name the most important business change he had seen in his career. His answer? Air conditioning. From today's perspective, this story seems quaint, a picture of another, simpler (albeit sweatier) time.

Today, business transformations are common. Business transformations include changes of control: mergers, acquisitions, divestitures, and leveraged buyouts. Business transformations include changes of sourcing: outsourcing, offshoring, and many varieties of corporate teaming. Business transformations include changes in strategy and business process. And many businesses reorganize their reporting relationships and organizational responsibilities once or twice each year.

Business transformations are notoriously hard to manage. As a result, many transformations fail. For example, several banks merge, but many mistakes are made in the merger integration. Even years later the resulting bank is not a seamless whole but a motley collection of organizations glued together from the original legacy banks. As another example, a consumer product company offshores its customer support process to save money but suffers quality problems in the transition and alienates some customers. As a third example, an energy services company implements a software package, but the employees reject the new business process that the software package supports, trying to use their existing process with the new software. (This last example is explored in a case study at the end of this chapter.)

Business transformations are difficult because they always involve people. Technology challenges are easy compared to people challenges: ensuring that employees are ready for the change, that they understand what it means to them, and that they accept it. Most failed transformation projects fail for people reasons rather than for technology reasons.


Excerpted from Business Modeling by David M. Bridgeland Ron Zahavi Copyright © 2009 by Elsevier Inc.. Excerpted by permission of MORGAN KAUFMANN. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Table of Contents

Part I: Business modeling
Chapter 1: Modeling fundamentals
Chapter 2: Why business modeling?

Part II: Business modeling disciplines
Chapter 3: Business motivation modeling
Chapter 4: Business interaction modeling
Chapter 5: Business process modeling
Chapter 6: Business rule modeling

Part III: Modeling pragmatics
Chapter 7: Building a model
Chapter 8: Model-based workshops
Chapter 9: Running a workshop

Part IV: Modeling results
Chapter 10: Analyzing a business model
Chapter 11: Simulating a business model
Chapter 12: Deploying a business model

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted September 9, 2010

    No text was provided for this review.

Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)