The Object Advantage: Business Process Reengineering With Object Technology

Description

"I firmly believe that this work... will have a profound impact on governments and corporations worldwide, as they seek excellence, efficiency and profitability. It is an authoritative guide on how to realize the ultimate adaptive enterprise architecture..."Dan L. Jonson, Avemco Corporation

Business Process Reengineering (BPR) is the key management trend of the day. Ivar Jacobson's book The Object Advantage presents a blueprint for re-designing a business according to BPR principles. It uses one method to integrate his work of reengineering a business, its processes and its vital infrastructure the information system. It describes all of the details about a business and its processes by viewing customers as users and business processes as cases of how they use the business "use cases". And it manages the risks involved in BPR by using a how-to method based on object technology, offering concrete guidance in the shape of a formal reengineering process.

Whilst most books tackle the "soft factors" (motivation, management commitment, leadership), The Object Advantage goes beyond this type of hand-waving and offers practical steps to success that include:

• A description that specifies every activity and deliverable involved in the business process
• Deliverables, in the form of business models, that focus on the company's architecture and dynamics
• A process for the development of an information system that is truly integral to the reengineered company

A seamless relationship is created between business model and information system, vastly increasing a company's chances of successfully reenginneering itself - the heart of this relationship is the application of the BPR model and object technology.

Ivar Jacobson's book will be essential reading for any manager contemplating reengineering their business or wishing to understand more about BPR and its practical implementation. It will also be invaluable for reenginnering teams re-designing their companies, employees within a reengineered company needing to understand how their new environment will work and what their role will be, and systems analysts and designers wanting to expand their current applications of object technology into business modelling and business reengineering.

Sample Content

Table of Contents

Foreword by James Martin



Foreword by Dan L. Jonson



Preface



1: Business engineering

• Introduction
• What is business engineering?
• Why do we need business engineering?
• What does the new company look like?
• Business engineering, business (process) reengineering, and business improvement
• Risk management
• The future of business engineering in the corporate world
• Summary
• References
  
  
  
  
  2: What is business modelling?
• Introduction
• What is a model?
• What is a business model?
• What does a business model look like?
• A few words about the traditional way of modelling
• Why do we need business modelling?
• Who should have a business model, and why?
• Working to develop a business model
• Summary
• References
  
  
  
  
  3: What is object orientation?
• Introduction
• Object-oriented models
• What is an object?
• Objects are linked
• Objects can form from aggregates
• Objects belong to a class
• One class can inherit other classes
• A summary
• Why is object orientation necessary?
• Object orientation as a platform for the future
• Object-oriented business modelling
• Summary
• References
  
  
  
  
  4: Object-oriented business engineering - an overview
• Introduction
• Object-oriented business engineering in context
• Business reengineering overview
• The reengineering directive
• Envisioning
• The objective specification
• Reversing the existing business
• Engineering the new business
• Installing the new process
• Iteration
• Business Improvement
• Summary
• References
  
  
  
  
  5: Architecture
• Introduction
• What must you be able to express in a business model?
• Internal and external models of business
• The use-case model
• The object model
• Use case versus objects
• Associations between use cases
• More about use cases
• Subsystems
• Summary
• References
  
  
  
  
  6: Reversing the existing business
• Introduction
• Why reverse engineering?
• Overview
• Building a use-case model
• Building an object model
• Analyzing the result
• Summary
• References
  
  
  
  
  7: Forward business engineering
• Introduction
• Building a use-case model
• Object modeling
• Interaction diagrams
• Information system development
• Verifying the new business
• Summary
• References
  
  
  
  
  8: An example
• Introduction
• What do we want to change
• What kind of organization do we have now?
• New business processes
• An object model of the new business
• Work-flow descriptions
• Summary
• References
  
  
  
  
  9: Building the supporting information system
• Introduction
• What is software development?
• The software-development business-system objects
• System development and business development
• Procuring the new information-system support
• Summary
• References
  
  
  
  
  10: Managing object-oriented business engineering
