Business-Centric Strategy for running successful Sharepoint Projects

OK , so you think you are a very good Project Manager. You have all the skills to manage software projects – a wide range of Expertise, Performance-Ability and Personal skills. Good!  You also have solid track record delivering successful web development projects. Excellent!

Now, with all your confidence and rich experience you started managing Sharepoint Projects. Despite combining power of all your niche skills – Technical, Managerial and even Political😉 , you find your sharepoint projects are not ‘well received’ by key stakeholders and end users. You are consistently worried about the fact that your Sharepoint solutions are not ‘long lived’. Also, your Senior Mangement don’t see Sharepoint delivering real business value despite huge investment.

Finally, You  (and your organization) have started thinking that Sharepoint is a problem rather than a solution!

Is Sharepoint really a problem?!  The answer to this question is YES – if you and your organization never thought of devising solid Business- Centric Portal Strategy with an eye towards implementation.

For non-sharepoint web projects to be successful, it may be enough to adopt IT practices and frameworks ( like ITIL and MOF) , follow good project management processes (like PMBOK or PRINCE2) and build cohesive team of developers, system administrators and testers. BUT, For running successful Sharepoint projects, you need one more weapon – a solid Portal Strategy. Before you start with a Sharepoint Project, the first and most important thing you need is to invoke your analytical powers and come up with a Portal Strategy.

Sharepoint is a beast. It is a platform and an application – both. From application point of view, Sharepoint require a number of hardware and software technologies to run smoothly to deliver best productivity experience. As a platform, it supports huge customizations and  development to provide solutions that are cost-effective and enables you to rapidly respond to business needs. It can deliver great value, provided you know how to tame it. Without a well thought strategy to act upon, you will loose control over Sharepoint . And very soon Sharepoint will start controlling you.

After a lot of analysis, I have come up with 7 elements that together define a generic business-centric Sharepoint strategy. By implementing the portal strategy ( and refining it as per the  scenario or context you are in ), I am optimistic that you will be able to build, deploy and run Sharepoint based solutions that resonate with Business.

There 7 key areas you need to work upon proactively  :

  1. Enage Key Stakeholders
  2. Understand Business Drivers
  3. Align Operating Model
  4. Understand all dimensions of Portal Architecture
  5. Establish Governance
  6. Ensure Business Continuity
  7. Continuous  Refinement ( of 1-6…)

Sharepoint Portal Strategy


1. Engage your key stakeholders

You must do a thorough research into business needs and expectations of your key stakeholders. Understanding them will enable you define a portal strategy most suited and aligned to objectives of  organization. A typical engagement should begin at the top level with Senior Management. Starting from top will help you to understand and focus on the themes and areas which Management want to improve.The top-to-bottom approach works best because senior stakeholders will point you in direction of quality people to work further. In most common scenario, below can be your stakeholders :


2. Understand Business Drivers

You should ensure that clear business drivers have emerged from your key Stakeholders.Some common business drivers that apply to most business are :

  • Improve Employee productivity and collaboration
  • Lower IT costs
  • Improve Business performance
  • Knowledge management and retention

Understanding of business drivers will help you to define a way in which your Sharepoint Solution should provide capabilties and services to organization and finally help to establish the success criteria of your Sharepoint solution.


3. Align the operating model

You also need to ensure that all project management processes, work procedures,  technologies and supporting systems are well aligned to work in harmony with success factors you have defined.



4. Understand Portal Architecture Dimensions.

To design for Reliability ,Flexibility and Maintainability, you need to have good understanding of multi-dimensional Sharepoint Architecture.



5.Establish Governance

Sharepoint provides capabilities that are almost unsurpassed and empowers with , both – wide & deep- range of flexibilities. This is the power of Sharepoint, but in absence of Governance , it can cause big issues. Governance is very important to ensure that your solution is ‘long lived’. I have written entire post on it : Effective Sharepoint Governance : A must for Sustaining the Success



6. Ensure Business Continuity

Almost all of the times, Sharepoint applications  are considered business critical. Still, most of the times, a proper business impact analysis is not performed for these applications. This refers to poor Business Continuity Management.

A well thought business continuity plan is very important to ensure that your Sharepoint Portal is  Highly Available and Disaster Proof.



7. Continous Refinement

Any strategy or plan is not perfect. When put into action, you may still discover problems with your strategy. Its your job to keep on refining stratgey to help for future Sharepoint projects.






Cloud Service Models { IaaS, PaaS and SaaS } : How Azure and O365 fits in

