I’ve just published a SOA book through Wiley Press and it is now available on Amazon (hence the catchy title for this post).  Woo-hoo!

The book was a ton of hardwork, but I am quite pleased with the result.  The aim was to address what I considered to be a significant gap in the marketplace — a pragamatic book on SOA that is more business oriented and less technology focused.  So I signed up Bibhas Bhattacharya as my co-author and set out to write such a book. There are vast amounts of resources available for techies that are interested in SOA.  There are even a fair number of resources available for managers.  If, however, you are a business leader, executive, or are actively trying to get the buy-in of one, where do you turn?  What resource is there to help you grapple with important questions like:

• What is SOA really about from a business standpoint?
• When is SOA applicable and when is it not?
• How should an organization go about adopting service orientation?

There are a couple of excerpts available for you to preview the content:

• Excerpt of Chapter 1 “SOA Primer”
• Excerpt of Chapter 3 “SOA Value Proposition”

When you get the opportunity to read through some or all of the book, I would really appreciate your feedback on the content.  I hope that many will find it to be a useful resource to facilitate pragmatic SOA adoption.

The structure of data for your service operations is very important.  This is the primary way that information is transmitted within a service oriented environment.  Moreover, the data model that you use for services will largely dictate service compatibility, interface flexibility, and to some degree will determine the extent of interoperability challenges that you will have as your service catalog expands.

One effective technique for defining the schema for services that I have seen is something I describe as a composite schema. There is a rather large assumption that many service designers make, which is that the schema definition for a service must be atomic.  That is to say that you either define the entire schema inside the service interface file, or define the entire schema in a separate file.  This is fine for the first few services, but what happens if you are six or nine months into service orienting your enterprise and a key aspect of your data model changes (perhaps the ‘customer’ element or ‘product’ element)? You’ll have to go and update the schema for each and every service that uses these elements.  The alternative, is to wrestle with each service design team and get them to agree to a single schema that everyone uses (which becomes bulky and unwieldy).  The answer to all of this, is a composite schema.

A composite schema is one that draws its definition from more than one schema file.  Thus a service interface has some of its data elements defined within one schema and some defined within another (some choose to have a single schema per service interface and simply have that single schema file reference several other schema definition files).  This allows service definitions to be reused and common elements to be defined only once.  When changes inevitably need to be made, this keeps the maintenance overhead to a minimum.

So what should the design of this composite schema look like?  There are several possibilities, but a common approach is as follows:

• Core Data — This schema defines common elements that are consistent across the board within your enterprise.
• Division / Line of Business Data — The next layer tends to focus upon some major segmentation such as industry or business division, etc.
• Product or Service Line – Data structures that are common across a product line or service category are defined in this schema.
• Service Data — Unique elements that are specific to the service are defined here.

Obviously, you could define as many or as few categories of schema as you like.  The goal here would be to minimize how much of a service’s data elements are defined as service-specific data types.  The ideal, would be for 80% or more of the data used within your service interfaces to draw from common, reusable schemas.

Composite schema are by no means revolutionary.  This is a capability that has existed for years.  The problem, of course, is that there is a tendency to craft solutions in a traditional, silo-oriented fashion.  Service orientation drives us to think more about exposing and consuming services across business units, in the broadest possibly context.  It also drives us to compose solutions from existing assets before creating new assets.  All of this leads to a need to work smarter, not harder, and look for opportunities to reduce maintenance costs and more effectively utilize resources.  Composite schemas represent one such technique.

Immediately after the conference last month, I got caught up in vacation and then working with a couple of new clients.  I’m back in the saddle now, and wanted to share some of my experiences.

The SOAWorld conference was very well attended, including the co-located events: Virtualization World and Data Services World.  I was a bit suprised to see that so many of the presenters were vendors rather than customers or practioners.  If this had been my first SOA conference, this would be a red flag for me that SOA is still just a lot of hype.  As it was, I just found it rather odd and a little more of an empty experience than I have come to expect.  Otherwise, the conference was great and it was quite encouraging to see so much energy around things like SOA and Virtualization in spite of the state of the economy.  This gives me great confidence and reinforces a belief that I have held for some time now, which is that SOA and Virtualization make good economic sense.

My portions of the conference went fairly well.  On Monday, June 23rd, I delivered: “A Composable Service is a Good Service”.  The room was packed and that presentation was extremely well received.  The audience was very engaging, shared some of their own war stories and asked for insight on particular service design dilemas that they have been dealing with.  On Tuesday, SYS-CON staff contacted me and asked if I would be willing to step in for a speaker that would not be able to attend.  I accepted, and delivered: “A Little SOA Goes a Long Way” (my SOAWorld presentation from last November).  I also had the pleasure to participate in two expert panels, one of which was held in the Reuters studio in Time Square.  When one or more of those videos become available, I’ll be sure to provide a link.

Presentation deck downloads: “A Composable Service is a Good Service” (PDF)  and “A Little SOA Goes a Long Way” (PDF)

One final comment about the conference is that there was quite a bit of buzz about virtualization as well as “cloud computing”.  I’ve paid a little bit of attention to the virtualization movement, but thus far I have completly ignored cloud computing.  None of my clients are talking about it, and it may all be vaporware (let the cloud-related puns ensue), but it has sparked my curiosity all the same.