• Introduction
• Tailoring the method
• Project organization and management
• Project staffing
• Organization staffing
• Reviews
• Summary
• References
  
  
  
  
  11: Scaling up to large businesses
• Introduction
• Two use-case models at different abstraction levels
• Business system areas
• Layered business models
• Summary

Preface

Background

In a very short time, business process reengineering (BPR) has become one of the most popular subjects at conferences on business management and information-systems design. It may become the number one buzzword of the Nineties. BPR, as defined by Hammer (1993) is "the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service and speed." BPR implies that you take a comprehensive view of the entire existing operation and think through why you do what you do, why you do what you do the way you do it, and why... In short, BPR requires that you question the entire existing operation and try to redesign it in a way that uses new technology to serve your customers better.

The number of books on BPR increases all the time. During 1993 and 1994, several important books were published on this subject. Several of these present, in a convincing way, the principles behind BPR. The book that received perhaps the the greatest success within this area is Reengineering the Corporation (1993) by Michael Hammer and James Champy. This book has a very simple, but clear message: if you are to survive, make your company process managed. This clear, articulate message enables the reader to understand the meaning of reengineering, that one must perform it and, in principle, what it entails to perform it.

What is this book about?

This book, however, is not yet another book on these principles. This is a book that describes how you can, in practice, redesign a business according to BPR ideas. The difference between having assimilated the principles and being able to apply them in practice is very great indeed.

The risks involved with performing a reengineering project are significant. There are estimates that 50 to 70 percent of companies that try it fail. I think the risk of failure is even higher. BPR risks fall roughly into two categories: risks associated with the change process, and risks associated with the technology used. It has been estimated that 80 percent of the failures are caused by "soft" factors, such as motivation, management commitment, leadership, the need for expert guidance, and so on. Most books and methods on BPR tackle these soft factors, creating best-selling authors and prosperous consultants.

I am convinced that BPR's success rate can be dramatically improved if its methods offer more concrete guidance. I don't underestimate the need to address the change process; that need remains. But I believe you can almost guarantee successful BPR if you have a formal reengineering process in hand. At Objectory AB, in Sweden, we have lengthy experience in reengineering many companies' software-development organization to adopt an object-oriented process. Our experience is unambiguous: a formal reengineering process and less hand-waving is a must for success. A similar message is also brought to us by James Martin (1994) in his recently published book-series Enterprise Engineering - The Key To Corporate Survival. James Martin not only articulates the basic principles for reengineering, "Change or Die," but he also offers a comprehensive set of techniques, an "integrated engineering approach", to manage the necessary changes in a company.

Ingredients of a formal reengineering process

A formal reengineering process includes:

• A description that specifies every activity and deliverable involved. The process description must be adaptable to the reengineering project. For instance, the size and maturity of the organization and the type of process you are reengineering will influence the process description.
• Deliverables, in the form of business models, that focus on the company's architecture and dynamics. These are different from traditional business models, which fail because they model the company as a computer with a database and a program that manipulates the database. The business model should be presented in an engaging language so that everyone involved - the CEO, executives, process owners, process managers, process operators, resource owners and customers - can understand them, not just the reengineering team.
• A process for the development of an information system that is truly integral to the reengineered company. A truly integral information system is one that is developed in parallel with new business processes and both influences the design of those processes and is influenced by them. This is often the most overlooked element of BPR. IT organizations are generally not as competent as other engineering disciplines in fashioning their product (information systems). The Software Engineering Institute (SEI) at Carnegie Mellon University elstimates that 85 percent of all software development done in 1989 was done without any real method. A good word for this type of work is "hacking." Here is a rich source of failure. A tight, seamless relationship is required between the process that develops the business model and the process that develops the information system. These processes primarily involve concepts, models, tools and documentation. Only if this is done do you increase your chances of success. Establishing this relation enables business people to communicate with IT people and IT people with end users. It also eliminates the separation between the business models and the information system's requirements models and tears down language barriers.

Who needs such a process?

