Skip to Content

I published most of this post over on my blog, vendorprisey, but I figured it would be okay to publish it here too, after a brief chat with SDNer Craig… I think it points to a problem that impacts not only enterprise software marketing, but also something for those of you that try and convince business types to invest in SOA projects.

The post is one of several where I rant on about simplicity.

Joe has a very interesting post over on ZDNET. If you are in Enterprise Software marketing, you should read it if it is the only thing you read this week.

He picks up on a podcast he was on with Dana GardnerSteve Garone, Joe  Neil Ward-Dutton, Jim Kobielus and Trip Chowdhry,  an equity analyst MD  at Global Equities Research.

Trip’s message is very simple and straightforward: Vendors, please start making some sense to the rest of the world when it comes to SOA. Trip said that the SOA concept holds some promise, but vendors aren’t articulating the message too well. “SOA is definitely a trend, but it seems like the messaging, the product, and everything else need to be simplified, so that people can know how one initiative can correlate and coexist with other initiatives they have going,” pointed out. 

Trip bashes SAP:

“If you think about companies like SAP who have very long implementation cycles, they have a lot of moving parts,” he explained. “It’s a complex product, and the problem that SAP has — and to some extent, most of the SOA vendors have — is that they’re trying to solve complexity with complexity.

When it comes to mass adoption — or the second phase of product adoption that needs to occur to show growth — then you really have to ease the product, ease the message. You have to tell what you do in one bullet point.

This worries me, not just for perpetuation of the SAP is slow to  implement myth, but because the the abject failure of enterprise software marketeers from all the major vendors  to articulate SOA in a way that customers and the investment community can understand.  

(I suppose the one positive from this is that Joe and co picked SAP as a SOA vendor.  Normally the analyst types moan that we aren’t SOA enough.)

I’ve been critical of the SOA marketing for sometime, here and here for instance. I commented last year.

The only thing in the world harder than learning German is trying to explain SOA to an audience of HR executives without causing them undue pain and suffering.

Business people want to talk about leaner supply chains, better margins, and fast implementations.   

Sam commented a while ago on James’ blog, the post was  discussing SOA

I’d go even further James and say that not only is it often superior to present an architecture without mentioning the supposed name of the architectural approach/style used, but often it’s best not to mention the concept of architecture at all.

The desired outcomes and value of the solution to the audience you’re talking to should press the right buttons.

Unless of course the audience is pure software people or technical architects and then their desired outcomes and value can be the architectural approach/style itself. Hence the problem of course … I like to call it supply-side thinking.

At the moment there is far too much recipe and not enough meal.

Every software developer I meet, not just here at SAP, but all over the place, tells me that SOA makes it simpler and faster to build flexible enterprise applications.  This stuff then is real,  it works.

If folks like Trip, who can probably do Black-Scholes calculations and build value at risk models while in the airport queue, don’t grasp what the marketeers are on about, then perhaps it is time for a big glass of Simple. 

The way to talk about SOA is not to talk about it, and just showcase the solutions that it enables.   Repeat after me.  Short sentences. No jargon. Real examples. Simple is goodness.

What has this got to do with you?

You may be asking what has this got to do with BPX? – marketing SAP isn’t my responsiblity, or thinking I’m not in presales. But actually a lot of you are. When you put your business case and ROI model together and present it to management, you are in sales, you might not be actually selling software licences, but you are certainly selling your project.

What do you need to sell your projects internally? How do you explain SOA to your management? Does SAP’s positioning help or hinder you? What do you do to simplify the message? What SAP materials do you use? 

Perhaps it is time for a competition?

