Realizing eBusiness with Components

Rating:
Summary: Great approach to design, development & implementation
Review: This book is a well written guide that crams a coherent approach to developing e-business systems into 233 pages.

The theme of this book is component-based development (CBD), which I personally found to be an effective way to design complex systems that can be implemented in a carefully managed manner. The concept of an architecture that is based on "plug-in" components is powerful in the abstract. Like many abstractions CBD could have remained as a theoretical approach had the author not skillfully laid out a map to transforming these abstractions into reality.

The book jumps right into aligning business to IT, making a business case for CBD, and how to plan e-business projects using a CBD approach. It then delves into details that clearly show this isn't another book on theory or unproven ideas.

What sets this book apart from many books on architecture is the fact that support and service delivery are interwoven into the approach, which takes architecture out of the realm of "ivory tower". The author's approach is pragmatic and remains focused on business requirements and delivering systems that have real value to end users. As such, this book provides invaluable advice on how to plan for operations, administration and maintenance of systems after they have been released into production.

While business and production issues receive thorough treatment, this book sticks with its theme by providing a realistic framework in which to design an architecture. It then shows how to use the design as the basis of e-business system development and deployment. This is reinforced by the way the book is laid out to support project stages and phases.

I discovered a lot of great ideas between the covers of this slim book making it, page for page, one of the most valuable books in my library.

Who needs this book? Architects and cheif technical officers, of course, but I think anyone who is assigned to manage development, testing and release of e-business systems should also read it. Project managers who are tasked with managing e-business implementation projects might find the information on managing e-business projects to be the difference between success and failure.

Rating:
Summary: A useful book for all trying to model enterprise systems
Review: This is a very good, practical book. I found it very readable, with just an appropriate level of textual detail in most cases. It's the first book I read which tries to tackle the problem of modelling and understanding Enterprise-level system interactions. If anything, Paul sells it a bit short by tying it to "e-Business", since a lot of the ideas and disciplines can apply to less forward-looking Enterprises who are trying to solve traditional integration problems but who may not identify with the e-Business tag.

The early part of the book discusses the principles of component-based development (CBD), and how this can be combined with process modelling to both help improve the business, and to provide a clear model for the systems needed to support it. Importantly, Paul sees the development of both business processes and systems as something which must happen progressively, so neither has to be the subject of "big bang" changes.

The next section of the book discusses the different types of components, and their role in a typical architecture comprised of both new and legacy systems. Paul then introduces his "CBD Process Framework", a way of defining components and then "provisioning" then by the most appropriate combination of new development, purchasing and re-using existing assets.

The core of the book takes a typical business process (car rental) and develops a worked example of the various business, logical and physical models which are required to define the component architecture. The models are each taken through several stages, corresponding to an evolving e-Business process and a system which is growing incrementally. This is much more realistic than presenting the final model "as is", and allows much better understanding of how the model develops. In many ways this is the part of the book which delivers the greatest real value.

The final part of the book discusses different provisioning and funding strategies for CBD, and how an e-Business team should be structured. There's a lot of good stuff here, which may be very useful to someone new to object- and component-based development. However if I'm honest I found this less useful, since there are better specialist books on this subject and it doesn't hold the interest as well as some of the earlier sections.

As an Appendix, Paul presents descriptions of all the major component technologies, and all the major UML-based modelling techniques. This could be a valuable reference for anyone.

I have one slight reservation on the book's core - Paul follows a convention in which an "interface" is a collection of types, and says that "by convention" the interface includes access to all the types. This is a bit different to the Microsoft model, for example, and may make it more difficult to establish good navigation around the object model, or to support "stateless" models. However, this is something to be aware of rather than something which should detract from what is otherwise a very useful tutorial.

I like this book. The worked examples of developing the e-Business model are excellent, so much so that I now recommend this book to anyone trying to model such things using UML.

...

Rating:
Summary: Good books don't have to be thick
Review: When I got this book I was was amazed by how thin it was - a mere 230 pages. What made me frown even more, was that on first inspection I determined that only 175 pages was main text and the rest was appendices.

After reading the book I realize that it is above properties that help make it the excellent book it is. The appendices contain information about technologies (which could date quickly) and modeling techniques (which possibly don't become obsolete so quickly but could be supplemented as new techniques become available). This makes it a very easy read for people who are already familiar with the modeling techniques or technologies. It effectively removes the need to discuss too much about the diagrams in the text itself.

The main text moves fast, stays relevant and focused thus yielding a very thin (in typical IT terms!) book. It starts immediately by discussing e-commerce, its business relevance and discussing the issues of aligning business and technology.

The book particularly impress me by maintaining its business focus throughout. The development of components is tightly coupled to the business process that is being automated (or newly developed). In this respect it propagates an approach whereby a component-based architecture is incrementally developed. The focus continually stays with providing real value to the client.

Management issues (project management, ROI etc) are also addressed in the later chapters in the book and adds significant value to the text especially if read by potential project managers.

In my opinion the book is a must read for any prospective designer/developer/project manager of e-Business systems.

Rating:
Summary: Advice on how to make a hard but necessary move
Review: While the recent downturn in the dot-com curve proves that e-business is just old business with an asterisk, there are some fundamental differences. The two most foremost are that e-businesses are technology driven and changes happen at a speed that can leave you codeless. When designing and constructing the technology solution, it is essential that you cut sufficient slack so that it can undergo substantial changes very quickly. The most realistic way to do this is to build generic pieces that can be interchanged easily and where modifications can be done in one piece that are invisible to all others. This strategy is of course the extensive use of software components.
However, like so many other solutions, the initial steps are the hardest. Not only is it necessary to retool development to the component model, but the initial design will almost certainly be slower to develop than any other. However, once done, there is a cascading effect that will lead to reduced costs for an extensive period of time. The how and why of the ways all this works are well-documented and explained in this book, largely from a management perspective. By far, the most effective chapter is chapter 8, "CBD Funding Models."
The decision to move to component based development will of course be based on return on investment (ROI) considerations. Given that the standard in the industry is that the up-front component development cost will be 150 -250% that of traditional development, there are significant justification hurdles to be surmounted. Since it is unlikely that such an increase will be easily accepted by those who control the budget dollars, it will be necessary to justify the changes using other funding strategies. These include spreading the cost over several departments and the selling of the components to other companies. While not all solutions may be feasible, at least the options are explained so that sound strategic decisions can be made.
The move to components is as much a cultural as technical move. To do it successfully, it is necessary that all players be committed, capable of communicating openly about the future and understand that the complete benefits will not be seen for some time. All of this requires that effective team structures be built, which is the topic of chapter 9. Building an effective team in the e-business world is quite different than the traditional, hierarchical team. Flat organization with direct communication lines among all the members is essential if the desired speed of execution is to be attained. Things sometimes move so fast that a delay of even a few hours can have serious consequences. Such an organization is described in detail, along with a recommended size and a list of the members and the roles that they will play. As is emphasized, not all of these roles are necessarily full-time, so it is possible that one person may fill more than one or one person may fill the same role in more than one team.
While moving to components is hard, not doing so is probably worse. Given the chance and with proper organization, it is possible to do so with enthusiasm, effectiveness and a sense of pride that will help retain your workers for the long term. That requires a plan, and this book will help you make a good one.