Expert Insight: Fralick’s Technology Insights
 

 

By Mark Fralick, Technology Editor, Supply Chain Digest

 

 
     
  May 16 , 2007  
 

SOA It Isn’t So….

 
     
  With All  the Hype around Service Oriented Architecture, Who Can Tell What’s Real in Supply Chain Applications?  
     
 
Fralick Says:
The problem is that the term is now bounced around so often that it is easy for vendors to say “We’re SOA,” declare victory, and simply move onto the next slide.  Are they lying? Who knows? 

What do you say? Send us your comments here

There is an incredible amount of noise and hype in the supply chain space right now about “SOA,’ or Services Oriented Architecture. Unfortunately, there is a problem with a whole lot of the noise and the hype.

Not that I don’t think SOA is important.  Having been one of the principle architects for what I believe was the very first SOA-based supply chain application (a warehouse management system) in the mid-1990s, I’ve been living and breathing SOA for a dozen years.  But the conversations that typically take place around SOA right now run the spectrum from techno-babble to partial truths to outright fabrications.  It needs to stop.

Here’s a quick primer on SOA.  The whole idea of SOA is to free the functionality of a software package from the confines of the application. We do this by creating logical bits of functionality called services.  A service, then, can be thought of as a piece of functionality delivered as a stand-alone ‘black box’.  Each individually identifiable black box is or can be decoupled from the application (doesn’t need the bounds of an application to execute).

It’s not that the application does not use the services. Rather, the services aren’t designed to be exclusive to the application (or the application as delivered).  In other words, SOA empowers us to create reusable, borderless bits of functionality.  These services can be used to create functionality and “work flows” (or processes) both within an application and between applications, sometimes in ways the original software developers may not have contemplated.

Sounds simple enough doesn’t it, even pretty logical? You might say “Makes sense. Isn’t this how software should be built? Give me the right building blocks.”

You’d be right in thinking this.  Software should be developed using SOA-based principles. The problem is that all too often it isn’t, or wasn’t. Now that SOA is such the buzzword, every software vendor is putting an SOA ribbon on everything they do. The reality is if the software wasn’t built that way from the ground up, getting there isn’t easy.

Some applications are truly based on SOA, some are not and most right now are partly SOA.  The problem is that the term is now bounced around so often that it is easy for vendors to say “We’re SOA,” declare victory, and simply move onto the next slide.  Are they lying? Who knows?  The problem is that there is no real clear definition of what it means to be SOA or have an SOA-based solution.

Here’s my suggestion – fill out the following SOA scorecard for each vendor:

  • If they talk about the technology of SOA (their implementation of it) – give them 1 point.
  • If they misspell SOA on any slide. Take away 1 point.
  • If they do not know each word making up the acronym SOA, take way 1 point for each of these words.
  • If they pronounce S.O.A as “So-A”, take away 1 point.
  • Add 5 points if they can use Web-Services based Integration.  A Web Service is an implementation standard for SOA.  Take away 10 points if they did not know this.
  • Add 20 points if they talk about it in terms of functionality and not so much in terms of technology – and can show how to shift the functionality around or move it outside the application.

If they score between 5 and 10 they probably have some SOA capability.  If they score over 20, they are probably pretty far along the spectrum.  But, my tongue in cheek scorecard highlights the most important thing about SOA.  While SOA is enabled by technology and architectural approach, its real value is to the operation and the enterprise’s business processes. 

So, in my book, vendors that speak of SOA in terms of technology are just adding to the noise – and may not “get it” yet.  Those that, more correctly, talk about SOA as a tool for yielding the most ROI out of the systems by how you can drive process innovation and rapidly configure the solution to the needs of the business (without regard to the specific functionality of the applications) – really get it.  If they are approaching the discussion from this perspective and (this is really important) can demonstrate how they do this, they probably actually do SOA to a level from which will yield you the potential for long term value.

In the coming weeks, I’ll be publishing articles revolving around what SOA can do for an operation and an enterprise and how to think about this in real terms. 

Agree or disgree with our expert's perspective? What would you add? Let us know your thoughts for publication in the SCDigest newsletter Feedback section, and on the web site. Upon request, comments will be posted with the respondent's name or company withheld.

 
 
 
  Send an Email  
.