John Reynolds's Blog

The SOA Elevator Speech

Here are some notes from a "brown bag" talk that I am preparing for our IT staff, many of whom are died-in-the-wool mainframe COBOL programmers. This talk will be far more evangelical then technical, and I hope that it will de-mystify SOA for some. I'm sure many of you will say "Duh!" when you read some of the points, but you'd be surprised how many folks just don't get it (yet).

I like the following definition of SOA from a paper by Bernhard Borges, Kerrie Holley and Ali Arsanjani, but it's a bit over-the-top as an introduction:

SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions.

I think it works better if I break down the definition as follows:

SOA is an architectural style that encourages the creation of loosely coupled business services

Loosely coupled services that are interoperable and technology-agnostic enable business flexibility

An SOA solution consists of a composite set of business services that realize an end-to-end business process

Each service provides an interface-based service description to support flexible and dynamically re-configurable processes

I’d like to get across the following points about SOA:

1. SOA isn’t really new, but there are now some standard technologies (such as Web Services) that make it much easier to implement
2. The “Services” in SOA are business services… updating a loan application is a business service, updating a record in a database isn’t
3. Services are linked together to implement business processes... Business Process Engines make it easier to combine services into business processes, and BPEL is an emerging standard language for this purpose
4. Business partners can use your company's services within their own business processes and your company can use services provided by business partners within your own business processes.
5. SOA solutions favor flexibility over efficiency... machine cycles and network traffic are less important then being able to quickly implement and change business processes

On the implementation front, we need to clear up the following common misconceptions:

1. Services aren’t tied to user interfaces. User interfaces invoke services. Many user interfaces can use the same service. A partner may build a user interface on top of a your service, and you may build a user interface on top of a partner’s service.
2. Services can be implemented in any language, COBOL, Java, etc., but all services must support the same invocation/communication protocols (for example XML/SOAP).

Perhaps that's a bit more information then you can get across in one elevator ride, but it's close.

If you could add one more point, what would it be?

Comments

• I think you are on the right track. If your audience is developers, I find it best just to honestly explain the concept.

  SOA is already well known to any software developer; it is nothing more than calling a subroutine / function / method.

  Inform them that tech marketeers recently 'discovered' this long-known concept, then promptly smothered it in a bunch of buzzwords. That's what they do. Remind them it is no different than their recent 'discovery' of the simple decorator pattern, which they now shill as AOP. I expect you will get a big sigh of relief out of them.

  Skip the hype. Simply explain that SOA means nothing more than separating business functions into routines, just as they have always done. The only difference is that these functions can now reside on different machines; and now they can easily call them, just as if they were on the same machine.

  Posted by: cajo on January 06, 2005 at 08:20 PM

• The SOA hype is worrisome… This is one of those simple ideas that always seem to get co-opted. There is a lot in common between distributed objects and SOA, except that SOA is supposed to be language agnostic, and the granularity of the methods is on the level of business functions.

  Sadly, the usual casts of marketeers are trying to obscure SOA to justify expensive components… and that makes me fear that SOA infrastructures will become as complex as EJB (rather then as simple as Spring).
  

  Posted by: johnreynolds on January 07, 2005 at 11:07 AM

• I've decided that saying "Service-Oriented Architecture" is like saying "Food-Oriented Lunch" -- it sure sounds good when you're hungry, but you still have to decide how much you can afford to spend on it, which restaurant you're going to, and what you're going to order. And you still have to wonder whether or not you're going to have a massive case of food-poisoning afterwards. Show me an actual menu -- then I'll tell you if I'm impressed.

  Posted by: davidrupp on January 07, 2005 at 02:35 PM

• "Food-Oriented Lunch"
  ROFL!
  Thanks, I needed that.

  Posted by: johnm on January 07, 2005 at 03:26 PM

• What about highlight the two different interface styles ? eg show the difference between RPC style services , they should get that fairly quickly and the document oriented interface where the interface is the document being processed eg Invoice , purchase order etcetera .

  Posted by: justjava22 on January 07, 2005 at 10:42 PM

• Hmmm... Perhaps we should be more generic and call it "Food-Oriented-Meal" ;-)

  Thanks for the laugh David... although I know you're not completely kidding.

  Thank also to justjava22 for the comment about the interface style. The concept of a document oriented interface is much easier for business folks to grasp.

  Posted by: johnreynolds on January 08, 2005 at 06:41 AM

• My thing is that this talk is too wordy. You have to determine your audience. Of course, I am not saying they're slow or anything, but they are as you say COBOL programmers. Do COBOL programmers know the following words?

  * Loosely coupled
  * Interface based
  * Composite set

  It has been a LONG time since I saw COBOL code. I used to peek at it and laugh at the business majors in school cry over their machines because they'd been up since 4AM.

  But, I did like the way you broke up the terms and refined your talk about SOA. I just don't know if "object-oriented" speak will carry very well to your COBOL cabal. :)

  Posted by: dhinojosa on January 08, 2005 at 02:23 PM