In the first place, the reengineering team needs a formal process to be able to redesign their company. They need tools with which they can visualize, explain, test and evaluate their ideas, solutions, decisions and actions. They need their special, expressive models of the redesigned company. These models are also used by people building information systems. These people must have clear models of the business which the information system is to support. And they must be able to build models of their information system that must be understood by the reengineering people; otherwise, there is a significant risk that you do not achieve the effects you desire.

The people in the new company also need to understand how the company will operate and what their new job will be. This requires special models that are more straight-forward work descriptions than the models that are dealt with in this book. The difference between these models and the reengineering team's models is similar to the difference between a user guide for an information system and documentation of the same information system (design documentation, program code, test specifications and so on) produced by its developers. We will not describe these simpler models in this book.

Our technique

We have called our reengineering technique object-oriented business engineering based on use cases. It stands on the following fundamental ideas:

• Use cases are a simple, natural way to identify business processes. A customer is a user of a company, and he or she uses the company through a business process. Each way of using the company is a use case.
• Object orientation is an excellent way to clarify the inner workings of a company - its processes, products, services, resources - and how those things depend on each other.
• The business model of the redesigned company and the requirements model for the information system must be seamless. This is achieved by pairing object-oriented business engineering and object-oriented software engineering - a use case driven approach (OOSE), which work in harmony. For more details on OOSE see Object-Oriented Software Engineering - A Use Case Driven Approach (1992) by Ivar Jacobson.

Why we have written this book

We have seen it as our mission to present a framework for a formal process for reengineering a corporation. The framework can be used to test ideas in a smaller scale. Furthermore, it can be used as a source of inspiration to develop such a process. But it is not, and we wish to emphasize this, a process itself. A lot more work than can be accomplished by a number of individual authors needs to be done. The various procedural tasks must be refined, the different modelling languages must be described in more detail, guidelines must be developed, documentation must be clarified. You will need support from reengineering tools, which will be very expensive to develop if they are to be used by professionals. These tools must be developed as an integral part of the process; process and tool stick together through thick and thin.

Our Experience

When, 27 years ago, I developed the first generation of what later became object-oriented software engineering, using my technique I made a model of a large company. The basic ideas behind my methodology were inspired by the way that Ericsson Telecom developed electro-mechanical systems. So I used the methodology for designing a small hardware system to make a model of Ericssson as a corporation. Having done that I felt comfortable about introducing the methodology to the development of combined hardware and software systems. This happened in 1967. Since then I have worked primarily in the field of software development.

My methodology has undergone major improvements, the most important of which were presented in my PhD thesis. Every new idea, a new language construct for example, was always first applied to the design of an organization. By using model constructs that were applicable for software as well as for organizations, I considered the constructs to be natural - they would be able to survive because they were not overly technical. Thus the ideas behind this book have been tested for many years, but they have been applied in practice for just seven years. In 1987 we used the first version of object-oriented business engineering within Objectory AB (our Swedish corporation) to develop Objectory, a software development process. This was presented in Jacobson (1987). At that time we used a slightly different terminology. We used the term "factory" to stand for a business system. Objectory was an invented name that combined the words "object" and "factory".

Objectory AB developed in 1989 a specialized version of Objectory to be used for business engineering within Swedish Telecom. The experience from this work and from the work of Objectory AB's other pioneering customers, such as Citibank in New York and Avemco Corporation in Frederick, Maryland, has extended our understanding of business modelling in general, and specifically of using use cases and objects within business engineering. Thus on one hand our experience of software engineering is far less than our experience of business engineering. This will be clear to you as you read this book. Therefore we recommend that you exercise caution when using the ideas presented. Try them out on a small scale before you use them in practice. And, please, if you learn something new, let us know about your experiences. On the other hand, we probably have more experience than most other people trying to combine business engineering ideas with object technology. This leaves us with confidence to write this book.

On the organization of this book

The book consists of three parts:

The first part of the book is an introduction. It consists of three chapters. Chapter 1, Business Engineering, summarizes the fundamental ideas and motivations for BPR. We will outline what the new business will in principle look like, what the risks are, and how they can be reduced. Furthermore we will give our picture of how, in the future, a modern business should manage business engineering issues. You may skip this chapter if you already are familiar to BPR. However, we think that our framework for business engineering in general is wider than BPR and can be used for long-term organization of work on business development. Chapter 2, What is business modelling?, presents the basics of business modelling. It answers the question in its title and explains why you need models of your business. Furthermore, it describes who you should develop business models for. At a first reading you may skip this chapter. However, we believe that the handler concept, models for handlers and the architecture of a model are important contributions to business modelling in general and worth reading the second time around. Chapter 3, What is object-orientation?, introduces the basics of object-orientation in the context of business modelling. This chapter describes the elementary concepts of object-oriented modelling such as objects, instances and classes, associations between objects, and inheritance between classes. This chapter should be skipped if you are already are familiar with object modelling in general.

The second part is the core of the book and consists of Chapters 4-10. Here we describe object-oriented business engineering based on use cases. Chapter 4, Object-oriented business engineering - an overview, introduces our approach. Chapter 5, Arictecture, describes the architectural style of our approach. A business model should emphasize the architecture of the modeled company. In this chapter we present the architectural design that we believe allows the right kind of decisions to be made about the company. Here we introduce use cases to model business processes, and objects to model internal processes. Chapter 6, Reversing the existing business, describes how to make a model of the existing business and Chapter 7, Forward business engineering, describes how you redesign your business to be process-managed. Chapter 8, An example, examines the results of using object-oriented business engineering to redesign Objectory AB, a real organization. Even though Objectory AB is a small company, the basic ideas behind approach are made clear and demonstrated. Chapter 9, Building the supporting information system, gives an overview of object-oriented software engineering, first using plain English and then by using object-oriented business engineering. In this chapter we describe the transition from business modelling using object-oriented business engineering to requirements modelling of the supporting information system. We describe how an elegant object model of the business is related to a use case model of the supporting information system. Chapter 10, Managing object-oriented business engineering, describes how you organize your reengineering work and the new company. The chapter describes the different roles that you will need in your reengineering team, and the different roles that people will have to play in the new company. Planning for the reengineering project is also discussed. Finally, we present some agreements for moving to a process-managed organization between different parties.

In the third part, Chapter 11, Scaling up to large businesses, we describe how our approach can be scaled up so that it can be used by large companies.

Acknowledgments

Our approach has been used in practice by several people. The feedback we have gotten from these people has been of utmost importance to us. In particular we would like to thank Bob Becker, Karl Frank, Dan Jonson, Hakan Lidstrom and Anders Rockstrom. Our former president Mark Broms, has given us a lot of insight into how to implement a process-managed organization, what kinds of roles you should look for, and their different responsibilities. We would like to thank Bjorn-Erik Willoch who has given much concrete advice and insights, and who has supported our writing of this book. Many of our reviewers have given us very valuable criticism for which we are very grateful. We would particularly like to thank Gene Forte and Bengt-Arne Vedin. Furthermore we would like to thank Angela Burgess and David Howe for helping us with the English. The following colleagues of ours have made valuable contributions to the book : Christian Ehrenborg, Johan Aronsson, Per-Arne Gussander, Sten Jacobson, Lasse Johansson, Patrik Jonsson, Kit Molander, Per Sundqvist, Nils Undin and Lars Wiktorin. We are very grateful to Objectory AB for allowing us to publish this work. And, last but not least, we would like to thank our families for their support and encouragement.

Whilst writing this book one of the authors, Agneta Jacobson, gave birth to a little girl Jennifer, which at the same time made another of the authors, Ivar Jacobson, a grandfather. Congratulations to all three!

On behalf of all three authors,

Ivar Jacobson
June 1994
Nybrogatan 45C, S-114 39 stockholm

Ivar Jacobson ivar@os.se
Maria Ericsson maria@os.se
Agneta Jacobson

Updates

Submit Errata