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.

04 February, 2009

Positioning SharePoint against competing products

If you are working as a SharePoint consultant you are likely to often encounter questions as to where SharePoint stands against competing products. Here are some resources that will help you answering those questions.

The Gartner Magic Quadrant is a research tool designed to provide unbiased qualitative analysis of market trends. This research is conducted for more that 100 specific technical industries and outlines strengths and cautions for all the major players in each of the respective areas.

The following is a list of Magic Quadrants from Gartner that have the most relevance from a SharePoint perspective and they contain lots of valuable information if you are trying to position SharePoint in the marketplace. They all position Microsoft among the leaders compared to competing offerings with the only exception being the magic quadrant for social software which is yet to find a leader.

Update: Unfortunately, public access to all the links below has expired.

Note, that SharePoint is not the only product from Microsoft earning them these merits. But it certainly has a part to play in all of the above and looking at the broad range of capabilities listed underlines that SharePoint is a horizontal platform more than anything else. If you look at each of the specific industries, then there are always more specialised products taking the lead. However, as a broad platform providing a wide range of capabilites SharePoint is hard to beat.

02 February, 2009

New white paper on using the SharePoint BDC to access SAP data

A new white paper has just been released on TechNet: Integrating SAP data by using the Business Data Catalog. The white paper has step-by-step guidelines for exposing standard BAPIs in SAP as web services and configuring the BDC in SharePoint to consume those.

The white paper does not cover creating the actual application definition file which, in my opinion, is the challenging bit when using standard SAP BAPIs. The inout parameters that BAPIs make extensive use of are quite tricky to deal with when building the application definition.

There are basically two approaches to providing SAP web services for the SharePoint BDC:

  • Follow the approach of the white paper above and only expose standard BAPIs as web services. The great advantage of this is that no ABAP development is required. All you have to do on the SAP side of things is some relatively basic configuration. But you will be limited to what is available through BAPIs and authoring the application definition file can be challenging. However, application definitions should not vary much from system to system, so sharing these on the web could solve this over time.
  • Alternatively you can go down the path of developing custom ABAP web services as suggested in a previous post. This gives you full flexibility in terms of the data you can provide and because the web services are designed for the BDC, the application definition files could even be generated automatically.