• You make point good
  COBOL man live in cave
  Eat meat raw
  No knows fire

  Actually the folks are a really good bunch, but I better be prepared to define all these terms just in case.

  Posted by: johnreynolds on January 08, 2005 at 07:40 PM

• What does SOA get me?
  For all of the extra layers of complexity that SOA involves, my experience has shown that the vaguely articulated benefits of SOA--wispy phrases like "business flexibility" and "an end-to-end business process"--don't justify the effort and expense that would be involved in a wholesale move to SOA.
  One thing that usually seems to be missing from an explanation of SOA is a hypothetical example of how SOA might be used, that includes a description of the system it would replace and how it improves upon the existing system.

  Posted by: dglasser on January 09, 2005 at 09:25 AM

• Why is it that so many people who, being architects or interested in architecture, I would expect to be somewhat pedantic (besides reasonably intelligent), can't tell the difference between then and than? Are people careless (which would be worrying, given the responsibilities that most of you already have, especially with regard to presentation), or do you really not know the difference?

  Then, the real point of this message: surely architects need to justify the cost benefit when changing a corporate architecture to include something such as SOA? So then, why does there appear to be so many cases where it has been implemented unnecessarily? Unless an organisation is willing to invest reasonably in integration technology, SOA is not that important, because automated integration (e.g.: using a BPEL or similar tool) is SOAs killer application. It seems to me that if organisations do not clearly understand the cost of automating integration, SOA should be left well alone as the cost benefit in other areas is marginal, if it exists at all.

  Posted by: mansley on January 09, 2005 at 04:44 PM

• I agree with the comment that a BPEL engine is at the heart of the matter.

  WIth something like BPEL, the mapping between your company's processes and the software implementaion is more apparent, and presumably easier to change.

  My company is in an industry where we have a lot of business partners, and currently we seem to have as many ways of exchanging documents as we have business partners.

  With Web Services, it looks like our ability to use a partner's service, or expose one of our own, has a better chance of being fairly ieasy to implement... even if we can't agree on an XML schema, it's fairly easy to map differences.

  BPEL provides the ability to cobble together services from multiple organizations into a complete end-to-end business process.

  This is a long way of saying that SOA makes sense if your company is not an island.. If your company has business processes that rely on several players, then it may make sense to adopt SOA.

  If your company is small, and its business processes are pretty much internal, then SOA might not be much use.

  Posted by: johnreynolds on January 09, 2005 at 05:38 PM

• People, I think the important component in this is that they decide as a team at the onset which specific tools and/or languages they will be using for each "granule", and then develop keeping in mind at what point the other granules fit into theirs, and what specific needs the granules that will be interacting with their granule will have.

  I think the SOA concept is not just a marketing tihng, but a frame of mind the programmer has to be in when they're building. "What will the user want to see/need to happen?", and "What other activities in the business process are analogous to what I'm doing, and am I setting this granule up for adoption by the other process?"

  I suggest you check out a company called NeuLion, run by a group of CA people who decided to use this technology (if I can call it that - "development strategy" makes more sense) in real life. They do a great job of describing this in words and graphics on this page:
  http://www.neulion.com/technology/technology.asp

  They are doing a couple of big projects, and already have two big brand name websites and business frameworks done. The people who have used them have great things to say about them, so I think you can at least get some hint at how it looks when the rubber meets the road in a marketing and e-commerce situation.

  I dealt with another development group in which each programmer locked himself in a little box for his specific process, and didn't think of what would happen when the other processes had to interact with his. It was a disaster, and took about 6 months to get the parts to talk.

  I think that any time you have more than one programmer, and each is working on a process that has to interact with the others, at very least the strategy of having them work out this interaction from the onset is very smart (actually pretty obvious). I think that on top of the mindset I described above, the concept of building a process so it is logical and understandable by others when they need to adopt and adapt it, in a language that offers this flexibility, is what can give this concept legs.
  

  Posted by: gmburton58 on January 10, 2005 at 01:28 AM

• I believe you are right. Coordination and definition are important tools to understanding. You need to be able to find the service and then understand what it will do when plugged into your application. (Wiki)

  Posted by: breedlov on May 20, 2005 at 08:58 AM

