How does Service Oriented Architecture (SOA) relate to the current world-view in SAP integration?

Service Oriented Architecture has undergone some interesting changes over time. It all began with CORBA, or remote procedure calls, and mainframes. Then came SAP, where you could call RFC remotely and build applications.

Later there was a trend toward object-oriented architecture and building applications based on classes. Where the focus was on objects and what to do about them.

Next came service-oriented architecture (SOA), and SAP’s contribution – Enterprise Services–where creating a sales order required certain components and a partner with certain other elements, and it all became a bit of a monster. SAP heavily promoted Enterprise Services, and any developer that needed to create an interface had to support the unwieldy SAP interface. This was challenging for providers to fulfill and for consultants to work with, because it required a lot of special development.

Later, OData emerged that brought a different kind of discovery protocol that allowed application to self discover content. It is different way of creating services and you would not see a common definition of what an order should look like.

Going full circle, lately we are seeing server-less architecture, like Amazon Lambda, for example. Server-less architecture allows developers to build functions that consume varying services, and in turn, applications can be built to leverage those functions. The smart thing, from a deployment perspective, is that you can create these functions to have all the resources you need, allowing you to scale your application in a different way.

Those developers who have been working in the field for a long time, realize these are all basically the same thing with different approaches and packaging, allowing companies to offer some cool features and be competitive.

From an SAP perspective, service oriented architecture is less desirable. Few developers today are using it for these sorts of purposes. Only a few companies are moving all their functionality to the SAP approach, such as Enterprise Services, which does have some more features than an IDOC.

But from a support perspective, it may still be relevant to use SOA. If you’re using IDOC already and are thrilled with it, continue doing that. But if you are going to build new interfaces, consider whether an Enterprise Service might be worth implementing. In SAP S/4, all interfaces are sent with the OData. All interviews are on the table, so that when data is exposed, it’s easy to read from your ECC system or S4 because it’s all OData on HANA services. OData is a protocol where the command is to expose data as web client data, rather than sending a service order and doing back end interactions. One problem with this approach is that it requires a technical function guide to drive it.

In general, people are habit driven, and we don’t want to invest a lot of time in figuring out how new things work. It’s the same with developers who don’t want to spend a lot of time figuring out how to do something in a new way, unless they perceive a clear advantage. I think this human nature is partly why we don’t see more people using Enterprise Services. Perhaps another factor is that Enterprise Services was originally released in small function blocks, which was an obstacle for developers who were reluctant to implement something that only affected a small subset of the business function they were working with.

As a developer there will always be new things and paradigms to consider. People will always say the have tried it, but now it is in a new context with new systems and concepts. So we will have to live with this change.

1 reply
  1. Rajn Ahmad
    Rajn Ahmad says:

    Daniel,

    Thank you for writing this blog on SOA/SAP integration in current days of Cloud Computing fever, Serverless services, Digital Transformation. It both timely and your views are appreciated. It is an excellent example of how SAP moving away from well published ES bundle ditching its partners who spent lots of money to build SOA based products to interface with ECC 6.0. These vendors are upset and do not know how to support another version of their product on S4 HANA. It is quite a challenge for them, I would quess so. SAP is quietly still supporting ECC environment along with new BW/Hana. SAP is also promoting new S4 HANA based ERP with IOT (Leonardo Platform), Front end UX with Fiori, embedded Analytics, embedded BPC and 3rd party microservices containers mapping back to old ECC with ES and Netweaver Application server, PI and Gateway APIs. All this is good for SAP, but for us Architects who are required to deliver and mapping out blueprints in timely fashion, it is becoming difficult to reduce code resources and still participate in new innovations. I think we architects and integrator should form a community and ask SAP to participate in details of its future technology under non-disclosure not that we are against digitization we want to support SAP in building a better path to support innovation at a lower cost.

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *