Cost-effective software manufacturing is no longer a dream. Already a few organizations have been able to set up their software development to produce quality software cost-effectively and in a repeatable way, using a component-based approach. There is today a confluence of business drivers, technology, development processes, standards, and architectural maturity such that the dream of industrialized software production, which has been a goal of our industry for so long, may at last be achieved.

This book tries to capture and describe the principles, concepts, and practice of mastering the complexities of large-scale software development using components. It is now clear that cost-effective software manufacturing is not only a matter of technology, although, of course, technology is a necessary enabler. Neither is it only a matter of methodology or development process; these are only part of the puzzle. Rather, it requires all aspects of software development to be addressed with a coordinated and integrated set of concepts, architectures, methodology, and more. We call this integrated set of elements an "approach" to software development. This book presents a complete component-based approach, the business component approach, applying and extending component thinking to all aspects of development, deployment, run-time, and evolution, and it focuses on large-scale distributed business systems where high rates of change are the norm.

The business component approach is, we believe, the first approach entirely focused on components across the whole development lifecycle and set of architectural viewpoints. It is largely based on a new, holistic, and perhaps revolutionary core concept that we call the business component, and that addresses distribution realities, dependency reduction, and autonomous development and deployment in a single multifaceted software construct. The approach includes a conceptual framework that brings component thinking into the world of scalable systems and that makes sense of the different component granularities. It also includes a methodology that goes beyond current object-oriented methodologies to provide the concepts and thinking required to address the real challenges of component-based development for the enterprise.

So what’s different about this book? Well, first of all, this book is entirely about components. It is about the conceptual framework, development process, architectures, and practical tips needed to build components, and to assemble systems and federations of systems using components. Second, this book is about building large-scale business systems; not user interfaces only, nor embedded systems or real-time systems. It focuses on business systems for the enterprise. Third, this book is architecture-centric. At one time, some may have thought that a good methodology and process were all that really mattered. Certainly today, if forced to make a choice between a good methodology and a good architecture, we would always choose a good architecture. Of course, a repeatable process could be set up without a good architecture, and poor systems would be able to be built—over and over again.

This is not a marketing book. Building large distributed systems is complex, perhaps more complex than it should be. And component technology is still leading edge. We won’t tell you that component-based development will solve all development problems. On the contrary, we’ll point out the challenges, risks, and costs of adopting and using components. But we’ll also suggest ways to meet the challenges and reduce the risks and costs. Many of the concepts and guidelines presented are a source of golden rules, tips, and tricks for any practitioner in the distributed system field.

Neither is this book another treatise on object-oriented development. We believe that object-oriented development is but one of many factors required to build component-based systems. But we’ll talk about how object orientation is important in building components, and how object-oriented principles are applied throughout the development lifecycle in the context of the overall component-based approach.

This book is, first of all, for anyone involved in, or learning about, or interested in the application of component thinking to business software development, and in the underlying architectures, processes, design techniques, and patterns that are necessary to support the coming revolution in software productivity. But it is also important for those interested in cost-effective software manufacturing and in building business solutions today.

It is particularly important for the following people:

The book assumes a basic understanding of both the main principles of software engineering and of the main concepts of the object-oriented approach. It is organized into three parts: the conceptual framework, setting up the business component factory, and software manufacturing.

Part 1: Conceptual Framework. Chapters 1 through 6 describe the concepts used in reaching the goal of high-productivity manufacturing of rapidly evolving distributed component-based systems. This part is organized according to the various levels of component granularity, from smallest to largest, and it presents the concepts required to assemble systems and federations of components.

Part 2: Component Factory Set-up. Chapters 7 through 10 describe how, using the concepts described in the first part, the factory itself can be built—that is, an efficient manufacturing capability for the various granularities of components. This part of the book is organized along the lines of the architectural viewpoints presented in Chapter 2.

Part 3: Manufacturing Component-Based Software. Chapters 11 through 13 describe the main modeling and design considerations for component-based systems and, in the concluding chapter, briefly discuss some of the main considerations for a transition to component-based development.

Both authors were separately involved in developing business systems using object-oriented technologies in the 1980s. Object-oriented approaches seemed so powerful, but after a while it became clear that something was missing. The expected gain in productivity, high levels of reuse, and ability to master complex development somehow did not materialize.

