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.

18 June, 2009

SAP Microsoft interoperability slide deck for portal solutions

At the Mastering SAP Technologies conference, we were conducting two SAP/Microsoft interoperability workshops in the Interactive Zone. One of these workshops was focused on portal solutions and what options are available for interoperability between SharePoint and NetWeaver Portal.

The workshop brought up some interesting discussions comparing and contrasting the two portal products. Consensus was that both portals have relative strengths and weaknesses despite covering similar feature areas. For example, SharePoint is often the preferred choice for collaboration and cross-functional horizontal integration and NetWeaver Portal is favourable for delivering standard business packages and vertical integration into SAP.

It’s also noteworthy, that having both SharePoint and NetWeaver Portal deployed appears to be a general trend within the SAP install base. Large organisations in particular are increasingly considering a dual portal strategy as a viable approach, leveraging the best of both worlds.

You can view the slide deck that was used as a backdrop for the discussions here:

The other SAP/Microsoft interoperability workshop at the conference was focused on business process solutions and covered a broader spectrum of UI platforms as well as the tools and technologies facilitating the integration between the SAP and Microsoft technology stacks. You can find the slide deck from that workshop here.

16 June, 2009

SAP Microsoft interoperability slide deck for business process solutions

This year’s Mastering SAP Technologies conference has just been wrapped up and it has certainly been a great couple of days. Like last year, there were lots of great sessions about upcoming technologies and a few really good case study presentations as well.

I was facilitating a couple of workshops in the Interactive Zone about SAP/Microsoft interoperability. It was great to have an opportunity to share experiences with other people interested in building innovative solutions bringing SAP data and functionality into the Microsoft stack.

One of the workshops was focused on business process solutions and how you can target multiple platforms in a service-oriented architecture. Thanks to my colleagues Alex Xie and Richard Frykberg for helping out with getting the content together. Please find the slide deck here:

I will publish the slide deck from the other interoperability workshop focused on portal solutions later this week, so please make sure you subscribe to stay tuned.

11 June, 2009

Why is there no universal task list in SharePoint?

This is a question I have been asked at a few occasions lately. It’s a good question because the experience many have with a growing SharePoint implementation is that you can quickly loose grasp of all the individual sites and their associated task lists. This is particularly a problem if you’re subject to an uncontrollable site sprawl due to poorly implemented governance, but even in relatively small and well-governed site collections the sheer nature of cross-functional collaboration can produce a significant number of sites.

If you’re a member of 10s of different team sites and workspaces that all have task lists and you also play a part in publishing workflows for various intranet and/or internet sites, you can quickly end up with quite a large number of task lists. Facing all this, the next logical question is “where can I see all the tasks that are assigned to me?” Wouldn’t it be nice, if SharePoint provided you with a universal task list aggregating all of your tasks from across the server farm?

The concept of a universal task list refers to a central list that automatically aggregates all your tasks from potentially many different task lists. It’s a concept well known from other systems. For example, SAP has the Universal Worklist (UWL) which brings together assignments from different workflow systems, including SAP workflow, alerts, Knowledge Management (KM) notifications and collaboration tasks.

So, why doesn’t SharePoint have one? Well, there are actually some good reasons for not having one. Although it seems like an obvious feature, it might not make so much sense if you dig a little deeper. The purpose of this post is not to revolt against a potential universal task list in SharePoint. But the fact is that SharePoint does not have one at present and although I have no insight into the product team’s design decisions in this area, I can think of two good reasons as to why there is no universal task list in SharePoint straight out of the box.

SharePoint is a platform, not a solution

SharePoint is a platform. Not a solution. It provides a platform of base services and features upon which you build business solutions. If you're not quite following this, then there are plenty of great articles out there trying to clarify this (including these). That means it doesn't have the business context to be able to determine what task lists to include in a universal task list and to provide meaningful ways of categorising and prioritising even at a basic level. It's not predetermined what the task lists are being used for, let alone whether they are being used for managing tasks at all. The task list in SharePoint is much like a datatype in a database. It’s a building block that can be used when designing and implementing business solutions.

