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.
[av_video src=’https://www.youtube.com/watch?v=PsFDVuBe3FQ’ format=’16-9′ width=’16’ height=’9′ av_uid=’av-2p3u3c’]
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.