Explain what SOA means to your business in the simpliest terms possible.  Craig and Marilyn how about some SDN Swag for the winning entry?  If I get more than two sensible yet simple comments, we will create a wikispace for the competition.

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Anton Wenzelhuemer
    …if you talk of dogs call ’em dogs.

    This helps a lot in avoiding to be put in a position where you have to answer questions like ‘SAP does ESA, IBM has SOA. How do we integrate them into one landscape?’.

    It would have helped also those people a lot who asked for literature on the principles of ESA when they already had a number of good readings about SOA in there library.

    but in case you want no one but experts to understand you call them canis lupus familiaris.

    just my 2 cents, anton

    (0) 
  2. Marilyn Pratt
    I think we can come up with some interesting swag.  I can promise to send (thanks to another community member, Scott Campbell) a timely book on Mastering Enterprise SOA with SAP NetWeaver as a prize.  Let us begin to showcase.  We have some community members eager to see and eager to share so this sounds like an opporunity.
    Thomas, hopefully you and others will also help evolve the rules of this game.
    I propose to take this over to the wiki area:
    BPX Main Page
    We can create a page there for “showing”.

    (0) 
  3. Nigel James
    That 4 letter word that is associated with a child’s toy is not a good analogy for the thing we are not mentioning.

    Also its not about not talking calling it a dog Anton, it is about showing the benefits (loving, loyal, protective of children, postman eating) without having to worry if it a kelpie or a poodle.

    cheers,
    Nigel

    (0) 
    1. Michael Nicholls
      Over time you can then replace Rex with Spot and as long as they understand the same request (Sit, Fetch…) they can then be used interchangeably.

      All in all, a dog is a good example of SOA.

      Cheers

      (0) 
  4. Pedro Lima
    I’m also reposting something from my blog[1], but I think it goes well with this challenge.

    Take SAP SCM tool as an example. To be able to do transportation planning the addresses of customers, vendors and plants need to be defined in geographical coordinates, so that it becomes possible to define and optimize the distance between places. This task of finding the latitude and longitude from the address data is called geocoding.

    With SAP SCM comes a plug-in software that one can install to do the geocoding. Of course this is not a very powerful tool, it comes with a limited database of addresses and just for some countries. This is the traditional architecture, the software has some plug-in that solves a particular need. And other more powerful plugins can be purchased if needed.

    But with some work [2] one can plug the SAP SCM to use the geocoding web service provided by Yahoo or Google. That way one can get better geocoding without the burden of having to buy, install and update a large geocoding address database. This is the SOA architecture. The software uses a stand-alone webservice internal or external to the company.

    [1] http://apolemia.blogspot.com/2007/01/soa-thing-was-i-would-explain-to-my.html
    [2] http://apolemia.blogspot.com/2006/08/goodbye-mapguide-hello-google-geocoder.html

    (0) 
    1. Nigel James
      That is a good example Pedro but not all geographies are covered by Google. For example in the UK geocoding data is available only under licence and hence Google do not provide geocoding services unlike in the US where this is free. Still it could be plugged into a web service from one of the providers at cost per geocode.

      Thanks for your comments.

      (0) 
  5. Jean-Jacques Dubray
    I am surprised to see that SAP (and a few other vendors) is still struggling to articulate any kind of strategy or value proposition around SOA.

    Maybe this series of questions and answer will help a bit.

    What is architecture? Architecture defines the elements of a solution and their relationships.

    Why do you spend time looking at solutions architecture? Architecture enables you to better estimate and contain cost, while enabling the solution to reach further value in the future by making it easy to change, expand or scale.

    Why SOA today? The web 2.0 is about “content”. The center of gravity of software has returned to the server (or more exactly a set of servers rather than just one). The desktop has become the “edge” of this new world, and its role is now limited to provide the best experience to consume increasingly valuable content. By definition the consumption is federated because to perform an actively today you rarely can limit yourself to go to a single server.

    What is the fundamental paradigm shift in SOA? SOA is about defining a set of technologies, programming language and ultimately architecture to construct solutions that can leverage content wherever it is the most cost effective to maintain and manage this content. The old way of doing things was “integrate or replicate”, SOA adds a new paradigm “federate”. Federate requires that we provide the technologies, programming language and architecture to create autonomous software agents that can work collaboratively to perform a unit of work.

    What do you need to achieve federation? first there are 3 levels of federation: UI, Process and Data.

    The basic building bloc of federation is communication. Without a universal communication infrastructure you can’t consume and federate. SOAP provides a secure, interoperable and reliable communication mechanism. REST provides another one, but IMHO, even though it is simpler than SOAP, it will not withstand time because of its lack of -ilities. When you create a solution that relies on a dozen services, you need a robust communication infrastructure.

    The second building block of federation is infrastructure to coordinate arbitrary complex units of work between these software agents. Here you need a new kind of programming language which can deal with long running unit of works, concurrency (here it means the same agent can be engaged in as many conversations as needed with other agents), can deal with correlation efficiently, … transactions (as an add on to the programming language) are also needed, because sometimes the unit of work is not performed as planned and some further work needs to be done to compensate the work done so far (two phase commit does not work in this world). You also need an “assembly” mechanism to assemble these agents in meaningful entities which can perform complex unit of work. The programming language of SOA is BPEL (it adds the concept of “message” to traditional languages which can only deal with “data” and “code”). The assembly technology is SCA and the transaction model is WS-Business Activity.

    Finally you also need EII like technologies at the service implementation level to achieve data federation.

    S.O.S: Service Oriented Solutions
    Why are they superior? They are superior because they are assembled from elements which are operated where the cost of operation is lowest. Traditional solutions keep replicating and duplicating elements. If you look back at SAP, how many elements could be operated commonly across all your customer base? Within an existing organization, this statement translate into creating agents once and reusing them in other solutions wherever it is needed. I know some SAP customers which have 30 SAP systems. Does it make sense? Each time you can “reuse” vs “build” you add to your ROI the cost of building something like you wish you could reuse. This is huge. There are enormous efficiencies that can be gained that way, not just in solution construction, but all along the solution lifecycle: in operation, maintenance and retirement as well.

    The other value proposition of SOA is flexibility, but this is a mere consequence of using federative technologies. Because you are more formal in creating interfaces, assemblies and service implementations (using BPEL), you can much more flexibly replace an agent by another one, change the rules associated to the unit of work, …

    I hope this little Q & A helped you.

    Jean-Jacques Dubray
    jdubray@gmail.com

    (0) 
  6. Sandeep Nalgundwar
    If I had to call you in the early days of telephones,if I had to call you, I would crank up the telephone and then tell the operator to connect me to Thomas Otter. The operator then would manually connect me to another operator at your end and then that person would manually connect that line to your telephone. Operator availability was the bottleneck. If the operator was busy with other calls, I had no choice but to wait. It could take hours, days… The choice phone companies had was to either increase the number of operators or look for better way to enable connect people.
    Next evolution brought electronic switching and telephone numbers. My new telephone had numbers on it that I could use to dial and that got rid of the bottleneck of operators completely. All I had to do was to remember the phone numbers of people. That resulted in a separate phone book and directories.
    Today, my phone stores the names and numbers so I done even have to remember the phone numbers. I just tell my phone to call Thomas Otter and I get connected.
    What SOA does for me as a user ( I know you hate the term business user) is to give me a simplified way to make the call – that is faster, better and cheaper. How that will happen is another discussion. That is what I am working on right now :).

    Sandeep

    (0) 

Leave a Reply