There are various broad ways a cloud-based service is consumed and utilized. In the world of cloud computing, there are three different approaches to cloud-based services:

  • Infrastructure as a Service (IaaS)
  • Platform as a Service (PaaS)
  • Software as a Service (SaaS)

Microsoft offers impressive Cloud services based on its widely used on-premises software products.

Office 365 is SaaS, which provides an online version of MS Office Suite (Office Web Apps) along with SharePoint Server, Exchange Server and Lync Server.

Windows Azure is both IaaS and PaaS, which makes the Windows Server operating system and other features….

The full post is now published on To read and have your opinion on it, Please visitCloud Service Models (IaaS, SaaS, PaaS) + How Microsoft Office 365, Azure Fit In


Leave a comment

Design Patterns for the Hybrid {On-premise:On-line} Sharepoint Solutions

With the advent of Office 365 /SharePoint Online, many organizations are willing to migrate  some of their sites and content from an existing On-Premise Sharepoint environment  to On-line Sharepoint environment. However, They still want to continue with some of the service offered by On-Premise  Sharepoint. This makes a case for Hybrid Sharepoint Solutions.

A hybrid SharePoint solution is one that combines  on-premise SharePoint features with SharePoint Online.There are several scenarios in which a hybrid solution can make sense, like:

  • Doing a phased migration of existing sites and content to Office 365 (from an existing on-premise environment)
  •  Need to leverage the best services offered by On-Premises and On-Line (such as Search, Business Connectivity Services, and Duet Enterprise Online for SharePoint and SAP)
  • Integrating SharePoint Online with the Addons,Services or Apps that must be deployed to an Sharepoint On-premise
  • Compliance to Organization’s Information Security policies that dictate where the company data  should reside.


The  main goal of a hybrid solution is usually to make both the on-line and on-premise environments look integrated to your end users. While planning to have the hybrid solutions to combine the best of both on-line and on-premise, we still need to remember that we have to deal with the two entirely separate SharePoint environments.

Below are some good desing patterns that can help achieve seamless integration :

Design Patterns for Hybrid Solutions

1. Partitioning
This pattern targets to achieve better user experience by partioning both the environments by user type, workload, company or date.

If you partition on-premise and on-line environment such that  a user rarely need to traverse both the environments, the user will observe less differences in the hybrid solution.

The ways to implementing the pattern are:

  •  Partion by user type (e.g. internal users use an on-premise environment and external users use an online environment)
  •  Partion by workload (e.g. ECM workloads online and BI workloads on-premise)
  •  Partion by the company or units (e.g., Legal may use on-premise environment due to security concerns while other departments use the online environment)
  •  Partion by date and time (e.g. new content created in online environment but existing content maintained in on-premise environment)

2. Smooth Transition

If the users anyhow need to traverse both environments,  you should target to achieve better user experience by making the traverse as smooth and seamless as possible.  For example, you should not ask for the authentication multiple times when user enters from online to onpremise environment and vice-versa. Also the branding and navigation should look uniform to both the environments.

3. Integrated View

To display related data lying on seperate environments, You should try to show it in a combined view on a single placepage only. This will have a better user experience.  To have a combined view of the data  from the lists existing in both online and onpremise environments, it is best use the client-side techniques like RSS feeds, JavaScriptJquery – Rest API and CSOM.

4. Shared Source

This pattern helps ensure consistency by having both environments (onpremise and online) use common Data Source  whenever possible. By using a shared data source your environemts are always synchronized. For example, Its good to have same User Profile DB for both environments.

5. Replication

This is actually not a pattern but Anti-Pattern! Data replication or duplication should only be done in both the environments if you are not able to use a Shared Resource.

Leave a comment

Effective Sharepoint Governance : A must for Sustaining the Success.

Like any IT project, Sharepoint projects can have successful launch if you deliver a solution that meets all the Stakeholder Requirements – on time, with Quality and within Budget. However, to maintain the success of your Sharepoint project in long run, you need an important tool in your hand- An Effective Governance Plan.Governance Framework

If you find that your project is suffering from any of the below problems, it is largley due to the lack of an effective Governance in place :

  • Inappropriate usage of the Sharepoint Solution.
  • Information mess & End-user confusion.
  • Degrading User experience and overall Quality over time.
  • A lot of Infrastructure and configuration issues.
  • SharePoint Solution becomes unstable every now and then.
  • Reduced adoption of the Sharepoint Solution.

An effective Governance Plan is vital for the ongoing success of your SharePoint projects. Be advised that , Governance Plan is important but is not all you need to ensure success. A governance plan alone will not ensure the success of your project. You still have to make sure that the governance plan is applied. However, not having a governance plan or having a plan that is either impractical or unrealistic is a clear indication for failure.

