Re: [service-orientated-architecture] Re: Jeff's 4 Buckets

Wed, 12 Jul 2006 11:42:54 -0700

Patrick,

I like your basic definition of SOA (a set of best practices), but I have to push back on this assertion:

>> Moving to an SOA is non-disruptive because it can be done incrementally, project by project.

From a technical perspective, yes -- SOA can be done incrementally, but SOA is much more about culture than it is about technology. And a SOA initiative will be very disruptive from a cultural perspective. If you look at SOA strictly as a technical approach, you won't be very successful with it. As Steve, Alexander, and Keith said in their responses, SOA is about IT/busines alignment. IT can't do it alone. It must be a joint effort with the business.

 Anne

On 7/9/06, Patrick May <[EMAIL PROTECTED]> wrote:

On 5 Jul 2006, at 09:48, Gervas Douglas wrote:
> Your many years in England may have awakened you to the fact that
> the appropriate accent nowadays is Estuary (unless you want to work
> in Government or the media where a socially uncomplicated Scots
> accent seems to be the key).
Gervas,

I thought it was my many evenings getting a Guinness-enhanced education on English culture from an eminently qualified historian and somewhat cynical observer of human nature.  ;-)

> Now what I want you to write in your best Maine accent is an answer
> to my request for a pitch on the business benefits deriving from
> SOA.

It took me years to rid myself of that accent.  If you're interested in hearing it, my former high school English teacher is now a "Maine Humorist" with his own website:  http://www.joeperham.com.  The audio trailers are a good approximation to how I spoke growing up.

Your request for a pitch on the business benefits of SOA comes at an opportune time, since I'm currently mentoring a group of business analysts and technical architects on that very topic.  While most of the members of this list won't need the selling advice, here's an example of what I've provided:

"Service oriented architectures (SOAs) are an exciting new technical approach that will eliminate the problems we currently have and allow us to build new systems faster, better, and cheaper."   How many times have the non-technical managers who are the end users of most bespoke systems heard similar claims over the years, with terms like "message oriented middleware," "client server computing," and "object orientation" in the place of "service oriented architecture?"   Considering that the industry average of project success (80% either significantly exceed schedule and budget or fail to deliver at all) hasn't changed appreciably in response to adoption of these technologies, project sponsors can be forgiven a certain amount of skepticism when presented with the next "big thing."   Indeed, any manager who rushes to embrace the flavor of the month shouldn't be trusted with a budget in the first place.

Those of us who have developed SOA based systems know that it does have real technical value and provides measurable benefits.  Our challenge is to convince our clients, whether internal or external, of those benefits.  A verbal deluge on the topics of separation of implementation and interface, multicast discovery, dynamic binding, non-functional requirements, and the merits of Jini versus SOAP, however technically correct and enthusiastically presented, is not going to achieve that goal.

So, what should we tell our clients about SOA?

The Elevator Pitch

When encountering a client by chance at the coffee bar, in the restroom (the appropriateness of this locale being dependent on the client's gender, of course), or in the proverbial elevator, there isn't time to explain all the benefits of SOA.   There is, unfortunately, plenty of time to give a very negative impression of it, the most common being "It's another toy for the techies."   The best possible outcome is to convey a simple but accurate summary and leave the client wanting more.

When the client asks "What is this service stuff I've been hearing about?" recognize that the real question is probably closer to "Why can't you people just deliver what I need without inventing new buzzwords   every few months?"  Answer the real question:

SOA?  It's basically just a name for some industry best practices that have proven valuable in other organizations.   We've been following most of them for years, so there won't be too many changes required (and those will be incremental).  The biggest difference you'll probably see is that more business functionality is going to be exposed across business units, so we can really make the existing systems sweat and get your money's worth out of them.   You'll also be able to change your business processes more easily.

Once your client recovers from the shock of having a conversation on a technical topic without his or her eyes glazing over, you'll probably be asked for a more detailed presentation.

The Stuck In An Elevator Pitch

Given more time, either as a result of a successful elevator pitch or because you lost the plot and your client backed into the emergency stop button while trying to get as far from your overly animated explanation as possible without taking the risk of breaking eye contact, you can expand upon the key points from the elevator pitch:

SOA does not require "rip and replace."  The costs and risks of new technology are at least as important as the benefits.   Clients need to understand that the combination of techniques that comprise an SOA are evolutionary, not revolutionary.   Moving to an SOA is non-disruptive because it can be done incrementally, project by project.

SOA leverages existing software investments.   Businesses have spent a significant amount of money on IT systems over the years.   In many cases, the business benefits of those systems have been limited because of architectural and design decisions that resulted in "silos" of functionality.   An SOA provides a means of unlocking the potential that exists in those systems by exposing the business functions as services.

SOA focuses on business functionality.  While there are a number of interesting technologies underlying SOAs, the primary focus of the approach is the delivery of cohesive sets of business functionality packaged as services.   This focus results in an inherently strong alignment of business and technical goals.

SOA increases business agility.  Exposing new and existing functionality as explicit services breaks down the barriers between business units just as the technology underlying SOA breaks down the silos that isolate IT systems.   The use of services supports the creation of more consistent business processes that can be easily, quickly, and safely modified as business needs change.

Examples specific to your business should be used to tie each of these benefits to specific issues of interest to your client.

Summary

Non-technical business people are rightfully suspicious of new technologies and approaches because of frequent exposure to over-hyped "solutions" that somehow never seem to deliver real value.   Service oriented architectures do actually provide measurable benefits, but those must be presented in a way that shows that the clients' real needs are understood and respected.   Technical people who fail to do so are not going to have the opportunity to use SOA in their organizations.


Comments and criticisms are, of course, appreciated.

Regards,

Patrick


__._,_.___


SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to