Beheading SharePoint (and Office 365) – the hype around ‘headless’

As originally posted on LinkedIn Pulse…

Every once in a while, a theme tears through the content management corners of the Earth that brings out the best-and-brightest to debate such a theme. One of the themes we have seen in the content management space for the better part of the last year is the concept of a headless content management system.

According to Margaret Rouse at TechTarget, “A headless content management system (CMS) delivers back-end capabilities for editing, organizing and storing all types of digital information, without regard to how that content is published, displayed or used. Compared to a conventional WCM system, a headless CMS can more easily support omnichannel delivery — including native mobile apps, mobile web apps, PC-powered webpages, speech and audio interfaces, and other digital experiences.”

She goes on to say, “A headless CMS includes a set of RESTful APIs to separate back-end content management from front-end presentation. Application developers must sort through various technical options to deliver front-end experiences that delight their target audiences and meet business needs. They need to have the insights and expertise to understand the various tradeoffs, and make the appropriate design decisions.”

The concept of headless is novel – it seems (and is often portrayed) as an ‘only upside’ technology approach. All of the power of a back-end CMS with none of the restrictions on what experiences you can create in the runtime. Not everyone is getting in the headless tugboat, however. Mick MacComascaigh (a friend, and lead CMS analyst at Gartner) told CMSWire a few weeks back that the headless movement was “hype” and went on to say that “the idea of decoupled is extremely important, but we’re [Gartner] in favor of head-optional as opposed to headless. And we’re in favor of API-first as opposed to API-only.”

You can research headless until you are blue in the face – and in the end, you will come (I think) to the same conclusions that I have. Those conclusions are as follows:

1.      Headless is [can be] powerful, but like everything else, power = significant complexity.

2.      There are niche players around the globe trying to make a name in ‘headless’ but without a defined market its lost in the product-market-fit ether. (Search “Headless CMS Companies” in Google and count how many actual organizations appear on the first two pages (versus debate and commentary)).

3.      The global leaders in the WCM/CXM space (see: Sitecore, EpiServer & Adobe) aren’t touching ‘headless’ with a 10-foot pole. EpiServer, for example, actually goes to great lengths to denounce the viability of headless content management.

4.      The concept of ‘headless’ works ONLY when the “body” is extremely strong, well governed and best-of-breed.

I want to focus on my final point there. Opinion only – but it is my belief that headless delivery with a niche player is a ‘fun toy’ that can be used to solve ‘point problems’ in certain circumstances and for certain companies. This opinion might be controversial, but the fact remains that commanding enterprises around the globe are intrigued by the concept of headless but are not standardizing on it.

So, the question remains, when it comes to content, what are they standardizing on? The answer for (literally) hundreds of millions of users around the globe is Office 365 and all its different content managing and storing workloads.

Headless can be powerful, if you have a mechanism to store, secure, evolve, govern and integrate all the content and transactions that you want to deliver to the desired experience, for the desired user, on any device and in any language.

What you are literally doing is “abstracting” the backend from the frontend. The traditional approach to content management was born when there limited channels for content delivery. As such, traditionally these systems have a certain (and in some cases, significant) amount of constraint on how the pages are built. These systems also needed to add overhead to the runtime page delivery for the purposes of supporting the CMS author and the content consumer.

SharePoint, for example, is a PERFECT snapshot of this. By-and-large SharePoint is a page delivery system. In fact, as new features of SharePoint Online hit the market Microsoft is adding more and more weight into that page as they chase down an even easier way to allow for page creation, manipulation and management.

This is a crossroads. SharePoint (and the other workloads in Office 365) are fantastic pieces of technology that target elevating the productivity of every user inside your organization. The Microsoft stack has become the standard for so many enterprises – and that means that an amazing amount of that enterprises content, intelligence, business processes, multimedia etc. are available to a user to create a page experience.

I have all this content and I want to deliver it into a agile, lightweight and targeted front end experience across multiple devices and in multiple branched fashions and languages. The main problem is that the runtime (SharePoint’s page management system) is super heavy and extremely restrictive (and those are probably understatements).

