(A note on SOALogix inaugural blog entry)

Up until now I have resisted throwing in and adding yet another finite opinion on exactly what SOA is; but now here I am. Two events have conspired to bring this change about:

The first is that we just changed our brand to SOALogix. It now seems appropriate for me to suddenly start blogging my adventures, learning and journeys related to SOA. As we have been practicing SOA principles and building SOA technologies and solutions since 2003, there are many adventures to be retold.

The second is that as part of our re-branding, our new website sports this spiffy blog feature that needs to be fed interesting content on a regular basis and again, it seems appropriate that I should be here.

You will also find upcoming entries from our technical, consulting and project services staff on a variety of topics covering SOA, business process integration, enterprise projects, composite applications and more.

We hope that everyone finds this forum to be interesting, relevant and available for open and sincere community dialog.

An SOA Reference Model

Since there is no single “master” specification for an SOA, we and everyone else wade through a plethora of overloaded terminology and expectation alignment. Terms like “choreography”, “workflow” and “integration” have different meanings to almost everyone and the question of dictionary invariably comes up during SOA related discussions.

Over the years, a few organizations have published “SOA Reference Models”, each with its own unique qualified rendering of what an SOA looks like. There are models that come from many different aspects: logical architecture, interface architecture, standards architecture, etc. The problem we have is that they mostly push an agenda and some rely on visual metaphors to “vendor enhance” the model or are based on a vendor specific product offering.

We could at least standardize the SOA dictionary for ourselves and create a way to communicate to our customers where our software capabilities and strengths for their situation are. To that end, we looked at all the SOA Reference Models we could find on the Internet, got all our senior technocrats together with double rounds of espresso and hashed out what we think is a solid abstraction for an SOA Reference Model. To all those who have gone before us, we give thanks for their work as the prior-art here was instrumental in shaping our own thinking and work product.

The first thing we wanted to accomplish with our reference model was to establish the concept of service domains bounded by specified separation of concerns. Of course, attempting to do this naturally led to a two hour SOA dictionary discussion, more espresso and ultimately a much refined SOA terminology set for our model.

After the preliminary work, we thought that producing the model would be cake, but again we were foiled in our initial attempts. The first person outside of the modeling team we showed the picture to said, “Oh, SOA is a layered architecture” and that is not what we wanted at all!

So back to the espresso machine, and then to the proverbial and literal drawing board. After a few more rounds, a few test subjects and one very unsuspecting sales person we arrived at our final reference model work products and were able to clearly communicate at least to each other what SOA looks like to us.

Even if you don’t agree with or like our model, I highly recommend that you get one, or put in the time to make one, and then educate everyone involved in your SOA effort on what it is and what it means. You can always revise the model as you go and there are enough examples (now including ours!) running around on the web to bootstrap the effort.

The picture below is the SOA reference we model finalized on. Its hard not to, but don’t look at the vertical as a “stack” or layers. Put your self directly on top of the picture and look “down” on it so that the ESB is “underneath” the service domains.

The one compromise we made on our level of abstraction for the rendering is to show an ESB in the diagram. We did this mainly to show that in our view, ESBs as well as SAP’s ESA provide “Backplane Services” to an SOA; which is different from the central role they are given in many other representations.

We also tried to stay with popular terminology semantics as much as possible, but there are a couple of notable exceptions. Remember that we wanted to create our service domains for our model based on a separation of concerns independent of any specific product offerings, technology packaging or specific standards implementations. That information we have captured in lower level models which are mapped up to our reference model.

The most notable distinction of our model is that we have separated out the “workflow” domain into Choreography services that invoke primarily BPM services and Information Services. We have carried this concept forward into our model out of the EA world from Zachman’s EA framework, where BPM and Workflow are clearly shown as separated concerns.

Another specific area we felt needed to be provided its own concern is Canonical Data Services. While most models contain an Information Services category, “integration server” is implied by the context in many. We combined these two service categories into a single service domain as they deal with different aspects of providing information services: integration and mediation services for information products consumable by business and user level services. This formalization of the business contextualized information provides a clean de-coupling from individual system’s data structures and fine-grained services and message formats from business rules, workflows and business processes without boundless transformation business logic scattered across architectural components.

We purposely left out the Portal component found in many of the published models because we felt that it was too specific a delivery technology to show in a reference model. We landed on Display/User Interactivity Services to allow for a wide variety of interpretations for presentation and activity implementations beyond the “corporate portal”. There are mash-ups, cell phones, cell phone mash-ups, streaming clients, etc that can all leverage services.

So that’s the SOA reference model we came up with, and it is my SOA reference model. By that I am not asserting personal ownership, but rather personal buy in. I use this model on a daily basis and carry it around in my head. I have found that it makes navigating the land of SOA more manageable and (hopefully) more objective while at the same time providing the foundation for a standard SOA dictionary, at least for 1 organization.

Like I said back at the beginning- if you like our model, I hope it brings you value; if you don’t like our model, go make your own!