19 November, 2009

New announcement on Duet Enterprise

There has been a new announcement from Microsoft on the Duet product. The product, which is a joint effort between SAP and Microsoft, has been slightly rebranded to be called Duet Enterprise. Duet Enterprise promises to deliver standard SAP functionality to business users through their day-to-day productivity tools such as Outlook and SharePoint.

The main difference from previous versions of the product is that Duet Enterprise is based on a fundamentally new architecture leveraging SharePoint 2010 as the middleware component. The cornerstone feature of SharePoint which facilitates the integration is the Business Connectivity Services (BCS). The symmetric architecture of the BCS will underpin communication between SAP and SharePoint as well as directly between SAP and the Office clients. The BCS also provides the client-side infrastructure that will enable offline support, effectively allowing business users to access and manipulate SAP data outside of network connectivity.

To start planning for a Duet Enterprise roadmap, we require the next level of detail in terms of functionality provided out-of-the-box and what is possible through the promised Software Development Kit (SDK). I expect the standard functionality to be an improved version of the scenarios available in the current version of Duet, but more importantly it will be crucial to understand what will be possible through the accompanying SDK. The lack of an SDK is one of the main limitations of Duet in its current incarnation.

The details on functionality and SDK are still to be released. This announcement does not provide much other than a commitment to the product from SAP and Microsoft. But there is now a public statement on a timeframe that will see the product released in the second half of 2010 and there appears to be a strong focus on providing a toolset that will allow us to go far beyond the pre-packaged solutions. Furthermore, it is great to see such a strong commitment to SharePoint from SAP.

01 November, 2009

Interview with Peter Chapman on the ZOA integration framework for SAP

Integrating with SAP from other UI platforms is increasingly common and this integration can be facilitated in many different ways. Regardless of the approach taken and middleware used, one of the bigger challenges is the granularity of the SAP APIs (BAPIs/RFCs) which are extremely hard to work with for developers from other platforms.

ZOA is an open source initiative that aims to address the SAP integration challenge at the root of the problem by providing a framework for exposing SAP services that are more reusable and easier to consume for outsiders. To shed some further light on ZOA, I’ve been in touch with Peter Chapman, who started the ZOA initiative. Here are Peter’s answers to my questions:

What exactly is the ZOA framework and how does it work?

The ZOA framework reduces the risk for SAP integration projects. It comprises patterns and classes for ABAP developers so they can build predictable, reusable services regardless of the host SAP product or version. Instead of building services for a point solution, with all the complications of cross-platform design and testing, the ZOA framework implements an abstracted service model which can be tested independently from a particular solution.

This allows the SAP developer to build to a clear specification regardless of the end application, and guarantees basic functionality for third-party developers.

ZOA is a play on the Z prefix denoting SAP custom developments and implies a developer oriented architecture.

What has motivated you to start the ZOA initiative?

For 13 years I have been building custom ABAP code around standard SAP functions. I have seen the steep learning curve for new developers trying to consume BAPI functions. And I have had the midnight calls and had to reverse engineer integration issues when I should be recovering from a good night out. The default approach is to solve complex interfaces by introducing even more complex middleware. I wanted to solve the problem at its source, which is why a new service model was required.

What are the biggest challenges developers are facing when integrating their applications with SAP?

Big business systems like SAP are easy to underestimate. They don't have sexy new programming environments. Their developers are still coming to terms with class based architectures. But just because something is represented in a language that still looks like COBOL (or in zeroes and ones for that matter) doesn't mean it is unsophisticated or lacks complexity. There is a reason that companies pay the big bucks to have functional, technical and Basis consultants working together to implement relatively simple-sounding requirements.

And that is without any integration component. In my experience, introducing a new technology platform increases effort and risk by an order of magnitude - and that includes SAP Portal and anything running on their Java stack. Just because it is all now badged NetWeaver doesn't make the integration challenge go away.
Once the challenges of integrating their applications have been overcome, of course, there can be even greater challenges to support it.

How does the ZOA framework help overcome these challenges?

ZOA anticipates some of the biggest pain points and provides consistent mechanisms for handling them, regardless of what objects, systems, or versions of SAP are involved. By delivering a clearly defined layer of abstraction in the SAP development environment (instead of pushing it out to an ESB), developers on both sides of the integration know what they are working with. If something doesn't work, it is much easier to identify the cause of the problem.

The framework includes testing and logging tools, which can be activated externally without any involvement from the SAP developer.

Traditionally, even trying to verify what is passing through the interface can be challenging. The ZOA framework includes methods to interrogate allowed values for particular fields and objects. It includes methods to validate individual field values. By building services to the ZOA specification, SAP developers don't have to write pages of technical documentation before the third party developer can understand what is being passed and how. The ZOA services are consistent across all objects.

There are many ways of achieving interoperability with SAP. What is unique about the ZOA approach?

This is a great question. All of the ways of achieving custom interoperability require support from SAP consultants, because even consuming existing SAP services is complex. Most often, a SAP developer will write some kind of facade or custom function to expose the services required for a particular interoperability scenario.
ZOA provides predefined templates and helper functions to focus this development effort. ZOA services and parameters are clearly defined, quick to develop, and highly reusable. There is a clear demarcation of responsibility between SAP and third-party developers. The model includes logging and debugging features, providing external developers with powerful analysis tools.
This approach brings conformity to custom integration design, regardless of the developers or project, using a proven model. The end result is reduced risk, reduced maintenance and reduced timeframes.

An important benefit for SharePoint developers is that the framework includes native BDC support by including services like SpecificFinder and IdEnumerator.

How do you manage an open source initiative like ZOA?

There is a great tool for SAP called SAPlink, which allows developers to easily share SAP development objects without involving the formal SAP transport mechanism. By publishing the source code in this way, and managing it with subversion through Google Code, collaboration is possible.

Having said that, there can be challenges finding a development environment where you can play with the code, and various licensing issues to be aware of. The open source community around SAP code is nascent, with the risk of using unknown code outweighing potential time savings. Experienced developers are on daily rates anyway and have responsibility for dealing with any production issues.

What is the roadmap for ZOA?

An early version of ZOA has been released to the public domain to assess interest and better communicate the model. I am continually refining the model and an enhanced version has recently gone into a production environment where it is performing very well. SAP's open source team are in contact with me and I am hoping to find a way of bringing the latest version into the public domain together.

In the meantime, I am advising SAP customers on their integration strategies and roadmaps, including architecture options and the potential for adopting ZOA.