Candidly, doing things the way SharePoint forces you to do them has just become and accepted and unfortunate reality – but part of that problem is that (nearly) no one is thinking about using the best parts of what it (SP/SPO) delivers and removing the worst. Most companies in the “intranet in a box” market that have tackled making SharePoint better have gone to great lengths to try and ‘improve’ it – but taking the thought process of headless to SharePoint isn’t improving it; it’s about re-inventing it.

“Heavy and Restrictive” aren’t simply just descriptors – in this scenario, they are real inhibitors to success and touch on the five key areas that a “headless” delivery system promises to fix.

1.      Performance

2.      Security

3.      Integration

4.      Flexibility

5.      Openness

So, what are you telling me?

Headless content management may or may not take off – and the vendors who purport to specialize in it (none of which are in the above linked WCM Magic Quadrant) might become more household names than they are today; BUT; what if you had a solution to make SharePoint and Office 365 headless?

The promise of that would be leveraging all the great that SharePoint (for example) does on the backend without any of the restriction on the frontend. The promise would allow organizations to create digital experiences for users whom you have purchased Office 365 seats and for those whom you have not.

Akumina (my company) has delivered a framework in its software platform allowing for you deliver a headless experience where the body is made up of all of those Office 365 workloads – and we have tons and tons of customers loving it – literally, thousands.

Let’s look at those five key areas that I touched on above. Abstractly, one could make the argument that SharePoint’s (and the rest of the 365 stack) problem is quite simply an inability to deliver on those 5 key areas.

Leveraging the enterprise headless framework built for Microsoft by Akumina, customers can create the following reality:

Performance: Leveraging a headless delivery on a SharePoint/Office 365 back-ended experience means you have no dependency on the SharePoint runtime, SharePoint page model or SharePoint performance for the DELIVERY of the frontend experience giving the developer complete control over the performance and response capabilities of the actual page rendering. No latency from SharePoint pages, no latency from Office 365 throttling, no restrictions on the object model for delivery.

Security: Security is a critical element of leveraging Office 365 or SharePoint to deliver an external facing web experience – be it a portal, extranet or public facing website. Leveraging a headless delivery on a SharePoint/Office 365 back-ended experience means you can deliver a more secure infrastructure. A developer has the power to “channel” access in a headless environment much tighter than a traditional content management system. Essentially, you only take what you <end>. A developer can define endpoints in a fashion that is far tighter than what is offered or possible with a traditional content management system. Additionally, with properly architected headless access, a developer can cache and deliver content asynchronously; reach back to the data source, grab the data, and then persist it in delivery. This results in the system “reaching back” significantly less often, but with the power to do it enough to create personalized experinces. At the end of the day, leveraging what Akumina delivers is the only approved use of Office 365 to power public facing site experiences available on the planet (insertion of…proud statement). One of Akumina’s biggest and most secure customers leveraging this is the World Trade Center in Manhattan – arguably the United States most decorated, sacred and secure trademarks.

Integration: Leveraging a headless delivery on a SharePoint/Office 365 back-ended experience means significant more flexibility and capability for integrating with other systems – inside the Microsoft stack and not inside the Microsoft stack. The developer can leverage C# development and MVC design patterns to integrate 3rd party systems via server side calls easily without a complicated proxy scenario using Provider Hosted Apps and without the handcuffs, latency and overhead that the SharePoint runtime dictates.

Flexibility: Leveraging a headless delivery on a SharePoint/Office 365 back-ended experience means significantly more flexibility for the developer. With a headless experience the developer can separate out the frontend runtime completely from the backend data store. This flexibility allows you to switch out the backend if you ever needed as there is no tightly coupled dependency between the environments. There is also unlimited flexibility in terms of user experience (UX) and the user interface (UI) that can be created as you are not limited to what can be created or delivered inside of a SharePoint page. Furthermore, a headless system allows for advanced load balancing scenarios and the incorporation of other enterprise server-side technologies available on IIS that you cannot control when rendering inside of SharePoint page (because the developer has no control over what can happen in IIS).

