04 December, 2009

ISVs can use SharePoint to light up their desktop applications

SharePoint is the server cornerstone that makes the Office clients light up. With SharePoint running in the background, the Office suite is enriched with additional functionality enhancing the collaboration experience. ISVs that are building desktop applications can use this same pattern to light up their applications.

I have had the pleasure of spending the last week with the Winshuttle team in Seattle and they have done exactly that. Winshuttle's main product is transactionSHUTTLE which is a desktop application that empowers business users to automate processes by shuttling data between SAP and Excel. transactionSHUTTLE is a great product in its own right addressing some very common challenges with SAP around mass manipulation of master and transaction data. However, what I really wanted to point out in this post is the architecture of the combined suite of transactionSHUTTLE and the supplementary server offering, eSHUTTLE, which is a SharePoint solution.

Winshuttle has for a number of years been offering their transactionSHUTTLE product to SAP customers as a standalone desktop application. When requirements emerged to offer a more enterprise-level solution with governance and workflow features, it became evident that a server component was required. Rather than building a server component from scratch eSHUTTLE was implemented as a SharePoint solution.

eSHUTTLE provides a central site for managing users and licenses and takes advantage of many of SharePoint's standard features including document libraries, workflow and alerts. All the desktop instances communicate with the server through the standard SharePoint web services. Artefacts created on the desktop can be submitted to SharePoint workflows and outstanding tasks are shown on the welcome screen of the desktop application.

This architecture does not only make life easier for Winshuttle because they can leverage the foundation of an existing platform. It is also highly beneficial to an organisation deploying the product because they can drop it into their existing SharePoint environment and their users are already familiar with the UI. For example, as the software vendor, Winshuttle does not have to worry about defining a viable backup and disaster recovery strategy for their server component. And the target organisation does not need to validate the backup and disaster recovery strategy of the vendor. The vendor and the customer are both leveraging the hard work Microsoft has already put into this for the SharePoint platform.

Winshuttle has managed to leverage SharePoint as a platform for delivering additional capability to their product suite in a way that lowers the cost of development but also lowers the cost of ownership for an organisation deploying the solution. eSHUTTLE lights up transactionSHUTTLE in much the same way SharePoint lights up the Office clients. And with the new Service Application model in SharePoint 2010, ISVs will have even more capability available to ustilise in their server offerings.

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.

23 October, 2009

Day 4 of the SharePoint Conference 2009

The last day of the SharePoint Conference was a short one. After breakfast I had a closer look at another third-party product. AgilePoint has a workflow solution that includes activities that can be wired up to SAP BAPIs through their integrated BAPI explorer. The interesting part about their product is that it presents a workflow solution for SharePoint without leaving a footprint on the SharePoint infrastructure itself.

Due to my travel arrangements, I only managed to fit in one session on this last day of the conference. I watched Rob Foster, well-known from the SharePoint Pod Show, present a case study with one of his colleagues from Deloitte about how social networking and improved collaboration have transformed Deloitte as an organisation. Social networking has helped break down silos and taken collaboration to a new level. Rich user profiles and associated blogs also allow individual employees to better manage their personal brand within the organisation which is always important in a large consulting company. The user profiles also display HR data replicated from SAP which was nice to see. Deloitte has implemented a very open policy about content contribution. Initially, concerns were raised that this could potentially lead to inappropriate content being posted. However, this turned out to be no problem at all. Everyone seems to acknowledge that what is not appropriate in an email or in the real world for that matter is probably not appropriate on a user-driven site either. Another point made was the rollout being successfully facilitated in a viral manner rather than forced upon people.

Unfortunately I had to skip the last two breakout sessions to catch my flight out of Vegas. It has indeed been a fantastic conference. There were lots of sessions providing a good feeling for all the new capabilities of the milestone SharePoint 2010 release and some excellent customer presentations about valuable lessons learnt. I also managed to track down everyone I wanted to meet which was a bit challenging at times with 8,000 people around. Thanks to everyone for a great week!

Read about Day 1.

22 October, 2009

Day 3 of the SharePoint Conference 2009

Yet another day of non-stop SharePoint activities has passed at the SharePoint Conference. And it has been non-stop SharePoint indeed. There is even a SharePoint channel on the TV in the hotel room, so when you sneak away for a little quiet time away from the other 8,000 SharePoint enthusiasts you can still get fed with SharePoint content.

My first session of the day was a bit different, yet very valuable. It was about the art of SharePoint storytelling and how selling and implementing SharePoint should focus more on the business concepts rather than the product features. Over the last couple of years, there has been an increased focus on the importance of building a shared understanding amongst all the stakeholders when rolling out SharePoint. This session explained how telling good and relevant stories can help to build this crucial shared understanding. Downloading the slide deck from this session will not carry much value since the message was delivered by telling good stories, effectively proving the point.

Being mostly interested in how we can eventually bring SAP data into SharePoint, I went to another presentation about the BCS, a deep dive into the runtime and the associated object model. The BCS has been significantly improved across all of its capabilities, but what really has enormous potential is that the architecture is now symmetrical on the client side. There is a BCS client runtime that will allow client applications (such as OBAs) to connect directly to the back-end LOB system. A client cache holds all the BCS meta data, external business data and manages queuing and synchronisation.

After catching up with various SAP/Microsoft contacts over lunch, I sat in on Steve Fox’ session on how to create OBAs utilising the BCS. Following on from the previous session I went to, this was specifically about building OBAs. When building Office add-ins in an environment with SharePoint 2010 and Office 2010 deployed, a lot more of the basic plumping will already be in place in terms of managing connectivity with the back-end systems and offline caches of external data. This will lower the total cost of ownership and be crucial for the uptake of the OBA architecture.

In the last two breakout slots of the day I let go of the BCS and went to some customer presentations talking about their experiences with implementing SharePoint. In particular, I really enjoyed Coca-Cola’s case study on how they are now utilising SharePoint Online for their entire SharePoint environment including public website, intranet and collaboration team sites. Their success was based on a strong focus on governance right from the beginning and having the entire program being led by the business with IT taking on a service providing attitude. They had some impressive usage statistics showing how successful their collaboration team sites have been within the organisation. Coca-Cola has also built a self-service area for HR transactions where SAP HCM is surfaced through SharePoint. They use custom Web Dynpro screens rendered within iFrames (note, not the IView Web Part).

In the evening there was another reception in the exhibition hall with roundtables setup for engaging with the experts in the various product and technology areas. A few of us self-proclaimed SAP/SharePoint evangelists quickly found each other to share frustrations with the past and excitement for the future. The reception was accompanied by a ‘SharePoint Idol’ competition where a large stage allowed participants to show off their ‘Guitar Hero’ skills. Again, all up a fantastic SharePoint day.

Read about Day 4.

21 October, 2009

Day 2 of the SharePoint Conference 2009

The second day of the SharePoint Conference was a highly productive one from my perspective as it allowed me to focus on integration with SAP attending sessions, meeting people and exploring third-party products all relevant to SAP.

The first session I attended was an overview of the SharePoint 2010 Business Connectivity Services (BCS) which is the evolution of the Business Data Catalog (BDC). The session covered the significant improvements in all of the three key investment areas of presentation, connectivity and tooling. With new components including a client-side runtime for Office connectivity and offline support, the infrastructure for the next version of Duet is starting to come together. I will cover this in much more detail in the future, so watch this space.

The highlight of the day was Matt Ordish’ presentation on surfacing SAP through SharePoint. Architectural principles around utilising both SAP and Microsoft technologies were discussed and kept the audience very interested. The session was really well attended which was great to see. News included the fact that the IView Web Part will not be available in SharePoint 2010 and the recommended approach for embedding SAP UI will be using iFrames instead. Again, I will write more detailed posts on this in the future.

I spent the afternoon catching up with people that are active in the SAP/SharePoint interoperability space and also had some great demos of third-party products that streamlines the process of getting business data from LOB systems into SharePoint. Stone Bond Technologies showed off their slick Enterprise Enabler product and Lightning Tools had a new release of their popular BDC Meta Man, upgraded for SharePoint 2010, and they also facilitated a detailed demonstration by Simplement of their approach to SAP integration.

The last session of the day in my schedule was a SharePoint 2010 Interoperability Overview. The Business Connectivity Services (BCS) is obviously a key component here but it was great to see an increasing number of standards being supported across the product. SharePoint will now be fully accessible across browsers by supporting WCAG 2.0 which has been a major roadblock until now in terms of using SharePoint for public websites. Various other standards will be supported including new web service protocols and CMIS for content management.

The conference is at the Mandalay Bay complex and when staying in these Las Vegas mega compounds, it is easy to forget that there is a real world somewhere on the outside. Just to keep my sanity intact, I went for a run in the late afternoon before joining everyone else at the SharePoint Beach Party featuring Huey Lewis and the News. It was a well executed 80’s theme party complete with break dancers, graffiti artists and various imitations of 80’s rock stars mingling in the crowd.

Read about Day 3.

20 October, 2009

Day 1 of the SharePoint Conference 2009

Day 1 of the SharePoint Conference 2009 has passed and it is certainly off to a good start. I got into Las Vegas Sunday afternoon and quickly met up with lots of colleagues from all over the world that I have not seen for years. With the likes of tools such as Twitter and Facebook we have an amazing opportunity to stay connected with a vast number of people and Twitter in particular was going off with everyone trying to locate each other.

The opening reception on the Sunday night was a buzzing event in the exhibition hall. As soon as the doors were opened at 6 pm the exhibitors were almost trampled by 1000s of SharePoint folks. Following the reception there was a community organised get-together, SharePint, in the EyeCandy bar at Mandalay Bay. It was another invaluable networking event with an overwhelming turnout.

More than 7,400 attendees made it to the keynote Monday morning. It is a testament to the penetration and popularity of SharePoint that so many people from all over the planet commit themselves to a weeklong conference entirely focused on SharePoint. 1000s of people have come across on long haul flights from various continents.

The first scheduled session I attended was a general overview provided by Arpan Shah, who went through some of the new features in the different workloads from an end user perspective. The UI of SharePoint has definitely been improved massively and I can only encourage you to check it out. It is a much richer user experience with less annoying post-backs, the ribbon has made it to SharePoint and many common pain points have been addressed.

I also sat in on a session on Visio Services. This is all new functionality and very powerful. Using Visio 2010 it is very easy to create dashboard diagrams that are connected to external data sources and which can be published to SharePoint and rendered in the browser. These external data sources can be SharePoint lists, so we now have a toolset for business users who want to build dashboard diagrams visualising SharePoint data. Visio Services can also be utilised for visualising SharePoint workflows and there is an associated JavaScript API for creating interactive browser-based diagrams.

In the last breakout slot of the day, I went to watch a customer presentation with real-world examples of Office Business Applications (OBAs) and MOSS 2007. Tyson Foods has been building solutions exposing their LOB sales system in Word, empowering their sales force to author contracts and proposals without having to leave Word when fetching data from the LOB system for the document.

After catching up with a business contact for dinner, I went to the Rum Jungle to join a horde of fellow Danes. Supposedly, 230 Danish SharePoint enthusiasts have made it to the conference. I guess a trip to Vegas sounds like too much fun for a Dane to miss out on!

Read about Day 2.

14 October, 2009

Connecting at the SharePoint Conference in Las Vegas

Next week I will be attending the much anticipated SharePoint Conference in Las Vegas. The build-up has been staged with barely any details being revealed about SharePoint 2010 beforehand. More than 7,000 attendees will be looking to learn all about this milestone release and Steve Ballmer himself will provide the keynote. Every attendee, exhibitor or speaker I have talked to certainly has high expectations.

We will without doubt see many new capabilities that will consolidate SharePoint as the market’s leading horizontal business productivity platform. I will direct my focus on any expects of SharePoint 2010 that will affect interoperability with SAP. There are some promising new features for accessing business data which will undoubtedly play a key role in driving the idea of surfacing SAP through SharePoint. And with SAP investing heavily in service enablement there should be some exciting years immediately ahead of us.

Learning about the new features and potential of SharePoint 2010 is obviously a key objective of attending this conference. But even more important is the opportunity to exchange experiences with many colleagues from around the world. I have already organised to meet up with 12-15 people that are active in the SAP/Microsoft interoperability space, but I am always looking to connect with colleagues so if you want to discuss surfacing SAP through SharePoint at the conference please ping me on Twitter (@kalsing) or contact me here.

05 October, 2009

Another way of accessing SAP data with the SharePoint BDC

Five months ago, ERP-Link and Nintex announced a partnership aimed at integrating SAP data into SharePoint workflows. Now another strategic partnership between third-party vendors focusing on SAP/Microsoft interoperability has been announced. Simplement and Lightning Tools have joined forces to make it easier to use the SharePoint BDC to access SAP data.

Using the Simplement Data Liberator, SAP data is replicated across to a separate SQL Server database as business transactions occur, using the same approach as in a live disaster recovery setup. In addition to the replicated tables, supplementary views are automatically generated which have business-friendly names for all tables and fields. This effectively empowers .NET developers or anyone using the BDC Meta Man from Lightning Tools to navigate the data with ease and without having any impact on the production instance of SAP.

The approach to accessing the data in SAP put forward by Simplement is a bit unconventional in the sense that it departs from the normal APIs and utilises the underlying database replication technologies. But the architecture has been carefully designed to have no overhead on the SAP application server and without compromising security. It is also worth noting that the founders are certified SAP professionals both on the functional side and on the basis side. When solving the actual interoperability problem, I am personally more comfortable with a solution that is lead by SAP professionals exposing SAP rather than Microsoft professionals making their way in.

The architecture can be utilised as a way of enabling real time reporting on SAP using Microsoft BI tools and technologies or to make use of the SharePoint BDC web parts in their current incarnation for bringing SAP data into SharePoint on a read-only basis. Once the BDC is configured, the SAP data can also be exposed through SharePoint search, user profiles or used as lookup data in list or library columns.

In a previous post I thrashed out the relative complexity of configuring the SharePoint BDC for SAP and the reliance on having ABAP developers creating custom web services specifically designed for the BDC. The value proposition from Simplement and Lightning Tools is that this reliance on ABAP development is eliminated. Their screencast below explains how it all works:

21 September, 2009

Book review: SharePoint Roadmap for Collaboration

A few months ago, I had to travel quite some distance to go and deliver a SharePoint governance workshop to a customer. Having to catch a couple of flights to get there gave me an excellent opportunity to read Michael Sampson’s latest book: SharePoint Roadmap for Collaboration: Using SharePoint to Enhance Business Collaboration. It was well worth my time and here is why.

I have previously expressed a concern about the general lack of focus on the deep functional knowledge of SharePoint. I can no longer count the amount of times I have come across or have heard of SharePoint implementation projects where business benefits have not been understood or even considered beforehand. From a collaboration perspective, this book fills a very important gap. If you have ever read Paul Culmsee’s excellent series on building a shared understanding with the users and want to improve in this area, then this book is a tool that will help you get there.

The book starts off by taking a step back from SharePoint and discusses why we even need it in the first place. It presents a number of frameworks for defining what collaboration as a concept, regardless of technology, means to the business and how we can get a return on the investment. I think it is fair to say that many SharePoint consultants have not spent enough time thinking about what collaboration really means in a business context. This book provides some valuable insight in this regard.

After examining what collaboration encompasses and outlining the critical success factors, Sampson evaluates SharePoint against those success factors. We get an honest assessment of SharePoint with specific examples of which capabilities the product is strong in and the ones where it is a bit immature or insufficient at this point in time. And trust me, there will be a few times where you will breathe a sigh of relief and think: ”I thought so! I’m glad I’m not the only one thinking that this just won’t work.”

Armed with the fundamental understanding of collaboration and what SharePoint is capable of doing, the book moves on to the always interesting and challenging topics of governance, engaging the business and user adoption. There are an increasing number of resources out there covering these areas, but in contrast to many of those, Sampson is very hands-on with plenty of ideas to what specific actions are required to make it all happen. Covering these topics can easily turn towards a fuzzy discussion, but Sampson manages to keep it real and provides us with some clear guidelines for approaching governance and user engagement which with no doubt are based on many years of experience in the industry.

If you play the role of a SharePoint functional consultant in the area of collaboration, then this is a must read. It is also an invaluable resource for SharePoint architects, program drivers and anyone else playing a key role in SharePoint collaboration rollouts. And needless to say that the governance workshop I delivered immediately after reading this book went very well. Sampson’s book further enhanced my ability to explain the central issues to both the business and IT.

11 September, 2009

Talking Office Business Applications and SAP on TechEd Online

Microsoft TechEd Australia is over and it was certainly a well-organised and fruitful event. There were lots of valuable sessions and as always it was great to catch with all the usual suspects from around the country.

I had the pleasure of being an invited speaker delivering a session about Office Business Applications (OBAs) and in particular how we can leverage this architecture to bring SAP functionality out to more users. If you missed my session, I did an interview in the ‘fish bowl’ for TechEd Online that summarises the key points:

OBAs: A strategy for unlocking the value in your ERP investment.

02 September, 2009

Presenting on OBAs for SAP at Microsoft TechEd Australia

Next week I will be heading back to the Gold Coast (I have only just returned from a very fruitful Microsoft Partner Conference there) for Microsoft TechEd Australia. Reading the TechEd Backstage blog it is shaping up to be a massive event and I am really looking forward to it. I will be doing a session with Domenic Chiera on Office Business Applications (OBAs). The session details are as follows:

OFC330 Integrating LOB interfaces into familiar ones
Presenters: Domenic Chiera, Kristian Kalsing
Thursday 10 September | 15:30-16:45 | Meeting Room 7
The average Enterprise Organisation has 32 Line of Business Applications. The rub is that on average 31 interfaces are provided to end users for these 32 applications leading to increased training costs, application switching, and little reuse of data between applications. In this session learn how to consolidate the number of interfaces for end users into their productivity environment and create Office Business Applications to give a single interface to the applications and data through Office.

Domenic will provide an overview of what OBAs are, why they are valuable to the business and what components constitute an OBA. I will demonstrate real-world solutions where SAP is the line-of-business system surfaced through Office and discuss the critical success factors in designing and implementing these solutions.

Throughout the conference I will be keen to catch up with anyone who wants to discuss integration with SAP. The Microsoft application platform provides an excellent opportunity to bring SAP data and functionality out to more users. Just ping me on Twitter (@kalsing) or through OCS on the conference network and we can find an appropriate place and time to meet up.

27 August, 2009

The new Duet architecture

Duet is a solution jointly developed by SAP and Microsoft. The solution allows information workers to interact with common SAP business processes through the Microsoft Office environment, leveraging the best of both worlds.

The uptake has not been impressive so far, but with a complete overhaul of the architecture, we can have high expectations for the future 3.0 release. Duet 3.0 will be the next major release after the current Duet 1.0/1.5 (there will be no Duet 2.0).

Not many details about the Duet roadmap have been released, but the latest I have gathered from various conference presentations is that we can expect Duet 3.0 around 3-6 months after the Office 2010 release, in other words probably towards the end of 2010.

The two major concerns about the current version of Duet is the relative complexity of the architecture and the lack of an SDK. Both of these concerns will be addressed in Duet 3.0. There will be a comprehensive Duet SDK alongside a complete toolset which will enable Duet extensions and customisations.

Duet 3.0 will also have a revamped architecture. There will no longer be a specialised Duet Server in the mix. Instead the communication between Microsoft Office and SAP will be facilitated by the SharePoint Business Connectivity Services (BCS), which is the evolution of the Business Data Catalog (BDC) in SharePoint 2010.


The new architecture will lower the barrier of entry as many organisations already have a SharePoint environment and the associated capabilities which can be utilised in a Duet deployment. Hence, it will become quicker and cheaper to get that initial pilot deployed.

By relying on SharePoint infrastructure rather than a specialised Duet Server, there is also potential for significantly lowering the total cost of ownership (TCO) of Duet solutions. How much easier will it be to find SharePoint resources to implement and manage the solution infrastructure compared to Duet Server resources?

09 August, 2009

Enterprise mashup slide deck from SharePoint Saturday Sydney

This weekend I had the pleasure of speaking about enterprise mashups at SharePoint Saturday Sydney. Thanks to Brian Farnhill and Ben Walters for putting in an enormous effort as organisers. For a community-driven event, it was run very professionally. The bar has been set high for SharePoint Saturday’s further foray around Australia.

My session was about leveraging SharePoint as a platform for enterprise mashups, first of all focusing on bringing LOB system data closer to the casual user. Thanks to all of you who came to my presentation. I am yet to create screencasts of the demos but the slide deck is available here:

As promised on Saturday, here is a list of resources that will be helpful if you want to create mashups similar to the ones in my demos:

  • AE Google Map Web Part
    I used this free web part for the Office Directory. There are also quite a few commercial ones out there with slightly more functionality.
  • Business Data Catalog Resource Center
    The BDC is the cornerstone component when bringing business data into SharePoint. There is a dedicated resource centre on MSDN.
  • White paper on using the SharePoint BDC to access SAP data
    If you are interested in accessing SAP in particular, then this white paper is a good place to start.
  • Customize the Search Result (using XSLT)
    The rendering of the search results was customised using SharePoint Designer as described in this blog post.
  • Binary Free SharePoint Twitter Search Web Part
    The Twitter web part in the Single View of Customer demo was created using the data view web part following the approach in this post.
  • SharePoint Reviews
    The eco-system of partners and products around SharePoint is constantly growing. This site has a broad directory of web parts you can potentially include in your mashups.
  • ProgrammableWeb
    This comprehensive directory of public APIs and mashups is a good place to look for value-adds and other functionality you can bring into your mashups. It is also a great source of inspiration.
  • Accessing business data with SharePoint 2010
    We briefly discussed the evolution of the SharePoint BDC into Business Connectivity Services (BCS) in SharePoint 2010. In this post, I elaborate a bit more on that.

As I have a particular focus on the integration with SAP, I am more than happy to hear from you if you have any questions in that regards.

04 August, 2009

Book review: Microsoft .NET and SAP

Not long ago, a second book entirely dedicated to SAP/Microsoft interoperability was released. I previously promised that I would share my thoughts on the book when I had had a chance to go through it, so here they are. The book is authored by the guys over at the SAP Global Alliance Technology Team at Microsoft. Not many people have as much knowledge about SAP/Microsoft interoperability as these guys do, so they certainly have the in-depth understanding of both technology stacks required to write a book like this.

The first couple of chapters provide a broad overview of the technologies and tools in both stacks that are relevant in the context of interoperability. It also includes a historic outline of joint initiatives between SAP and Microsoft, from the early days of bringing SAP to the Windows platform up to recent developments such as the Portal Development Kit for .NET and the looming Duet product. This is quite an interesting read providing a nice 10,000-foot perspective before diving in deep.

The book then moves on to detailed walkthroughs, starting with exploring the different architectures for obtaining connectivity between .NET and SAP. You will learn about the SAP Connector for .NET, SAP Enterprise Services and the various incarnations of the BizTalk and WCF Adapters. This is arguably the most important chapter as it gives you the basic understanding of the technical architectures that underpin any SAP/Microsoft interoperability solution.

The five following chapters specialise in five different main areas: Business intelligence, SharePoint/NetWeaver integration, SharePoint Business Data Catalog (BDC), Office Business Applications (OBAs) and custom development. Each chapter provides detailed walkthroughs of how you get started with each individual style of solution. A lot of the content in these chapters is somewhat similar to what has already been published in various white papers, but the book is more thorough and includes lots of screenshots. Note, that depending on the versions your are running of the different products the screenshots in the book could vary quite a bit from what you have in your environment, but there is enough information in there for you to easily work it out anyway.

The last chapter is dedicated to security and identity management which is quite an important topic in this context. Given that obtaining the appropriate security architecture is a critical success factor and the relative complexity of the subject, you could probably have wished for a bit more content in this area. But then again, you could easily write a whole book on security if you wanted to cover it on a practical level. The security chapter in this book gives you a helpful introduction to the key components in play.

In summary, this book meets the expectations in terms of providing a comprehensive guide to SAP/Microsoft interoperability with enough depth in key areas to assist you with prototyping some solutions. Not only does this book give you some great tutorials if you are just getting started with interoperability, but it is also a useful reference you will regularly come back to down the track.

15 July, 2009

Presenting on SharePoint enterprise mashups at SharePoint Saturday Sydney

SharePoint Saturday is a community-driven event offering a full day of SharePoint sessions and open to anyone for free. The first SharePoint Saturday was held at Virginia Beach in the US back in January this year. It has since spread quickly across North America as a very popular event with good numbers signing up to come and see all the great speakers that haven’t hesitated to support the initiative.

SharePoint Saturday is now going global with the first event outside of North America coming to Sydney on the 8th of August 2009. This remarkable community conference will continue its foray into Australia with local editions already being planned for Adelaide and Brisbane later this year.

I’ve committed myself to deliver a session at the Sydney event focusing on utilising SharePoint as a platform for enterprise mashups. I will demonstrate how you can leverage the Business Data Catalog (BDC) to bring data from your ERP system and other sources into SharePoint and then use this business data in mashups and composite applications. The mashups will blend structured and unstructured data as well as utilise various Internet services to provide users with a single view of related information.

People have been quick to sign up for the event and it’s filling fast. If you want to grab one of the remaining spots, head over to the SharePoint Saturday Sydney site for instructions on how to enrol. Be quick!

13 July, 2009

Accessing business data with SharePoint 2010

The SharePoint Team at Microsoft has just released a Sneak Peek video showcasing some of the new features of SharePoint 2010. Although the video only shows a small subset of what’s coming, it’s certainly enough to get everyone excited. A much richer user experience addresses several common pain points and in terms of integration with business data from other systems significant improvements are in the pipeline.

The user experience is now a lot closer to what we are used to from the Office 2007 client applications. The contextual ribbon is the prevailing interface providing an even more consistent user experience across Office clients and SharePoint sites. User dialogs are generally handled by frames on the forefront with a grayed out background, eliminating lots of time-consuming page post-backs. Web page editing has a rich user experience similar to editing Word documents and finally users can upload images on the fly when adding pictures to web pages (sigh!).

From my perspective, currently specialising in bringing ERP business data (from SAP in particular) into SharePoint, there is massive potential in the new version of the SharePoint platform. First of all, the cornerstone feature of LOB system integration has been upgraded significantly. The Business Data Catalog (BDC) is now called Business Connectivity Services (BCS) and have three momentous improvements:

  • Vertical support for reading and writing business data. The BDC sort of had support for writing back to LOB systems through the object model, but the BCS now take this to a whole new level. You will be able to create an ‘External List’ where you can create, read, update and delete business data like with any other SharePoint list. It is, however, still unclear how easy it will be to customise the list forms and the ability to create filtered lookups is also high on the wish list in this context.
  • Integration with Office allowing users to take business data offline. Users will even be able to edit that business data offline which will then be synchronised with the back-end system when connectivity is restored. SharePoint Workspace, formerly known as Groove, is the rich client for SharePoint providing extensive offline capabilities and plays a central role in this. The External Lists mentioned above will be editable through SharePoint Workspace when offline.
  • Better tools for modelling business data entities. In my opinion, this has been one of the major holdbacks with the BDC up until now. Adequate tools for authoring the application definition files were lacking. Now, both SharePoint Designer and Visual Studio will provide a much improved toolset, including visual design surfaces, for modelling business data entities for the BCS.

Another new capability that will bring business data to life within SharePoint, is Visio Services. Similar to InfoPath Services and Excel Services, Visio Services enable browser-based rendering of Visio diagrams. With Visio already being able to connect to external data sources this will allow business users to create process and workflow diagrams reflecting data in LOB systems and easily publish those to a SharePoint site.

All of these improvements will help move SharePoint in the direction of becoming a truly capable platform for composite applications and enterprise mashups. It will be simpler and more cost-effective to integrate business data into those composites and mashups.

08 July, 2009

Presenting on SAP/SharePoint interoperability at the Brisbane SharePoint User Group

This coming Wednesday (15 July), I’ll be presenting at the Brisbane SharePoint User Group (#BSPUG) on SAP/SharePoint interoperability. I will cover the motivations behind bringing SAP enterprise data and functionality into SharePoint and give an overview of available interoperability options.

One of the key features of SharePoint that enables integration with back-end business systems is the Business Data Catalog (BDC). This session will include live demos of solutions showcasing the different ways of utilising the BDC. There will also be examples of concepts like custom search results rendering, enterprise mashups and portlet syndication.

Although the demos are based on scenarios where business data is sourced in SAP, the concepts covered can be applied to any ERP back-end or other line-of-business applications. In other words, do not hesitate to come along even though your company or clients are not running on SAP.

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

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…)

07 April, 2009

List of SAP/SharePoint interoperability resources

Following up on my presentation to the Brisbane SharePoint User Group (#BSPUG) last night about bringing SAP data and functionality into SharePoint, here’s a list of resources you should be aware of if you are playing in this space:

White papers


  • Microsoft .NET and SAP
    February 2009
    This has just been released and it is the first book dedicated to .NET and SAP interoperability.


  • WSRP Toolkit for SharePoint 2007
    December 2008
    Provides sample code for producing WSRP conformant data from SharePoint lists and libraries. That data can then be rendered natively in SAP Portal.
  • OBA Sample Application Kit for SAP
    February 2008
    Sample Visual Studio setup for building OBAs interacting with SAP. Includes sample Application Definition files for the SharePoint BDC.

If you have anything to add to this list, please let me know. You may also want to check out some of my previous posts:

19 February, 2009

Do we need SharePoint functional consultants?

There has been lots of debate lately around why SharePoint projects fail and what’s currently wrong with the way SharePoint implementers engage. Paul Culmsee has written a landmark post about the criticality of user understanding as an important prerequisite for user engagement. Jeremy Thake has a great wrap-up of how the industry currently works. And then there’s all Joel Oleson’s work around governance and best practices which is also highly relevant in this context. A lot of the issues boil down to a lack of understanding SharePoint for what it is and in particular taking the users along this journey of shared understanding. The question is how do we change our approach to accommodate this?

I’ve spent the last 12 months in the world of SAP. On SAP projects the roles of consultants are typically very clearly defined. Not only is there a much clearer distinction between infrastructure (basis) consultants, developers and functional consultants, but the functional consultants themselves are very specialised in different parts of the SAP system. The role of the functional consultant is to work closely with the business to determine the requirements, configure SAP to meet those requirements and provide knowledge transfer to the users. To be able to do that effectively, the functional consultants are required to have the relevant business experience.

The point is that the consultant configuring the finance module is basically an accountant and the consultant configuring the HR module probably studied human resources at university. In the SAP world, it would be absurd to take someone who has configured materials management or plant maintenance with one client and ask them to configure HR with the next. In SAP, the specialisation does not stop with the functional areas of the product. There are also functional consultants building up experience in certain industries. E.g. supply chain management can be very different when talking coal mining compared to running supermarkets.

In the SharePoint world, we often see technical consultants one day building an intranet for the marketing department in a bank and the next day they are configuring Excel Services for the financial controllers in a mining company. Isn’t that ludicrous if you really think about it? Although drawing parallels between the worlds of SAP and SharePoint might be a bit of a stretch considering SAP as a product is humongous compared to SharePoint, I do believe there are some lessons to take across.

What if we had the concept of SharePoint functional consultants? Consultants that did not necessarily have a technical background but were business experts specialising in for example collaboration, business intelligence or enterprise content management. They would first of all have business experience in their respective fields and then be trained up in configuring SharePoint functionality to build solutions. When they do reach the limits of what the product can do out-of-the-box, they would request feature development from SharePoint technology specialists and developers.

The functional consultants themselves would spend the majority of their time developing their expertise in their area of specialisation. A collaboration consultant would understand the issues arising from people working together and the business benefits of effective collaboration. An enterprise content management consultant would have real-life experience in document management and understand the requirements of the ISO15489 international standard on records management.

So, isn’t this why we have business analysts? SharePoint implementers do sometimes engage business analysts to work closer with the business in analysing and specifying the requirements. Whilst this is great for defining scope and mapping out immediate needs, the analysts do not usually help to bring about the shared understanding of SharePoint with the users. Because they don’t usually get involved in configuring SharePoint, they are rarely effective at communicating the real benefits of SharePoint as a platform.

In further defining the SharePoint functional consultant, what we need is a role with the business knowledge and analytical skills of the business analyst, but with far more functional knowledge of SharePoint. They must be able to build solutions through the UI, but not concern themselves with the technical aspects of SharePoint. A SharePoint functional consultant would take care of the functional configuration which includes lists, libraries, content types and basically anything someone with site collection owner privileges can do. This is not to be confused with non-functional configuration which includes web applications, load balancing, backup processes and the many other tasks requiring farm administrator privileges and which is carried out by SharePoint technical consultants.

So maybe it is time that we start thinking along those lines and develop the concept of SharePoint functional consultants? I have come across a few people that seem to fit the bill. However, there are not many of them and they never work for the implementers. They are typically ambitious people from the business that have learned to configure SharePoint by trying to address their own pain points with it.

18 February, 2009

EP/MOSS portal technology strategies

An increasing number of enterprises running SAP on the back-end are ending up with two portal technologies in play, SAP NetWeaver Enterprise Portal (EP) and Microsoft Office SharePoint Server (MOSS). This raises the important question of how much of each do they need? Can they get away with just one portal technology? Or do they have to develop capabilities in both? If your organisation is in this position, this article might provide some food for thought and input to your portal strategy conversations.

The following will define nine high-level portal strategies utilising EP and/or MOSS based on the footprint of each product. For the purpose of this discussion, there are three options available for each of the products: no deployment at all, standard deployment only with no custom development or full-scale deployment including developing custom functionality.

No portal strategy

Your choice is to not provide any portal technologies. This will require most users to be trained up in multiple LOB applications and you are unlikely to meet their expectations in terms of ease of access to information and there will be little integration across the business.

At this point in time, not many organisations do not even have a basic portal in their environment.

One portal strategies

A one portal strategy has the great advantage of only requiring one technology stack. An organisation with a one portal strategy can save substantial costs on the IT budget by only having to support one technology. The downside is limited capabilities in terms of serving a user base with a broad range of functional requirements.

Standard EP only

Typically seen in small to medium-sized organisations with a limited number of desk workers. Only a very basic intranet is required and maybe a few standard business packages such as ESS.

EP only

You want the ability to provide a wide range of portal capabilities but you have no intention of adding MOSS to this. This is typically in organisations where the Microsoft Office suite is not part of the end user environment. Your email is in Notes, GroupWise or something else.

You might consider to leverage the extensive document management (DMS) capabilities of the NetWeaver stack, particularly for controlled documents with a clearly defined lifecycle. For the content of more collaborative nature you can apply NetWeaver’s knowledge management (KM) functionality to information from various repositories.

Standard MOSS only

Not running EP at all and only deploying limited MOSS functionality is only seen in small to medium-sized organisations. Typically there would only be a limited number of desk workers who require basic collaboration functionality.

MOSS only

The key strength of MOSS over EP, is the way it serves knowledge workers. MOSS is designed around people and is great for collaborative content. If you are running MOSS only, your organisation will be dominated by a large number of knowledge workers, all using the full suite of the Microsoft Office productivity tools.

Although this could be a valid strategy, it is unusual for organisations running SAP not to have any EP footprint at all exposing some of the SAP transactions. But you do have the option to develop user interfaces for that functionality in .NET and deploy it through MOSS.

Dual portal strategies

If you choose to deploy both products, you will potentially need to build some capabilities in both. However, it is still feasible to pursue a dual portal strategy without having to build strong capabilities in both technology stacks if you use one technology as the main portal environment and leave the other as vanilla as possible.

My experiences from talking to lots of SAP-centric organisations indicate that a dual portal strategy is the prevailing approach. And even research from SharePoint’s early days confirms this.

EP and standard MOSS

EP is the corporate portal. MOSS (or even just WSS) are used to provide standard document libraries and collaboration workspaces. Your organisation is committed to EP but is starting to feel a demand from the business for SharePoint collaboration tools, i.e. team sites. You want to limit SharePoint to standard team sites only.

Although you’re confined to be using standard SharePoint team sites, governance is still important, particularly around the site provisioning process.

Future enhancement packs for EP will support this architecture by providing functionality that will allow access to content in distributed SharePoint libraries.

MOSS and standard EP

MOSS is the single entry point for all users. It is the intranet portal. You will have a large user base of information workers. These workers perform most of their tasks using Microsoft productivity tools, such as Outlook, Excel and Word.

EP is used as is for transactional functionality such as ESS and other standard business packages. You can consider bringing IViews forward to MOSS by using IView Web Parts.


Going down this path provides the highest degree of flexibility in terms of addressing almost any possible business requirement. It also entails the highest degree of technical complexity and requires strong capabilities in both technologies. Only large organisations should consider this a feasible strategy.

Building capabilities in both technology stacks effectively means utilising competent people from both areas. Competent people have typically spent a significant part of their career focusing on their technology of choice and will naturally be passionate about the associated products and be strong advocates of using those. That gives rise to a managerial challenge of making sure both camps subscribe to the idea of leveraging the best of both worlds.

You will also be faced with having to make a decision on which portal product will be your “portal of portals.” This can go either way. And if you asked SAP and Microsoft, I bet they would both put forward a strong case for their respective products.


If your organisation is running SAP, you will likely have to make a strategic choice for the footprint of the two portal technologies. This choice will dictate how you structure your IT department and what capabilities you will need to build.

In this article, I have outlined the available technical strategies. Making the choice is the real challenge and ultimately depends on what functionality you want to offer to your user base. EP and MOSS have different strengths and weaknesses and understanding those is highly beneficial when analysing the requirements from the business.