22 June, 2009

Interview with Mike Fitzmaurice on the Nintex and ERP-Link partnership

Recently Nintex and ERP-Link announced a partnership to integrate the ERP-Link iNet SAP/Microsoft interoperability platform with Nintex Workflow 2007. From an interoperability perspective, this is certainly a very promising partnership.

I’ve been in touch with Mike Fitzmaurice, former Product Manager of SharePoint and now Vice President of Product Technology at Nintex, to get some questions answered around this new partnership. Here are the questions and Mike’s answers:

Bringing SAP data and functionality into the Microsoft stack seems to be the perfect way of leveraging the best of both worlds. It respects SAP as the process-oriented transactional engine and still allows workers to collaborate in a people-oriented environment. Do you agree with this point of view?

Most assuredly. It’s the best of all possible outcomes. SAP knows work. Microsoft knows workers. Both companies benefit and both companies’ customers really benefit, when they can be made to work together.

Although the SAP/Microsoft interoperability strategy easily wins people over from a conceptual point of view, it still seems to be a relatively immature idea when it comes to actual large-scale implementations. Is that your observation as well?

I don’t think “immature” is the right word here; that implies lack of cognitive complexity, sophistication, etc., and that’s not the problem. There’s an enormous amount of aligned technology on both the Microsoft side and the SAP side of the equation.

What are behind the curve are the companies that have a solid understanding of both SAP and Microsoft technology, ERP-Link being one of a few notable exceptions. Too many (not all, but too many) SAP specialists don’t seem to be able to wrap their heads around information workers; they even refer to that universe as simply “unstructured data”. Conversely, plenty of Microsoft technology specialists think “SAP” is one simple thing, and providing “SAP integration” involves some magic black box. If there’s immaturity, it’s in the service sector.

Integration always involves services. What we can do in software-land is make that service step as straightforward and painless as possible. ERP-Link does their part by creating Microsoft technology-based access to the SAP features of your choice, and in a way that you can reach from Web Parts, forms, orchestrations, custom pages, and workflows. Nintex workflows are designed to reach other software and Web services are the way we work with ERP-Link. We’re a living example of how this kind of thing is supposed to work.

How do you envision SAP data surface through the Nintex product?

The most common immediate scenario we envision is having a SharePoint workflow, designed using Nintex technology, fetch data from SAP and post information to it. In other words, calling BAPIs. This will allow you to check someone’s vacation balance, approve expenses, etc., inside friendly workflows that are front-ended by SharePoint sites, InfoPath forms (or spreadsheets, or just list items), and approve them with emails, get notifications over instant messaging, etc.

In fact, users won’t even realize they’re using SAP. SAP is there, and is the final authority on what’s what, but they’re using the tools they already understand to interact with SAP. No extra training, no extra steps, no extra pain.

Will you provide standard workflow activities that do not require any code to access SAP data? Is it your ambition to provide out-of-the-box workflow activities for certain functional areas in SAP pre-assembled and wired up through the iNet.BOP platform?

Certainly. Not immediately, but certainly. SAP is a big subject area. There are many modules and components to those modules. What you’ll find us doing is working with ERP-Link, and our mutual customers, to see which use cases are most in demand. ERP-Link will have (or already does have), pre-built business objects for those use cases, and we’ll in turn create drag-and-drop workflow actions that call those business objects’ Web services.

We take the same approach today to communicate with BizTalk Server, Excel Web Services and other facilities that expose SOAP. Rather than using our general-purpose SOAP client action, we’ve created actions tightly-coupled to specific web services, and produced extra-friendly actions to fit them as a result.

Will there be an SDK for iNet.BOP that allows developers to build Nintex workflow activities integrating with SAP?

Actually, the Nintex Workflow SDK already covers how to build custom workflow activities. They’re standard Windows Workflow Foundation (WF) activities with a tiny bit of extra code to provide a web-based configuration dialog box. It’s not hard if you understand WF. If you want to know a little more about the Web services iNet.BOP generates, their SDK is ready to help. Will we create several examples to show the process from start to finish? Of course. However, our products are accessible enough that a special SDK isn’t likely to be necessary.

What versions of SAP are you targeting?

