The book seems high level, but they enter into a lot of technical detail as well, while not getting involved in a specific technology. The book is used by me as a textbook for graduate students, as it covers all aspects in detail but generically.
The advantage of the book is the way in which components are defined. Business Components are large grained, made up of many parts which they define in layers. This leads to a wider view of the concept, and leads to a re-organization of the development process.
The book is structured around an architecture for development, which establishes a production-line approach. This ensures the component concept is bought into throughout the organization.
This is the only book to focus on large grained components, with a pure business advantage, but explained technically. This is and is not a how to book. It is a roadmap for what to do and how to arrange it, but not the specific technology to use.
There is a lot of detail in this thick book, but it is easy to read. Very unique approach, and the only book describing aspects you will not learn elsewhere. Other books only describe the overall concept. This one tells you exactly how to fit it into your organization, down to how to structure teams! The book is very comprehansive, and really does follow the development lifecycle. You will gain knowledge of : components on a business level, a new lifecycle for development that is very tailored to components in business, techniques for developing systems, from individual components to integrating federations of components form third parties, all the other aspects thinner books leave out.
Much of the material in this book is stuff you've seen before -- the words are different or they're used with different meanings or in new contexts -- but a lot of the concepts are familiar. The book does expand its scope somewhat to cover much more of the "development process", resulting in more of a mix of technical and process information than is typical. This is good, as all too often we tend to separate the technology from the process.
Bottom line: Useful information. Nothing particularly new or revolutionary. Could have been a couple of hundred pages shorter. I frequently found myself needing to re-read something or refer to the glossary to re-discover a definition.
OO has a lot of theoretical ideas which just don't seem to pan out in practice. The Business Component Factory cleary explains why, and shows what really works in the true industrial setting. It is rich in practical advise, and low in BS. Very refreshing for the software practitioner who is frustrated by the OO theoreticians who spout their wisdom from the ivory towers, but have rarely, if ever, had to work on real projects.
Along these lines, the BCF book dispels the OO myth that all classes / objects must be as intelligent as possible, and admits that, in reality, it is often best to have "focus" classes. These classes contain the intelligence of a group of related classes (grouped in a component) and give the advantage of lower coupling for the other classes, and of providing a focus target for process and use case modeling. Hence, Herzum / Sims tie the use case models effectively to classes, then to components.
The BCF book also points out that components need to be "first class citizens" in the UML metamodel, which map from analysis through design into code. As the UML currently stands, packages and (UML-style) components fail miserably in this area. Herzum / Sims show how to get around this deficiency and model and produce large-scale software units (components) effectively.
There is much more to the book than described above, but the above two points emphasize that the BCF book is not afraid to take on conventional wisdom (even the sacred UML), to point out flaws in this "wisdom", and to discuss what really works. Highly recommended, especially for anyone working on large-scale system development.