Skip to Content

Finally the Penny Dropped Regarding ESA/SOA…

There is a German saying for when you finally get something, the moment of epiphany: “Der Groschen ist gefallen”. Word for word translation would be: “The penny dropped”. Funny enough, when I checked with Americans they don’t know what I am talking about, verus British people seem to have the same phrase in their version of English.

Here is my story on how the penny dropped regarding ESA/SOA (Just to make sure… ESA: Enterprise Service Architecture and SOA: Service-Oriented Architecture)

To hear management talk about a new strategy is one thing, but to answer the resulting questions from customers is quite something else. By the way, the customers have every right to ask these questions. And most often I found myself really getting the idea of a strategy by answering these inquiries.

While you can easily explain the concept of ESA for non-techies, those who know today’s tools also know that the stressed ‘Services’ part is not here yet. (This is somehow related to Matt Kangas’ Weblog about the Implementing the Refrigerator)

We make no secret about our road map to ESA (which is SAP’s implementation of the general SOA acronym): We will develop a list of services in 2005 with first implementations in 2006. As any techie knows, we just need more tools for a service-based concept.

Hacking BAPI calls and wrapping it as web services will not be enough.

Needless to say that any programmer is suspicious against any kind of technique that promises something like instant programming out of the box, or the like. So, how will all of this come together, and what will be the revolutionary meat to it?

A couple of days ago I talked to two friends of mine and tried to explain what we’re doing. One of them is not a techie at all, while the other is a full-time programmer, so I tried to draw the picture of how companies work today: A department of XYZ Inc. decides to run a customer campaign because they see a good one-time opportunity. Unfortunately, that kind of campaign is not implemented in their ERP system. Implementing that stuff would take too long and would be too much of a hassle. Guess what they will do: They’ll extract the needed data out from their ERP system to do the necessary work with Excel (in most cases).

At this point the non-techie started to grin. ‘This is exactly what we do at my company’, he pointed out.

‘Now imagine a system that does not only drop data on you, but let’s you much better define the data you want,’ I continued.

‘First of all, you would like to only get the fields of a table you want, and additionally you’d like to get only the number of records you are interested in.’

At the same time, I had to think that this is not much of a challenge to us techies, but it surely is to your fellow white-collar clerk colleagues.

‘Second, it’s a nice idea to have some rules on that data and that is where, today, anybody has to engage a programmer. Last but not least, how about not even stripping off the data from the system, but keep it there for the whole process?’

Here the techie entered the conversation: ‘Nice, but why do you bother me when you are coming back to programming after all?’ ‘NOT SO!’, I answered.

‘Imagine a large bunch of services that give you back your company data sliced and diced the way you want it. Sorry, first of all not for you, but for your fellow non-techie colleagues. What you’ll see them do next is build applications that are not worthy of being called such, ugly screens that your boss would fire you for, and of course without any documentation. But the guys who made that stuff will be proud and happy.’ Well, from that point I became a little pathetic ‘Proud because they managed to get along without IT and happy because they saved a lot of manual work they had to do before.’

‘This never will happen, stupid’, was the next I got back from my techie. Well, I must say that the people I usually hang out with are sometimes very straight-forward. ‘Or you’re doomed, dummy,’ I gave back. OK, we’re sometimes very blunt to each other.

Reality usually lies somewhere in between extremes. Therefore we agreed that, while obviously these kind of new applications will first serve a ‘market’ that today’s IT cannot serve anyway, and therefore, it is not threatening any jobs.

‘But there are open questions of course’, I said. ‘Yes’, the techie jumped in. ‘Can we let those guys run over the complete data of the ERP without notice?’

‘I admit, this is an open question, but you don’t tell me there is no solution to this, do you?’

You don’t need to follow the whole discussion of that evening, but guess what, somewhere in the middle of it I felt a dime drop.

You must be Logged on to comment or reply to a post.
  • Hi Benny,

    Good post, thanks for the plug.  In "American", I think we tend to say "the other shoe dropped" (as in "waiting for the other shoe to drop") more than the penny... 😉

    Best Regards,

    • Actually I the closest America version is "the light bulb came on" - the "other shoe dropped" is when one is waiting for something bad to happen and it does -  "the dime dropping" is about making a phone call - normally thought of as informing on someone to the police but stands up in normal use.

      I've spent 20 of my 47 years in the US but grew up in England - so I speak American, English and the resulting mix of Gibberish as my only three languages...

      • I've revisted Benny's post quite a few times and the more I read it the more it makes sense.
        What I imagine seeing in the ESA SAP ecosystem is a number of "programmingless" tools.  Hope someone will begin blogging about those quickly.  I know they exist in the SAP products and services.  Wonder how many folks use and know them.
        As an aside, I lived in Israel for 25 years so I speak Hebrish (Hebrew-English)and coin dropping is a familiar concept.  In the "old days" we called it "token dropping" (loose translation), the phone tokens dropped into the phone as the conversation continued.  The longer the conversation, the more tokens.  So what's the connection here?  The more conversation about ESA, the more tokens drop for this listener 😉
        Thanks Benny and Matt.


        • Does Visual Composer fit in here?  I recently saw a demo of the next version in which the presenters were quite proud of the fact it could easily retrieve data from BAPI/RFC or BW, while barely touching the concept of connecting to web services.   When asked, they acknowledged it did, but that was about it.

          In the SAP world... is Visual Composer going to fit into this space?  Seems to me it could, though it's still pretty techy atm. 

  • Where does the concept of different and unique business operations come into the picture?

    Surely, there is the underlying assumption that the business will need to change to take full advantage of the ESA environment, or can the architecture be resilient enough to accomodate differences?


    • Hi Paul,
      you're opening a big issue here and I'll concentrate on your subject: standard and custom.
      DI would say, don't expect that your customization in future will just be some changing and reconnecting between services - that still is science fiction. I expect the standard software still to be directly connected in places that don't fit with services but some pieces of code serving as services at the same time. That means standard software is something you get as is and may be able to chenge the same way as before - with same consequences as before - except you find a way to use services for this.

      The benefit of the flexibility you have to expect in other places: just yesterday I was at a customer site (production facility)and the single thrilling thing for these customers was that we might give them a way to support end users mapping changes to the production landscape software. Today this always needs action from the IT department.

      That's the direction to think about.