The Object Advantage : Business Process Reengineering With Object Technology (Addison-Wesley Object Technology Series)

"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.

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.

Dr. Ivar Jacobson,Vice President of Business Engineering, is the inventor of the OOSE method, and he is also the founder of Objectory AB in Sweden, which recently merged with Rational Software Corporation. Dr. Jacobson is the principal author of two influential and best-selling books Object-Oriented Software Engineering--A Use Case Driven Approach (Computer Language Productivity award winner in 1992) and The Object Advantage--Business Process Reengineering with Object Technology. He has also authored several widely referenced papers on object technology. One of the most famous papers is his first OOPSLA '87 paper entitled "Object-Oriented Development in an Industrial Environment," which presented the first truly object-oriented method ever published. Ivar Jacobson's use-case driven approach has had a very strong impact on the entire OOAD industry, and he himself has become one of its "icons." Consequently, he is a frequently invited keynote speaker and panelist, debating OOAD topics with colleagues and methodologists such as Grady Booch, Jim Rumbaugh, Steven Mellor, and Rebecca Wirfs-Brock at major OO conferences around the world.

He is well known for his pioneering work and more than 20 years of experience in using object methods for the design of large real-time systems. His early object-based design technique has evolved into the international standard ITU(formerly CCITT)/SDL.

Dr. Jacobson also regularly serves on the OOPSLA, ECOOP, and TOOLS program committees, and he is a member of the advisory board of the Journal of Object-Oriented Programming.

In 1994, Ivar Jacobson received the first Swedish Computer Association (SCA) award (the Kjell Hultman prize) for "extraordinary achievement in promoting efficiency and productivity in the development and use of information technology."