Your SOA is JABOWS (Just A Bunch Of Web Services) and I can prove it

Are you ready to answer this challenge... can you prove that your Service Oriented Architecture (SOA) is NOT JABOWS?

 

I'm not asking from the standpoint of technology (are services secure, available, composable, etc) but rather from the business. In other words, if the business wants to achieve flexibility through the SOA, do the available services represent the correct interaction end points to accomplish that goal?

SOA saves money in some environments (especially ours), but it’s greatest value happens when the business can add a capability to meet a competitive opportunity quickly and inexpensively. Speed is important. Cost is important. A Good SOA is structured to deliver on that promise. In my opinion: Evaluating “how good” a SOA is means modeling out the competitive opportunities that are actually in the corporate strategy and seeing if the SOA can react to both expected and potential competitive moves.

If you look at the ‘universe’ of business processes, you get a spectrum from “changes rarely” to “changes frequently”. If you place that on one axis and on another, you place the spectrum of “happens occasionally” to “happens frequently”, you get a grid like the one below.

 

IT projects provide tools for business processes. They automate parts of a business process or collect information or reduce errors. The point is… which processes? In the past, traditional IT only succeeded with the processes that changed rarely. Therefore, the greatest successes were in the upper left, with a lot of projects happening in the lower left (a pragmatic, “pick your battles” approach… solve what you can successfully solve). The problem is that there is a long list of business processes that occur frequently but that are more difficult to automate because they change frequently. (the upper right).

That is the SOA sweet spot. To annotate the prior diagram…

 

So, if you want to know what a GOOD SOA is, look to see if the services cluster around the data elements and detailed activities needed to automate frequently changing business processes. Certainly, an organization can START from their position of strength on the upper left, but if they never move to the upper right, then the business flexibility that is needed, and which SOA can address, will never be achieved.

So, to evaluate how good a SOA is, you need to ask:

A. What business processes occur frequently and change relatively frequently?

B. Of those processes, which are the most critical opportunities for automated tools to provide value?

C. Of those opportunities, which are aligned to corporate strategy? (feedback loop to executives here… opportunities missed)

D. Of those aligned to strategy, what data elements and activities are needed to compose them in a flexible manner?

E. Of those atomic elements, and required infrastructure components, how many exist in the enterprise SOA?

Step E produces a number. The closer that number gets to 100%, the better the SOA is.

Comments

• Anonymous
  January 18, 2007
  I'm missing something. How can something that “changes rarely” also “happens frequently” I'm assuming that I'm missing a distinction. Do you have some object examples to point to so I can tell what rare change happens frequently?

• Anonymous
  January 19, 2007
  Imagine you are a small online retail store selling only music players.  The process 'take an order' happens very frequently.  So does 'receive a stock shipment' and 'ship an order'.   However, if your store is responding to the ever increasing hype in the music player business, you can get an edge by learning about your customers wants, and perhaps contacting folks when the model that they want appears on the market to get a pre-order.   So you try that, but it doesn't work.  Then you come up with the idea of holding contests and a betting pool on your website dealing with features that 'should' be in the product.  But that doesn't work either.   So you start bundling players in with iTunes cards, and sales goes up.  That's the case of a frequently occuring process (take an order) changing often (three times, in this example). To do this well, you need isolation between the notions of 'present an offer', 'bundle stock', 'collect customer desires', etc.  You mix and match until you get it right. This is where SOA wins.

• Anonymous
  January 22, 2007
  Ok, I think I have it. And if you have a process that happens rarely, but changes frequently, you might just want to leave that as a manual process simply because if: You have one order per quarter and The model changes on a weekly basis Then there is a negative justification (read "no business value") to carrying stock in that genre. I'm mixing my metaphors horribly but I get it now.  Thanks.

• Anonymous
  January 23, 2007
  Sounds like you got it.  Yes, a process that occurs rarely but changes frequently should remain a human endeavor using general IW tools (like Office and Excel).  ("Drafting Purchase Documents to Acquire Another Company" usually falls into this category, as do most other forms of fine art).

• Anonymous
  January 25, 2007
  What happens when your process does not change all that often but decisions (or decision services) within it do? I think you need to consider both process agility and decision agility (http://www.ebizq.net/blogs/decision_management/2006/09/is_a_bpm_suite_enough_to_deliv.php). Achieving "Agility" is more complex than just SOA or BPMS (http://www.ebizq.net/blogs/decision_management/2006/07/achieving_agility_some_notes_a.php). Decision Services in your SOA can deliver an additional layer of agility within your processes - check out this article on SOA and rules http://www.soamag.com/I2/1106-2.asp. JT

• Anonymous
  January 25, 2007
  The comment has been removed