What is Governance all about

Governance is one of hot buzzwords for the enterprise IT Systems today.Below is the Microsoft definition of Governance and is a good definition actually :

“Governance is the set of policies, roles, responsibilities, and processes that guide, direct, and control how an organization’s business divisions and IT teams cooperate to achieve business goals”

The importance of Governance is also emphasized by many standard IT management frameworks, like ITIL , COBIT and MOF

Why Governance is Vital

The mission of SharePoint Governance is to ensure that :

  • Expectation of your stakeholders are met, not just after you deliver the project but also in long run.
  • Consistency and performance of your Sharepoint Solution is maintained,
  • The risks to your project are avoided and mitigated – specially when your Sharepoint Solution is live and starts Operating.
Governance planning becomes more important for SharePoint Projects because SharePoint is designed to empower end users who are typically not IT experts and may not be aware of best practices required for the smooth operation of the Sharepoint Solution.

Take an example of collaboration portal you developed on Sharepoint. The portal is only as good as the value of its underlying content. An effective governance plan is essential to ensure that the portal delivers worthwhile content to its users in an effective way.For the portal to maintain its success, you need a Governance plan that establishes the processes and roles required to :

■ Ensure the content on the Portal  is periodically reviewed for accuracy and relevance by defining a content and site review process.
■ Ensure that content quality is maintained for the life of the Portal by implementing content quality management policies.
■ Provide a consistently high-quality user experience by defining guidelines for Content and UI designers.
■ Establish a decision-making board and escalation procedures to deal with policy violations and conflicts
■ Ensure that content on the Portal is retained in compliance with retention guidelines and policies.

An effective governance can help to:

  • Manage the Stakeholder expectations for what the SharePoint Solution is being used for.
  • Ensure the performance and availability of SharePoint Solution.
  • Protect the Sharepoint Solution from inappropriate usage that will introduce threat to Stability and Consistency.
  • Avoid or Mitigate the risks
  • Understand the impact of change and Control Change.
  •  Etablish the definition of the good and bad and deal with it accordingly
 How to plan for Governance

The first step to Governance is to have a solid  Plan Document that outlines :

■ Vision statement
■ Roles and responsibilities
■ Guiding principles
■ Policies and standards

To start preparing the governance plan, you should build a team ( ideally the stakeholders should be part of it)  to help define the key decisions or principle for Governance and then divide up the work to among them. The team should include representatives from IT, Development, Quality , Training, Human resources, Corporate communications and the people responsible for knowledge management in your organization.

The Governance principles or decisions will vary in according to Project requirements.

Below are a few ideas :

  • The established security policies and principles will apply fully to the SharePoint Solution.
  • Navigational techniques, language, processes, branding, and so on, must be standardized across the SharePoint Solution to provide a consistent user experience.
  •  The SharePoint Solution should be used for the purpose for which it was designed and implemented
  • All content must have a Owner who is ultimately responsible for content management.
  • Copyrighted material will not be added without the proper authorizations.
  • The priority order for adding new functionality into the SharePoint Solution should be as follows:

1. Out-of-the-box Implementation
2. Third-party tools
3. Development

Here is a sample Governance Plan for your reference.

For more insights on Sharepoint Governance , I would recommend below sources:

TechNet : Sharepoint Governance Overview

The Five Pillars of SharePoint Governance

SharePoint Governance Strategy

SharePoint Governance: What You Need to Know to Put a Plan Together


Introducing OAUTH

OAUTH is a…. please wait!

Before I go straight to the definition of OAUTH and its elaboration, let’s talk about few things we already know to set the context. Also, my discussion on OAuth below is very generic and is not specific to SharePoint now. Once we are clear of OAuth concepts, we will see on SharePoint OAuth implementation in another upcoming post.

Apps: We all know what Apps are by now. The word App is so common now a days that I hope to see the nursery books replacing A for Apple  with A for Apps😉 Well, at least for me A is for Apps.

Service: We all understand the idea of Service. A Service can be a Web Service or API that is consumed by client applications

Service consumer : Any application that consumes a service. Now tell me what’s is the most common breed of application now-a-days that consume the Services?….guess… APPs! Yes, Apps are the most common Service Consumers now-a-days.

Service Provider: It’s the one who hosts the service and where the service runs. The service generally requires authentication so that only trusted consumers can access the restricted functionality or data offered by the service.