A universal task list would inevitably have a large amount of tasks in it, so in order for it to have any value some level of prioritisation and categorisation would need to be applied to it. But how do you define levels of priorities and sets of categories in a generic way that can be applied to tasks from vastly different sources?

I'm not trying to argue that the concept of a universal task list is not applicable to SharePoint at all, but rather arguing that providing one out of the box does not make much sense because of the lack of business context. There are of course cases where task list aggregation does make sense. Imagine you have built a number of workflow solutions in SharePoint and you want an aggregated list of workflow tasks. Here a centralised aggregated task list could have a place. But again, this may still contradict the fact that task management has to be fully controlled by the individual to be truly effective which brings us to the second reason for not having a universal task list in SharePoint.

Task management is personal

The requirement for a universal task list is often driven by management wishing to find a silver bullet that will magically make everyone perform all their tasks in a timely manner. But driving task management following a top-down approach is not necessarily very conducive for individual productivity. I think productivity guru, David Allen, would agree with much of this. If you have a large generic universal task list, where you have had no involvement in defining the principles of it, your brain will very quickly go num to it. What you really need is tasks coming in via one of your existing “inboxes” and then process and manage the associated actions with your own personal system.

So what's the solution in Microsoft's current suite of products? Well, that's where Outlook comes in. Outlook is your personal productivity tool and it has the ability to aggregate tasks from multiple sources, including scattered SharePoint task lists. Outlook has a rich set of features to filter, sort, categorise and prioritise your tasks, customisable to your style of working. Outlook is a tool for you as an individual to collate tasks from a myriad of sources and create your own system that works for you. Obviously, this is only ever going to be as effective as the individual systems people have put in place to manage their tasks. But I dare say you will get much better results providing each individual with the right tools and coaching to improve personal productivity rather than trying to roll out yet another centrally managed task list that the brain quickly goes num to because it wasn’t designed for each individual’s particular style of working.

08 June, 2009

Microsoft interoperability workshops at the Mastering SAP Technologies conference

Next week (15-17 June 2009) the annual Mastering SAP Technologies conference will take place in Brisbane. There will be 12 tracks packed with technical SAP content and lots of international presenters.

At the conference, I will be facilitating two workshops focused on SAP/Microsoft interoperability. The workshops will be run as interactive sessions for a relatively small group of people where knowledge sharing is highly encouraged. Both sessions will also include live demos of real-life SAP/Microsoft interoperability
solutions.

SAP/Microsoft interoperability and business process solutions

  • Interoperability strategies for enhanced accessibility, usability and collaboration
  • Case studies in the following: InfoPath forms, Office Business Applications (OBAs), Smart Clients, Web and portal solutions, Mobile solutions
  • Examine the tools provided by both SAP and Microsoft to make this possible
  • Critical Success Factors for SAP/Microsoft integration

SAP/Microsoft interoperability and portal solutions

  • Comparison between NetWeaver Portal and Microsoft SharePoint
  • Interoperability between the two portal products and how to share content between them
  • Bringing IViews into SharePoint and Web Parts into Enterprise Portal

Each of the workshops are scheduled to run three times giving everyone an opportunity to fit them in between all the other great sessions. Download the full details about the the workshops from here. I look forward to see you there!

04 June, 2009

SAP GUI support for new Microsoft releases

A few details on the required SAP GUI versions and support packs for new and upcoming major Microsoft releases:

  • Office 2007
    Supported by SAP GUI 7.10 with Support Pack 13 (more…)
  • Internet Explorer 8
    Supported by SAP GUI 7.10 with Support Pack 13 (more…)
  • Windows 7
    Supported by SAP GUI 7.20, due March/April 2010 (more…)
  • Office 2010
    Supported by SAP GUI 7.20, due March/April 2010 (more…)