• How about a pitch for the business folk. I for one have often had to justify why we are doing this (as a consultant brought in to make it happen) and do a bit of selling to the business:

  SOA enables you to connect just about all of your computing assets into a cohesive whole, making it possible with a fraction of the effort required in the past to get your systems speaking the same language together, regardless of their technology and what you may have been told in the past were 'incompatible' systems.

  Your developers can use a single programming technique or 'API' across all of your computing investments to create integrated solutions. These solutions are typified by messages that can be sent in real-time, that can be send using a technique where even if the target system is down, the message will be delivered when it comes back up, and many other ways including even email between systems (I know that sounds strange).

  This will likely save you money immediately by eliminating any rekeying of information at the tactical level, while allowing you to provide strategic solutions perhaps not concieved of before that will enable you to gain an advantage on your competition, enter new markets, and/or add a flexibility to your IT department you have likely not experienced before. The goal is to not think of your IT Department as a cost center, but as a strategic asset. SOA helps get you there and makes it easier to align IT with your business.

  Quality will likely improve due to the lack of duplicate data and possible human error and also due to the fact that key parts of working programs that you want to share with other programs (which might have before been incompatible) will now not need to necessarilly be duplicated, they can very likely be called directly. Don't get me wrong, SOA is not a panacea and there are still some kinks being worked out but for the most part progress has been swift and continues at a rapid pace. It would be very unlikely that you could not benefit immeditaly from a reasonably small investment with potentially large returns.

  In many ways SOA unlocks what were previouly independant silos and empowers you to create solutions that leverage all of the millions you have likely invested in your IT assets and will allow you to further improve the ROI on the money you have already 'sunk' when you may have thought you had already realized all of the return you were going to.

  Kind Regards,
  Damon Carr, CTO
  agilefactor

  Posted by: damoncarr on June 26, 2005 at 05:45 AM

• In addition, an SOA often allows you to seamlessly integrate with your business partners and automate many aspects of your 'value chain'. Perhaps you were told before that you could not communicate with your main supplier's computers. SOA just might make that possible using the Internet (and I know you are thinking security now) as the medium. In terms of security I can assure you the techies who did work on the SOA standards have some incredibly robust encryption techniques for the safe delivery of messages over the unsafe Internet. The odds of a hacker getting into our secure messages, even though they are over the internet, are incredibly small and would take an incredibly dedicated hacker with vast computing resources that would likely take months before they had a chance at breaking our messages. This is a highly unlikely scenario, but we must ensure our developers folllow strict standards for Internet communication of sensitive data. Luckily there are standards they can use, and we can enforce our policies with the help of our network staff to ensure a sensitive message is never sent without encryption.

  Damon Carr

  Posted by: damoncarr on June 26, 2005 at 05:52 AM

• The single underlying feature that allows SOA to work is metadata, however it is expressed, so long as humans can manage the metadata in the chosen format, and software can consume it to self-organize. Having such an ability does not make it economically viable, nor define an appropriate use for that ability. BPEL does not provide that either. Good business management does. Nobody needs SOA to communicate with other systems or vendors. A simple record definition will do the same job and for 1/10,000th cost of XML, provided all the users have software written to consume that record layout. People that claim otherwise are ignorant of the thousands of systems that do just that and have been working just fine for decades. At least as important as being able to perform these feats of interoperability is the ability to do it as well or better than an entry level programmer, and for a reasonable cost. A BPEL generated system that is so badly designed that data-entry operators that are booking flights or posting VISA card payments are 1/3rd as efficient is of no value to anyone. If you want great software, you don't need new and better technology nearly as much as programmers and software engineers that are also domain experts in the area they are writing software in. Software is congealed intellect. If you don't understand the problem down to a very fine-grained level your software is doomed to be of low quality. Like human languages, software languages don't guarantee that you can say anything useful, meaningful or even coherent. Expertise in a subject area doesn't either, but it is necessary, and with proficiency of language, it is sufficient. Damon. All of those standards that you think are the bed-rock of SOA are just tomorrow's yestertech to be discarded with extreme prejudiced when the marking mill gets rolling for the next bit of alphabet soup. Like now, the domain experts that know the business and the technology will roll their eyes, dig through a still more bloated pile of neo-blather software, and figure out how to keep the CIO from looking like a complete idiot for wasting a ton of money on still another fad. Industry knowledge and proficiency with the fundamentals of software - data structures and algorithms - will server you and your organization well until you retire. Running after fads will get you nowhere and waste endless company resources. If, as you go along in your software career, you don't come to appreciate those that came before and the cleverness with which they solved problems you are either hopelessly egotistical or very dull. Things do progress and get better, but at a much slower pace than marketing materials would have us believe. You can improve your skills at least as much by gaining an appreciation for what came before as considering new approaches. Yeah, I've written a few lines of COBOL, but mostly came to know the language by writing a parser for COBOL in C. Both of those languages will transport data 50,000 times as fast as XML, so appreciate the strengths that were there and build on that. So to the point, are we there yet?

  Posted by: solidpoint on August 03, 2007 at 02:01 PM

• For my thoughts on XML... Take a look at my other blog.

  -JohnR

  Posted by: johnreynolds on August 23, 2007 at 01:26 PM

• hi am a java developer, am new to this blog and new to the SOA also. i want to learn the concept of SOA. what i need to know?
  could any one give guidance pls.

  Posted by: surendra_meda on October 10, 2007 at 06:06 AM

This work is licensed under a Creative Commons License.