I’ve just finished reading the Packt Publishing book “Service Oriented Architecture: An Integration BluePrint: A real-world SOA Strategy for the Integration of Heterogeneous Enterprise Systems”.

The book provides a summary of all the major topics in SOA-style integration, written in a clear, vendor-independent, and to-the-point manner.It’s focused on IT system integration, not on the numerous other aspects typically falling under the ‘SOA’ umbrella.

The book makes no attempt to talk about Governance, IT strategy, or specific business processes. I find this refreshing! The scope is entirely application integration, whether data- or process- based. Also, there is no generic discussion of “business services versus application services”.

Basically, the assumption is that you have a good reason to be integrating your systems, that you know what ‘services’ you want to provide, and this book shows you some ways of doing it.

The authors, Guido Schmutz, Peter Welkenbach, and Daniel Liebhart, work (or worked) for an IT integration consulting company based in Switzerland called Trivadis AG, and no doubt the book is drawn from their experience, providing what they call the Trivadis Integration Architecture Blueprint.

The Trivadis Integration Architecture Blueprint describes an integration solution as including “transporting information from the source systems, together with collecting transforming, filtering, forwarding and distributing information, and transporting it to the target systems.”  The integration system is thus an intermediary, a means to an end, not a target or solution in itself.

In the first two chapters the book covers basic integration principles and patterns, including point-to-point, hub-and-spoke, pipeline, and service-oriented architecture, and the base technologies related to them.

Chapter 3 provides an Integration Architecture Blueprint, breaking down integration into application, integration domain (mediation, collection/distribution), and transport. Within each of these domains assembly / deployment, transaction, security/management, monitoring, BAM, QoS, and Governance are mentioned. The bulk of the content in chapter three is around various patterns and layers: the integration layers defined are Communication, Collection, Mediation, Distribution, and Communication.

One of the key points is that data integration is typically process independent, while a SOA integration style is process-based. The implication, then, is that without a strong understanding of business processes SOA-style integration will not be possible. SOA, then, is not about middleware but rather process enablement or improvement.

Chapter 4 describes some implementation scenarios, again at the blueprint or pattern level. Being a blueprint it does not address any product or project -specific constraints.

Finally, chapter 5 provides an overview of the major SOA stacks from Oracle , IBM, Microsoft and an open source framework including Spring. The products covered are the Oracle Fusion Middleware product line, the IBM Websphere product line, Microsoft Biztalk and .NET 3.0 , and the spring frameowrk combined with other open source copmonents. For the data integration side of things the book discusses Oracle Data Integration, IBM Information Management, and Microsoft SQL Server Integration Services.

While the book title mentions strategy, this is not about strategy in the business sense: a strategy might look at what ends an organization hopes to achieve by implementing SOA, how the organization is going to go about it, and how the business will utilise the capability to achieve comparative advantage in the context of its market. If we take strategy in this sense, the book does not cover SOA strategy: rather, it provides a set of tactical options for integrating applications.

I’ve got no problem with the book taking this approach. Too many SOA works try to cover both business and technical concerns to the detriment of both. Simply using the words ROI, TCO and break-even does not make something business-minded!

(ZDNet has a story about this topic at the moment, quoting Patrick Gray as saying that IT strategy documents are usually just “tactical plans detailing various technologies that the company is implementing, considering or watching, and perhaps making a half-hearted connection with what the larger corporation is doing.”)

In summary if you’re looking for a book of integration patterns or blueprints that is refreshing free of hype or grandiose claims, I think the book is well worth buying. It will need to be supplemented with more detailed product-specific expertise, and anyone “implementing a SOA” will need to consider a far broader set of topics than covered here.