Openness: Leveraging a headless delivery on a SharePoint/Office 365 back-ended experience means not needing a team of developers that are SharePoint developers. Because of SharePoint’s object model and design pattern, a developer must become an expert on understanding how to create experiences the “SharePoint way”. A headless experience means leveraging existing skill sets to create those experiences and allowing unbridled use of any technology, style or application of code that the developer desires. This also allows for the isolation of expertise – letting designers create whatever design they want, letting developers create the functionality they want and allowing the site admins to administer the governance they want with no need for expertise of reliance on SharePoint at all. This also means that the deployment of code and assets into the site is greatly simplified for the developer because they can use typical developer tooling – with no need to know to deploy assets into SharePoint.

Like anything else, the appropriate application and decision to go headless should be specific to and in-line with the requirements of what the business (customer) is trying to solve – but one of the areas where we see it extremely powerful is when an organization wants to use Office 365 / SharePoint as the backend for a portal, public facing site or extranet that is targeted to users that may not be inside of Azure AD – and who at the same time have no desire to go out and purchase an entirely separate content management platform.

Allowing an enterprise to store all their data in Office 365 (inside each of its workloads) is extremely powerful and very efficient. One overarching system of record. One set of rights, rules and permissions, one data model, and one connected API (see: Microsoft Graph) to be able to traverse across the workloads to get to different data pieces.

Let me give you an example. One of our customers is a major professional sports team in the United States – one of the oldest and most storied franchises in the country. They have delivered a SharePoint “headed” experience on the Akumina platform for their global corporate intranet. They have thousands of users operating around the globe and needed a platform that could deliver a next-gen digital workplace solution for them targeted at increasing productivity of the organization. For this experience, the headed SharePoint experience works great. They leverage the Akumina presentation framework on top of the SharePoint runtime experience and have created a personalized, targeted and adaptive experience for their users. Additionally, they have all of their content (almost all of their content) in Office 365 across about 12 workloads (e.g. Exchange, SharePoint, Stream, Yammer etc.).

But what happens if they want to use all that same content (or create new content without a new backend system) and they want to start targeting external audiences – Think: season ticket holders or vendors they work with or partners they do business with. If we roll with the season ticket holder example – you are actually talking about a larger audience of season ticket holders than you have in full-time employees. It’s a big number. How do you create an experience for them that will 1) perform, 2) be visually appealing and engaging, 3) that will enable transactions on tickets and events connected to third party systems and 4) that is easy to create without re-inventing the entire tech stack – after all – they already own Office 365.

This is just one use case, but the answer is simple: dial up a headless experience. And with Akumina’s content management and page management capabilities – content creators and authors have a single place to go to create content with the power to deliver that content to either experience with the simple click of a button.

Is this content item relevant for our employees? Deliver it to the intranet.

is this content item relevant for our season ticket holders? Deliver it to the portal.

Is this content item relevant for both? Deliver it to both experiences with one click.

The reality is that a headless CMS concept opens the doors for a new kind of page management and delivery layer. Akumina believes that a headless system is only the first step to a site or other application that lends maximum flexibility to those who are creating those compelling experiences (Queue Duckboats for the developers and designers!). The next step is a completely agnostic page building and management system. Such a system would have no dependency or restriction (or even understanding) of the underlying core system that is supporting it and/or providing it with its content and data. Such a system would allow for the creation of web based experiences, native mobile app experiences, digital display experiences and more – with absolutely no dictation from the underlying system of what is can or should be able to do.

This approach (revolutionary at best; superior alternative at worst) and thought process will allow developers to create true digital workplace and digital engagement experiences that will scale exponentially as more needs emerge from a customer, while putting the power in the hands of the “creators” to focus 100% on the experience they are creating and the audience they are creating it for with not a minute of having to worry about accommodating the backend system and all the baggage that it brings.

To learn more about Akumina, or to see how we have become the experts on delivering both “Headed” and “Headless” digital experiences on top of Office 365, send me a note or check out our website.

David Maffei is the CRO and a Board Member at Akumina. You can reach him at dm@akumina.com and https://www.linkedin.com/in/davidmaffei/