NOTE: For more on this topic, please check out this episode of the Office 365 Developer Podcast where I discuss these topics with Microsoft’s Jeremy Take; it was a great discussion!

For many years, Microsoft and others in the SharePoint community promoted SharePoint as a Platform. The idea was to develop business applications within SharePoint sites, and thus to gain access to all the rich services SharePoint brings to the table such as document management, search, user profiles, enterprise content management, and more. Another promise of this approach was that IT could support one big application (SharePoint) and deliver may smaller applications to business users, and thus deliver on the “long tail” of application needs.

Microsoft invested in features like Business Connectivity Services and the Secure Store (identity mapping) service to make SharePoint a capable platform for building business solutions that integrate with other Line of Business applications. Yet this approach wasn’t all we had hoped it would be.

Here are some of the reasons:

• The tight coupling of solution code to SharePoint meant that it was often difficult to upgrade SharePoint once it had been customized. The “Fab 40” applications provided by Microsoft for SharePoint 2007 are a good example of this; it was impossible to upgrade SharePoint without breaking some of these applications. As a result, many companies still maintain a SharePoint 2007 farm just for one or two Fab 40 applications, which is much more expensive than it would have been to simply build discrete applications in the first place.
• SharePoint’s user interface is dated; it’s very heavy weight and not “responsive” and doesn’t work well on mobile devices. In 2007 the SharePoint UI was an asset, but now it’s a liability unless you’re using a lot of its built-in features.

Meanwhile, Microsoft has introduced a rich set of client-side API’s for SharePoint, with client side object models for .NET and JavaScript as well as a rich collection of  RESTful web services. As a result, it’s now possible to use SharePoint as a set of services instead of as a platform.

SharePoint as a Platform	SharePoint as a Service
Application runs on SharePoint pages and infrastructure	Application runs with any page model on any web platform
Application in SharePoint accesses Line of Business data through BCS, web services, etc.	Application outside of SharePoint accesses Sharepoint data through client API’s and web services
Application gets access to SharePoint capabilities such as document management, search, profiles, and more	Application gets access to SharePoint capabilities such as document management, search, profiles, and more

SharePoint as a Service is a 180 degree pivot from SharePoint as a Platform; where SharePoint as a Platform pulled business data into Sharepoint, SharePoint as a Service pulls SharePoint data into a business application. Both are good and valid approaches to business applications that use SharePoint.

Choosing the Best Approach

In general, if you want to make use of a lot of SharePoint’s out-of-the-box user interface, then SharePoint as a Platform is still the best approach. If users will manage documents, compose web pages from web parts, etc. in your application, it would be silly to reinvent the wheel in your application.

On the other hand, many applications strive to “not look like SharePoint”, and are more about consuming SharePoint content than creating it. If your user interface is highly customized, needs to be responsive, or is tailored to a unique user experience, you might do better to build an application outside of SharePoint and use those rich API’s to pull in the SharePoint services you need.

Here are a few real world examples:

1. Simple Intranet – A company wants to build a simple Intranet and allow business users to publish information. Branding needs are simple, and most of the requirements can be met with SharePoint web parts.
   SOLUTION: Use SharePoint as a Platform; make a few tweaks but stick to the out of the box experience.
2. Complex Intranet – A company wants to build a customized Intranet that reflects its brand identity, is responsive, and includes a number of industry specific features.
   SOLUTION: Build the user interface from scratch using technologies such as ASP.NET MVC and AngularJS. Use SharePoint as a Service to access documents, search enterprise content, and pull in profile information about users.
3. Project Sites – A company wants a collaboration site for each project where users can share documents, schedules, task lists and project contacts, etc.
   SOLUTION: Use SharePoint as a Platform where users can access built-in document and list management features. Allow users to innovate by creating their own lists and web part pages on a project by project basis.
4. Specialized Portal – A company wants to build a domain specific web portal to manage knowledge that’s relevant to their industry and unique way of doing business. The portal needs document management, search, and other services that are part of SharePoint, and there’s no reason to develop those services from scratch.
   SOLUTION: Use SharePoint as a Service; build the portal from scratch in whatever web technology is easiest and most appropriate, and call SharePoint API’s to access only the services you need.

There are a number of choices for developing solutions that use SharePoint as a Service. If you’re in Office 365, consider developing an Office 365 Add-in with the new Active Directory Authentication Library (ADAL); this is a simple approach that allows single sign-on between your application and Office 365 services such as SharePoint Online. If you’re on premises and have the Add-in model configured, a Provider Hosted Application can provide the needed security integration. Or, you can go entirely custom and develop a solution however you wish, accessing SharePoint services under a service account or by accessing the user’s identity using Kerberos or directly from a client side application.

Microservices

Using SharePoint as a Service opens the door to the new world of microservices, an architecture in which an application is developed as a suite of cooperating services, each running in its own process, and communicating using light-weight methods such as RESTful web services. This allows application components to be released independently, and even to be built with different technology stacks. There are a number of advantages to this approach, including scalability, reusability, and the ability to build LEAN engineering teams responsible for each microservice.

Martin Fowler has written on this topic; his seminal article is here and is a great introduction. Another great article from my colleague Bob Familiar is available here.  One of the nice things about microservices is that they can be introduced gradually, with one servie at a time replacing the services of a monolitic application.

A good example of this is the new workflow engine used in SharePoint 2013. The old workflow engine was baked into SharePoint. To scale the old workflow engine required scaling all of SharePoint, and upgrading it required updating all of SharePoint with all of the associated challenges and testing. The SharePoint 2013 workflow engine is deployed as a separate product – Workflow Manager – that can be deployed, scaled, and upgraded independently. This is in line with microservices architecture and offers the benefits of being an independent, loosely coupled service.

You can use microservices along with SharePoint services in business applications to reap the same benefits. The microservices can be developed in Microsoft Azure or other cloud environments, providing the advantages of microservices along with the power of SharePoint’s rich suite of services. Here is a sample architecture for such a solution, which uses Azure based microservices alongside document management services from SharePoint Online.

The application is developed as an Office 365 add-in using ASP.NET MVC. A WebAPI gateway is provided to broker calls to the microservices; this is a common pattern that allows hiding the specifics of microservice semantics and security details. The application itself is developed as an AngularJS application that accesses business data via the API gateway and microservices, and SharePoint Online content via the REST API. ADAL provides authentication for the MVC application and WebAPI gateway, and ADAL.JS provides authenticaiton to SharePoint online. (Helpful tutorials are available here to get started with this.) The result is a modern, responsive application with a single sign-on experience across both SharePoint services and line of business microservices.

Conclusion

There has never been a more exciting time to be a SharePoint developer. In addition to the option of using SharePoint as a platform, we can now make use of the latest advances in application design such as responsive, single-page applications backed by microservices.

As an application architect and developer, don’t be limited by the offerings that Microsoft spells out in its documentation, such as using SharePoint as a platform or the SharePoint add-in models. Many developers see the SharePoint add-in model and assume they’re supposed to use SharePoint as a Platform with add-ins in place of the traditional server-based farm and sandboxed solutions. However there are as many options as there are ways to develop applications! As long as you call SharePoint’s API’s in a supported way, which mainly means using proper authentication and security measures, the sky’s the limit in terms of application design. Choose an approach that allows you to leverage as much of SharePoint as possible without being burdened by aspects that you don’t need. And enjoy being part of the greater development community building modern applications backed by SharePoint’s cornucopia of services!