16 July, 2010

Facilitating round table discussions for new SharePoint conference in Australia

Another new SharePoint conference is being launched in Australia. Later this year, Share 2010 will be a conference with a different format and focus than previously seen in Australia and New Zealand, focusing entirely on the business issues and challenges of SharePoint. It's being organised by Eventful Management who for many years have been running some great events in the SAP space. I have been fortunate enough to have been involved in many of their conferences, both as a speaker and as a vendor, and they have always exceeded expectations.

The conference content and format will be driven by the people at the coal face. At the moment, Eventful is running round table discussions in Sydney, Auckland, Melbourne, Canberra, Brisbane and Perth with local people who play a key part of their organisations' SharePoint journey. Based on the outcome of these round table discussions, the conference agenda will be set and speakers invited accordingly. In total, more than 100 community opinions will feed into building the inaugural conference content and style of delivery.

I will be facilitating the round table discussions in Brisbane this coming Thursday. Please provide your input in the comments below if there's something you think should absolutely be part of the conference. What are the biggest pain points you are currently experiencing with SharePoint? In particular from a business and change management perspective? What format would you like to see sessions delivered in? I’ll make sure all your comments and ideas are taken into consideration.

05 July, 2010

SAP/Microsoft interoperability and the composition challenge

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.