The best of both worlds approach is appealing. Leveraging SAP as the transactional backbone and surfacing business data in the Microsoft collaboration and productivity tools that everyone is so familiar with. So why isn't everyone doing it? Because, it is not that straight forward. There is one particular challenge that always needs to be addressed and here I will explain what the fundamental problem is.
When SAP opened up for a more service-oriented approach, they basically just took the lid off the box exposing a rather complicated mess of wires, called RFCs and BAPIs. You can achieve almost anything connecting to these wires but it takes a specialised SAP professional to do so. To overcome this challenge, these wires need to be combined into understandable and reusable sockets which outsiders, such as .NET developers or increasingly business users with the right tools, can easily plug in to.
In other words, connecting directly to RFCs and BAPIs will not get you far if you require anything but the simplest of read-only integration. So, has SAP overcomplicated it by making the API so granular? Not really. Because SAP is one large generic product built to work in pretty much any conceivable industry, it has to be this way. At least when considering the core product.
We have all heard users expressing their frustration with the standard SAP GUI. A lot of that frustration is a consequence of a generic user interface that is not targeted at that particular user's role or industry. It is exactly this same frustration developers experience when connecting directly to the SAP services. The issues users are having with the SAP GUI are reflected in the integration layer when developers are facing the underlying API. Granularity is the culprit in both instances.
There are many tools and technologies which can be employed in the services tier or even to help with point-to-point integration. However, regardless of whether you are using SAP Enterprise Services, SAP Connector for .NET, SAP PI, Microsoft BizTalk, your own custom interoperability components or any combination of the above, you will still encounter the same challenge: Composing easy consumable services from the granular SAP API.
The good news is that this is a problem that can be solved. And it can be solved elegantly. The less positive news, however, is that the reality dictates a wide range of solutions depending on many factors that are specific to your requirements, circumstances and environment. But hopefully this post has helped you focus on where you need to concentrate your effort, particularly when you design your architecture or evaluate various third-party tools and technologies. Always ask the question, "how is this going to make service composition easier?"
Thanks for reading and please do share your thoughts below. Many people out there are eager to hear your professional view on this.