Now,  imagine as a developer, you have developed an enterprise application that offer users to play some interesting games on their Mobile devices. For that, you created a Windows 8 or iOS App (or any App) whose main function is to entertain user via some puzzle games on his mobile device.

Now, a new requirement is to allow the user to share the score on his Facebook timeline via your App.

               How can you make your App share the information on Facebook on behalf of User?

Isn’t it a most common and necessary requirement now-a-days? It is.

You will need to access the Service provided by Facebook (Service Provider) and authenticate your App to post on behalf of the User. An obvious solution is to ask User to provide his Facebook credentials and store it securely with you (in your DBconfig or whatever). Now, whenever the user wants to share his score, your App will use the stored credentials and post on the Facebook wall on behalf of user.

With this (bad) solution, below uncomfortable questions arise around Security, Maintenance, and User Experience.

1. Security: Is it good to ask User for his Facebook credentials and store them with your application?
Although a user may enjoy playing with your App but he will most likely hesitate to provide you what you are asking. Of course, he cannot simply trust you!

2. Maintenance: What if you want to provide the same functionality with other social platforms like Twitter, LinkedIn or Yammer? Also, it will be difficult to maintain the user credentials for all the platforms you have integrated and also keep them in sync in case the User updates his account at Facebook, Twitter, and Yammer etc.

3. User Experience: If your App makes a User feel insecure about his social accounts, he will simply abandon your App. How can you prevent it? One solution is that instead of storing credentials, you can also present a login page when he can supply credentials. However, if your App connects with many Service Providers (Facebook, Twitter, LinkedIn, Yammer and many more upcoming) and you keep on asking the credentials every time, the user will not feel your App is really integrated . Isn’t it?

The solution to all above questions is OAUTH – an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications.


OAuth is a standard way for Service providers and Consumers(Apps for example) to handle authentication. Also, the OAuth authorization framework enables a third-party application to obtain limited access to a service hosted by Service provider. By using OAuth, you can allow the user to access a service (Facebook wall for example) stored at one site(Service Provider) with another application without having to store or manage credentials at the Application side.

There are 3 main Actors in an OAuth transaction: the User, the Service Consumer ( which is generally an APP), and the Service Provider.  This gang of three are often said to form the OAuth Love Triangle.



Now, assuming that your Game APP implemented OAuth for FaceBook, it can initiate authentication using OAuth.

Below are the steps(and the technical conversation) that will occur at high level  among all parties:

1.  A user wants Service Consumer (App) to access his protected resource lying with Service Provider (Facebook) :

User: “Hey App, I enjoyed the game but now I would like you to be able to share my game score on my Facebook timeline.”

Game App: “No problem! Let me ask for permission from Facebook. ”

2.  The service consumer asks for request token from service provider.

Game App: “My user wants me to post to his wall. Please share a request token.”

Facebook: “Your request is answered. Take the token and associated secret.”

Using the secret,  the service provider is able to verify the future requests by consumer (if its coming from the valid Service Consumer).

3.  The user is redirected to the service provider where user approve the service consumer to act on his behalf.

Game App: “Hey user,  I’m redirecting you to Facebook so you can approve me for the actions you want. Take the token with you which I got  from Service Provider(Facebook).”

User: “Ok”

4.   The user sees a form presented by the Service provider which lists all the actions the Service Consumer can take on user’s behalf. If user thinks its all OK, he approves.

Facebook: “Welcome User, do you want to authorize the Game App for all the A, B, and C actions?”

 User: “Yes, I approve”

Facebook: “OK, the request token is approved for the Game App”

5.   The service consumer obtains an access token in lieu of request token from service provider

Game App: “Facebook, Can you provide an access token for this approved request token?”

Facebook: “Sure. Take the access token and secret.”

6.  The service consumer preserve the access token and secret information for later use.This information can be saved along with user account with service consumer.

Game App : Hey User, now you can share the score on your wall as long as you keep me authorized with Facebook.

User: Great! But please note I will revoke your permission on my account with Facebook anytime I wish.

7.   The service consumer accesses the protected resource (of user) on behalf of user.

 Game App: “My user wants to share score on his Facebook wall.  Here is the access token for the action”

 Facebook: “Your access token looks valid. Your request can be carried on!”


OAuth is adopted by many Service Providers like Facebook, Twitter,Google, Yahoo and all the Consumers that consume the service from them.

The initial version of OAuth is 1.0 which is  still being used by some software companies. The second and latest version , OAuth 2.0, is created to simplify development while still providing app authentication and specific authorization flows for web apps, desktop applications, and mobile devices. For OAuth history and deep details, you can go to and Wikipedia .

