SOA Best Practices: A Book Review

"Enterprise SOA: Service-Oriented Architecture Best Practices" is by Dirk Krafzig, Dirk, Karl Banke and Dirk Slama. These are three Germans from the banking and insurance sector who present a wealth of practical experience to the reader. They attempt to talk about SOA without favoring any particular technology which is hard to do. I would still say that there experience with EJBs and CORBA provided a certain slant to the discussions however they were also using SOAP, WSDL and XML examples in their discussions.

The book had the feel of describing the real world rather than discussing and ideal world. By contrast the book by Erl was from a Web Services purist's point of view and glossed over some practical issues like what to do about user interfaces, performance problems and legacy transaction integrity. On the other hand Erl had the advantage of not having to describe the concepts in terms of differing technologies.

Legacy integration issues were covered well by Krafzig et al. There was an excellent chapter on process integrity and a good chapter on infrastructure issues like Scalability, Interoperability and Security. They covered the range of process integrity techniques from "Eyes Closed and Praying" to "Two Phase Commit over a heterogeneous environments" and "SAGAs with complex compensation graphs".

Krafzig et al provide more of "Horses for Courses" approach. Their approach does not necessarily advocate the same approach for fine grain and course grain services. Their approach even accepts that synchronous as well as asynchronous service buses might need to work side by side.

One theme was the importance of the registry and repository for SOA. The book gives some practical suggest about what to put in these stores. Another theme is the importance of governance of the development process. This theme is taken up in a later chapter which discusses SOA-driven project management, configuration management and testing. The book also discusses a thin-thread approach to software development. This is accompanied by discussions on how to fund SOA development and how to manage the risk of these initiatives.
The climax and conclusion of the book is four case studies. These are real-life examples with solutions that had to meet compromises and struggled with incorporating legacy environments with their solutions. It would have been nice to have an example that was not a finance company but it seems that is where the money is when it comes to SOA (and any big information systems for that matter).

The book did not provide a motivating definition of SOA although the thoughts on architecture I found enlightening. Such as "architecture … is designed to last longer than one or two of these technology innovation cycles" and that its purpose is to simplify development. How easy it is to forget that our new inventions in IT are just to make the world a simpler place.
I enjoyed this book. It was good to read a European context on SOA. They referenced Niklaus Wirth (a hero to anyone who did computer science when I did it) a couple of times and referred to other European IT Gurus which is refreshing break from the US IT heritage. I commend it to those who want a technology-agnostic look at SOA.

References
Erl, Thomas, Service-Oriented Architecture: Concepts, Technology, and Design, 2005 Prentice Hall

Krafzig, Dirk, Banke, Karl and Slama, Dirk, Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall, 2004

Hype Cycle for Application Development

I recently read an article from Gartner Research (Hype Cycle for Application Development, ID Number G00147982). Generally I find the material from Gartner great. It's reasonably independent and provides the right level of detail for me mostly. It costs alot to access so you have to find an employer or university to part with the cash to subscribe. I recently heard from a vendor of mapping software that said Gartner wanted $40k to do a review of their software and include them in an appropriate "Magic Quadrant". So their independence is not absolute.

The "Hype Cycle" article was a good summary of what is happening in software development today and the relative maturity of a number of technologies, concepts and product sets. It was handy to brush up on some acronyms. ARAD SODA apparently means Architected Rapid Application Development Services-Oriented Development of Application. You can also have Architected, Model-Driven SODA. Now that seems to be putting all the current buzzwords together in a couple of long acronyms. When did 'architect' become a verb? Any way now I know that what I am trying to do at work is a SODA and, even though I quibble about the grammar, I want it to be architected.

The article itself was written by a number of contributors and provide a mix of succinct insightful writing and some marketing waffle. One of the less well defined concepts was Enterprise Information Management (EIM) which is its 'technical trigger' phase rising to a 'peak of inflated expectations'. I find EIM a little similar to Knowledge Management (KM) which in turn can be almost anything related to the enterprise. KM can be include building design, HR practices and telephone lists. It was one of those definitions that a like to ask "What is it not?" and more to the point "How is it useful?". EIM, like KM will be more an approach to looking at the whole organisation. This may bring up some useful concepts. KM seemed to spawn the concepts of tacit knowledge and explicit knowledge. Before that people talked about the "stuff in our heads" and the "stuff written down" or for the geeks "biological data stores" and "digital data stores". Tacit knowledge was a vaguely useful concept. I don't think I'll championing my organisation to do EIM.

One of the more insightful parts of this article was the analysis of SOA by Roy Shulte and Yefim Natis. I am glad to see SOA is climbing the 'Slope of Enlightenment'. Something I have been struggling with is how many services my organisation has developed. I had assumed the number was zero until one of my senior developers showed me a list of all the EJBs he had built to access mainframe data and said "look at all these services". This did no fill me confidence. In a service I expect to see late binding, loose coupling, an XML interface, some aspect of self description and the ability to integrate using business process technology. Most of the SOA definitions I have seen are pretty vague and some a clearly business focused. These did no give me the ammunition to say that this was not the type of service I had in mind. The definition added to what I had seen previously.

"An application is an SOA application if it s modular; the modules are distributable; software developers have written or generated interface metadata that specifies and explicitly contract so that another developer can find and use the service; the interface is separate from the implementation (code and data) of the service provider; and the services are shareable..."

This should give me something to work on when I say I want this sort of service. Of course I could just say I want a web services with a SOAP interface. That might be easier. I get told SOA is not just web services though.

Hype cycles have their detractors but in general these hype cycles help see the big picture. IT shops are bombarded with a huge number of technologies. We are made to feel inferior by the marketers and our more progressive staff that we are behind because we are not employing the latest tools and techniques. The bottom line though is that many of these tools and techniques are not mature. They do not actually benefit all organisations and it takes time for conservative organisations to reap any benefit from investment some products that are billed as the next big thing.