For anyone looking for a groundbreaking development architecture, don’t bother with service-oriented architecture (SOA). Early in the book, the authors admit: “The concepts of service-oriented software and architectures based on such software have existed in some form for a number of years.”

The first chapter provides several definitions of the term service-oriented architecture, and then the authors provide their definition. “A service-oriented architecture is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components—services—that can be reused and combined to address changing business priorities.”

The authors contend that business requirements are evolving at such a rapid pace, corporate executives are being forced to more closely align their information technology (IT) resources with their business requirements. Their solution is a monolithic architecture that must be sold to all levels of a company from executive management to programmers. But even a neophyte IT professional knows that no matter what methodology is used, IT is expected to work closely with other departments to help meet business goals and provide technical solutions to meet business requirements. But, the move to use SOA will likely face resistance, possibly ending in a small-scale implementation. In this case, any possible benefits of SOA will not be recognized.

The majority of the book is focused on using SOA to make services available to customers via the Internet, commonly referred to as Web services. In some cases, it makes sense to include the services of vendors to meet the needs of customers. According to the authors, SOA concepts can also be used in traditional software development. Their list of project phases follows the waterfall methodology using standard terminology, but, in the discussion that follows, they identify new terminology. For example, analysis and design becomes modeling.

A key aspect of SOA is the enterprise solution asset (ESA). An ESA “describes common problems and difficulties that occur frequently in architecting and designing enterprise solutions, and it proposes solutions to address them.” Once created, ESAs are categorized and kept in a catalog. Then, anyone in the enterprise can access this catalog to reuse, with modification if necessary, the solutions recommended.

Reusable code has been the holy grail of the IT world for many years. The hope is that eventually, services will be interchangeable and replaceable, similar to the way parts are easily interchangeable and replaceable in manufacturing. The SOA architecture does allow exceptions for unique business needs. And if the past is any indication, IT managers will want the majority of their development projects designated as exceptions.

Since all of the authors are employed by IBM, it is no surprise that IBM products applicable to the subject of a section are mentioned, for example, IBM WebSphere.

Chapter 10 contains two case studies. These provide an overview of implementations of SOA, with one project creating Web services and the other focused on traditional software development. The final chapter provides a summary of SOA guiding principles and future directions. In the latter section, the authors admit that much of what is described in the book is in an early adoption phase.

The flow of the book makes it difficult to read. Some parts of it have more of a philosophical tone than a practical one. It appears the authors each wrote separate parts of the book that were then cobbled together. In the end, though, none of this provides any real improvement over current methodology and programming techniques. SOA can be implemented incrementally, but it will have to be shown to be a significant improvement over current methodologies before it will be worthy of widespread implementation.