In search of more productive ways of developing systems, Peter, together with many excellent colleagues, started around 1992 to work on components and methodologies for large-scale component-based development. This involved architecting, designing, and developing what was probably the first component factory, which included a home-grown technical infrastructure for large component-based systems and the creation of a methodology tailored to the needs of this kind of development. It also included the development and deployment of large-scale systems using this methodology and technical infrastructure. He first defined the business component concept and a first version of the business component approach in 1994, and he successfully applied it to large-scale software development. In 1995, he started to capture many of the concepts for a future book.

Oliver first met object technology not through languages, but through trying to ease the lot of the application programmer in the early days of distributed systems with PC front-ends. Indeed, his first use of object-oriented thinking was in creating real pluggable components for PCs in the late 1980s. Having been involved in distributed systems since the mid-1970s, his next step was to consider the distributed business system as a whole, which led to his development of the four-tier and distribution domains concepts. Following this came a period of technical development that produced one of the first "business object" commercially available component infrastructures, running on multiple platforms, supporting both object-oriented and procedural languages, and giving pluggable binary component capability to large-grained business objects.

In 1996, Systems Software Associates (the Chicago-based ERP software producer) initiated a project, in which both authors were involved, to build a truly revolutionary software component capability for its flagship product, BPCS. The project, through the sponsorship and vision of Riz Shakir and the leadership of Wojtek Kosaczynski, brought together a world-class team, which embarked on building nothing less than a business component factory. This experience, with the contributions from the great team working on the project, permitted to the authors to refine, mature, and improve the business component approach to its current form.

In producing this book, and in developing the concepts it presents, we must first thank our wives and families. They have loyally supported us as we slaved over keyboards on sunny weekends, when we should have been with our wives, or playing with the kids, or participating in other family activities. Thank you, Simona and Heather, and thank you, Solveig, Viveka, David, and Richard.

Many of our colleagues and friends have made important contributions to the concepts presented in this book, and our debt to them is immense. Some of them may not realize how much they have helped because the comprehensive approach that this book aims to present derives very much from numerous discussions in many circumstances—a thoughtful comment is later recollected and provides an insight to the solution of a problem. To the extent that this book contains any errors, however, we claim them for our own.

From the many who have contributed, it is perhaps invidious to name some and not others. Nevertheless, for the major part they played in realizing, in advanced software, many of the concepts expressed in this book, we would especially like to thank Peter Eeles, Neil Howe, Don Kavanagh, Wojtek Kozaczynski, Phil Longden, Boris Lublinsky, Riz Shakir, Steve Terepin, Dan Tkach, and Rick Williams. And for their many insightful comments on early drafts of the book, we are indebted to Robert Mickley and Jeff Sutherland.

In addition, for their direct and indirect contributions and teachings, Peter would like to thank Jean-Claude Bourut, Rich Burns, Ludovic Champenois, Stefano Crespi-Reghizzi, Alberto Dapra, Carlo Ghezzi, Charles Haley, Hans Gyllstrom, Francesco Maderna, Radouane Oudhriri, Paul-Eric Stern, Ed Stover, and Tom Vayda. For their many insights, freely shared at OMG and other places, Oliver would like to thank Martin Anderson, Cory Casanave, Fred Cummins, Dave Frankel, Steve McConnell, Kevin Tyson, and Dave Zenie.

A Personal Note from Oliver Sims. When I first met Peter Herzum, my thinking on the nature of distributed components (DCs) was reasonably advanced (at that time I called them "cooperative business objects"). My colleagues and I understood well that a DC was a pluggable component that realized a business concept, that there were different kinds of DCs at the different distribution tiers, and the four tiers themselves were defined and had been tested. By that time, we had also had considerable experience producing middleware that provided the required level of abstraction for functional programmers, had supported and built DCs in a range of languages (both OO and procedural, compiled and interpreted), and had seen our technology proved in operational systems.

Although I knew that more—much more—was needed beyond the technology alone, neither I nor anyone I had met had a really good understanding of the required methodology, development processes, and project management techniques for scalable development that aimed to map business concepts isomorphically to independently deployable, larger-grained software components. Peter made a major contribution to those things, but he also provided two other things, perhaps even more important. First, while I knew that somehow there had to be a link between a real-world business concept and a component that executed at run-time, the thinking at the time was incomplete, especially regarding development processes. There was a crucial missing link. Peter had the answer to the missing link—a single coherent concept that gathered up not only physical distribution, architectural viewpoints, and development lifecycle factors, but also provided for project management approaches, and at the same time strengthened the mapping between a single business concept at requirements time and a single independent deliverable at deployment. This concept—the business component—is at the core of this book. It gives its name to a whole new approach to developing distributed business systems large and small—the business component approach. Second, the approach to leveraging the power of business components to place software production on an industrialized basis was Peter’s.