Excellent question. One reason for working with ERP-Link is that their interop layer targets many versions of SAP. It can certainly work with R/3 technology and it might even support earlier versions from that. A non-trivial chunk of SAP’s customers run deployments that aren’t on the latest version of everything SAP provides, so only looking at the current offerings wouldn’t’ be enough.

When integrating Nintex with SAP, is your focus around surfacing SAP data in Nintex’ existing workflow model or do you envision having SAP transactions drive new ways of building Nintex workflows?

That will be up to our customers. I think SharePoint is the center of the universe, and I can’t imagine companies not wanting to use SharePoint Server as their primary portal, not wanting to have their primary document collaboration take place in SharePoint sites, and not driving workflow processes out of SharePoint sites – especially if they have Nintex Workflow. But I’m biased.

We’ve already encountered scenarios where customers want workflows that begin in SAP and then are off to Nintex Workflow and SharePoint to conduct the lion’s share of the work. It is then returned to the SAP workflow at the very end. That’s certainly a scenario that interests us greatly; we already have the necessary building blocks to make that work.

The upcoming Duet 3.0 (SAP for Microsoft Office) will be heavily based on SharePoint technologies. Is the Duet product taken into consideration? How is the iNet.BOP/Nintex architecture positioned against Duet?

It’s not positioned against Duet at all. Duet 3.0 will be great and customers with all of the right prerequisites will find it worthwhile. We’re actually hoping the APIs are open enough for us to interact directly with Duet facilities from within Nintex workflows. But Duet is focused around specific use cases. iNet.BOP is a general purpose means of delivering the building blocks for many use cases. And ERP-Link also provides a means to connect to SAP’s document management investments and to SAP’s business intelligence facilities.

Which business scenarios will benefit most from iNet.BOP/Nintex architecture? Are there any particular functional areas of SAP where you see a lot of interest?

It’s kind of a foot-in-the-door phenomenon. The first thing we often hear is usually around the area of employee self-service access to HR services. That having been said, purchasing, expense approvals and many other processes usually get mentioned almost immediately thereafter. But it’s not about what we want; it’s about what customers want.

Do you see the iNet.BOP/Nintex architecture as relevant for management of documents with a clearly defined lifecycle (as opposed to using standard SAP DMS)?

Definitely. SharePoint already supports the notion of content that begins its lifecycle in SharePoint sites and later moves into more formal content stores (Documentum, OpenText, Filenet, etc.). Nintex Workflow already supports submitting content under workflow to be submitted to records repositories. When coupled with ERP-Link technology, customers that want to combine both worlds will have the means to do so, and the means to do so without pain.

Do you see the iNet.BOP/Nintex architecture as relevant for managing collaborative content?

We see SharePoint in particular and Office in general as relevant for managing collaborative content. One of Nintex Workflow’s greatest strengths is that it’s build for SharePoint, with SharePoint. Workflow factors into this in a big way, and we make that easy to create, easy to deploy, easy to manage, and easy to understand.


William van Strien said...

Hi Kristian,

thanks for sharing this interview with us.
I agree with Mike in his statement that an important aspect for holding back the SAP/SharePoint interoperability in real practice, is the lack of combined knowledge of the 2 technology stacks. Often in companies there is knowledge and experience present of both IT platforms; but it is separated, not combined.
The separation is at minimal at the conceptual level. It is hard to know and keep up with the inners of both the SAP and Microsoft stacks - products, technologies, tools. But typically the separation is also explicitly embedded in the organisation structure. Different and independent teams responsible for SAP and for the Microsoft IT within the enterprise; and non-communicating nor cooperating in a structural manner.

I think that an essential factor for succesfully approaching SAP / Microsoft interoperability in an enterprise is to combine the knowledge + experience of both in a single team. It is not required to have team members that are indepth with both technology stacks. You need however a vision - both business and technical; an integration architecture, and someone with an helicopter overview of the enterprise IT. And augmented with experts on the specific SAP respectively Microsoft technologies. Also critical for the success is to have a business sponsor...

Kristian Kalsing said...

Thanks for your comment, William. I couldn't agree with you more. In every organisation I speak to, there seems to be a Chinese wall between the SAP and Microsoft practices. When a solution is required, it's usually handed to either the SAP camp or the Microsoft camp. Rarely are solutions architected to span across the two technology stacks.