Its the year 2016. Organizations are wondering if the decade worth of customization on SharePoint has paid off ? In 2007, they built several shared service providers in MOSS to customize their business needs and keep their end users happy. In 2010, they evaluated buy vs build vs build on SharePoint vs buy for SharePoint (WebParts & Add Ins). Their productivity increased multifold and so did their time to market for their applications. In 2013 (and 2016), they developed and deployed several apps (now add-ins) using client side technologies and achieved challenging customizations for the end users. And Office 365 gave them a huge playground for apps that were built with perfection by the product companies. Now where do they head next?
SharePoint is an excellent collaboration tool with flexibility to customize business needs with out of the box features. Throw in some custom code, java script and BCS and you can build enterprise grade business application. Create some custom content types and you have reusability at its best. And then came a mandate. Conversion to the next version. Every customization, every workaround and every piece of unsupported code comes haunting your sleep. Large lists that your end users created with love and affection. And don’t mention terabytes of data in single content database that your database admin has been always warning you about, but his email ended up in your clutter.
So how did all of these happen? SharePoint architects made an informal checklist for every business problem.
- Do you require workflow ?
- Do you need item level security ?
- Are there internal users ? Or external users ? Or public access required ?
- Do you need access to external data ?
- Do you need findability ?
If the answers to above questions have 3 affirmation, SharePoint becomes the undisputed solution.
I am sure by now SharePoint Architects would be building nasty comments in their minds to criticize this article, but I am a SharePoint Architect myself. And knowing when NOT to use SharePoint makes you a successful architect. There is no defined recipe of where to use SharePoint and when not to use SharePoint.
In my opinion, Microsoft have head subtle hints from SharePoint community to fix long standing issues related to customization and Microsoft did hear them all but offered a completely different but relevant stack of product to address these issues. These are part of Azure cloud stack namely Power App, Microsoft Flow and Azure Functions.
So why do I say Microsoft Flow, PowerApps and Functions presage a new model of cloud applications? Because increasingly, cloud apps are evolving toward a lego-block model of “serverless” computing: where you create and pay only for your business logic, where chunks of processing logic are connected together to create an entire business application.
So how does this all fit in? Let’s say John Doe is a supply chain manager who wants to build a tracking system for every exception in their route management process. He wants to track all exceptions, route them for approval to stakeholders and perform some near complex business logic before sending the response to the exception team. John Doe (or a power user from his team) can create forms in PowerApps at astonishing fast speed. Want that app mobile-enabled on any smartphone? No problem, you use the Common Data Model available in PowerApps enabling a lingua franca between applications. Kick off a Flow to create next steps of assignment. And if you need some complex business logic added, have a developer use Azure Functions that can be triggered by virtually any event in Azure, 3rd party services, or on-premises systems. Azure Functions is built on a serverless architecture, which handles the heavy lifting of building highly available, scalable, end-to-end Functions.
It is easier said or written than done but so was SharePoint. But as the question of my blog post suggested, has SharePoint become irrelevant? I would say no. Not for the purpose SharePoint has been built in the first place. SharePoint is still the first choice for content management, business intelligence portal, enterprise social, enterprise search and workflow to leverage team collaboration and publishing features. But when evaluating complex application development with critical functionalities, it makes sense to evaluate vis-à-vis availability of compute time and resource for Microsoft Azure with the organization. But as the code of conduct for Architect community says, plan to leverage existing licenses and investments but not at the cost of architectural debts. That’s where we (the architects) come-in. Provide the best bet solution to the business problems. And next time a business user walks up to your desk asking can I solve this on SharePoint, calm down-take a deep breath-and show him this blog.
Disclaimer – No SharePoint Architects were harmed while writing this blog.