Let’s see SharePoint and OAuth in action in the upcoming post.

Stay in touch!



Remote Event Receivers in SharePoint 2013

Remote Event receiver is one of the two way notification options provided by the new Remote Event Infrastructure in SharePoint 2013.

In SharePoint 2013, remote event receivers are built as web services and can be one-way or two-way.

The remote event receivers can be registered with SharePoint 2013 just like the way local event receivers are registered in SharePoint 2010. The only difference is now we need to provide a web service URL in place of an assembly and class name.

Whenever an event is raised by a SP component ( like a list or site), SharePoint calls the web service and sends the event properties to the web service which carries out its business. The web service can also call back into SharePoint, authenticated via OAuth, to read and write as needed.

Below is a sample  Elements.xml of a remote event receiver registered for a list deployed as part of a SharePoint-hosted App. The web service URL and event type is specified inside in the <Url> and <Type> tags

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="">
   <Receivers ListUrl="/lists/contactus">

To create a web service for the remote event receiver, we need to implement the IRemoteEventService interface. There are two methods to be implemented from the interface:

  • ProcessEvent  This is a synchronous event handler.Use it to call code when a “before” event occurs .
  • ProcessOneWayEvent This is an asynchronous event handler. Use it to call code when an “after” event occurs .

Both the methods accept  RemoteEventProperties object as parameter from which you can determine everything about the occurred event.

The important point about the ProcessEvent is it is for synchronous processing, so SharePoint will wait until your code in the remote webservice completes. To allow cancel the event, the ProcessEvent returns an SPRemoteEventResult object that you can optionally use to let SharePoint  know how to proceed after remote webservice code is executed. The ProcessOneWayEvent method is for asynchronous processing and returns void.

For synchronous “-ing” events (like  adding, deleting, updating)  you must use the ProcessEvent method. For asynchronous  “-ed”  events (like  added, updated, deleted), use the ProcessOneWayEvent method.

You can also use ProcessEvent for the  “-ed” events , if you want synchronous processing . However, “-ed” events cannot be canceled by your remote web-service code , because the event has already occurred in SharePoint.

The below diagram demonstrates the  flow of how a remote event receiver actually works.


Below is an example of a web-service class used as remote event receiver:

public class ContactUsReceiver : IRemoteEventService
     public SPRemoteEventResult ProcessEvent(RemoteEventProperties properties)
       switch (properties.EventType)
             case RemoteEventType.ItemAdding:
             //Code to handle ItemAdding
             case RemoteEventType.ItemDeleting:
             //Code to handle ItemDeleting
         return new SPRemoteEventResult();

     public void ProcessOneWayEvent(RemoteEventProperties properties)
        if (properties.EventType == RemoteEventType.ItemAdded)
              //Code to handle ItemAdded
       if (properties.EventType == RemoteEventType.ItemDeleted)
             //Code to handle ItemDeleted

Below are some excellent resources to have good grasp on remote event receivers:

SharePoint 2013: Use event receivers to handle events in apps for SharePoint

Remote Event Receivers – Demo



Remote Event Infrastructure in SharePoint 2013 : An Extreme Overview

SharePoint is now increasingly becoming the main collaboration and data hub in the growing enterprise world. So far, SharePoint was able to address the need of two way collaboration with External Systems :

  • Business Connectivity Services and Search proved to be really impressive solutions to surface data from external LOB systems to SharePoint Portals.
  • Vice-versa, External Systems were also able to surface data from SharePoint via its web services and CSOM (although in limited ways).

So we see, SharePoint not only helped Organization  employees to collaborate but also the Organization systems🙂

As the collaboration between SharePoint and External Systems growing day by day, there felt a need of a solid notification infrastructure in order to:

  • Notify SharePoint when changes are made in the underlying data in the external systems.
  • Notify External Systems when changes are made in the underlying data in SharePoint ( via events).

This two-way collaboration is becoming  a hot requirement over the period – which SharePoint 2013 attempted with the introduction of REMOTE EVENTs.

Prior to SharePoint 2013, there was possibility to meet such requirement but via some complicated, full-trust farm solutions with many custom event receivers and web service calls.Also, this kind of development (and deployment) style is not good for the cloud version of SharePoint(Office 365)SharePoint 2013 Remote Event infrastructure provides three kind of options :

  1. Remote event receivers(for Apps)
  2. Events in external lists(for BCS)
  3. Reporting Services data alerts

We will explore all the three options one by one. I will link the upcoming posts on all three options above.
Will update you soon…

1 Comment

%d bloggers like this: