Is the SharePoint 2013 App Model Ready for the Enterprise?
Since the introduction of the app model for SharePoint 2013 and SharePoint Online (Office 365) development was announced last year, much has been written on the topic of full-trust solutions versus apps (see Andrew Connell’s post and this one from Richard DiZerega). While the larger debate of how new applications should be written for SharePoint going forward is valid and worthy of much more attention that it has been given from non-marketing sources, one of the facets of the discussion that hasn’t received much attention is the basic validity of the app model in the enterprise. If an organization is currently considering SharePoint 2013, either online or on-premise, it is important to understand the current capabilities of the model Microsoft is promoting as the future development direction for SharePoint solutions and its present limitations before deciding upon which approach to adopt.
The app marketplace concept is one that has proven to be popular and effective for consumer-focused applications. Small, lightweight applications that sell for a nominal fee to thousands of individual consumers are a great fit for a delivery model designed to accommodate mobile devices. Trouble is, enterprise applications are an entirely different breed – they are rarely small or lightweight, are priced in the thousands of dollars, are typically provided on a site-wide or per-seat license basis, are purchased through a structured acquisition process, and often have a significant learning curve. In other words, they just don’t "fit" into a "store".
Take the licensing issue as a prime example. Currently, in order to purchase an app, the customer must authorize it not only on a site-collection by site-collection basis but on a user by user basis as well. There is no ability to assign licenses to any kind of group or set of unnamed users – they have to be assigned to individual named users in each site collection. Think of an enterprise with dozens of web applications, hundreds of site collections and tens of thousands of users – there is no way that the current licensing model will ever be accepted in this scenario. Site admins are simply not going to go through the pain and suffering to make this happen even with automation tools like PowerShell to help out. What happens when a user leaves the company? How does the license get reassigned? And what about archived site collections – how do all those licenses get moved? It’s an administrative nightmare and not one that enterprise customers are willing to accept, especially when all the other enterprise application vendors (including Microsoft themselves) are more than happy to provide a license key and volume licenses for "real" software products.
Then there is the payment issue. Assuming the licensing hurdle is overcome (which has about as much chance of happening as the Dallas Cowboys ever making it back to the Super Bowl), how does a vendor listing a product that sells for, say, $150 per user, deliver it via the marketplace? How does a customer with ten thousand users buy that? Just slap down their credit card? Hardly. Worse, what if it’s $150 per user per month? There’s no model for recurring transactions much less those that sell for umpteen thousands of dollars. That kind of spend requires a purchase order – but who does that go to? Microsoft? The vendor? How are the taxes paid across state or – dare I even say it – international borders? Vendors can’t even see who their customer is in the woefully inadequate seller dashboard – how do legal and tax departments deal with a complete lack of customer info? Does Microsoft want to become the go between in that scenario? Not very likely.
It is also common for enterprise apps to have a lot of dependencies and integration points with other applications. The current deployment model provides only for authorization related to permissions. What about configuration parameters for an app that needs to connect to various resources both inside and outside of SharePoint? Most vendors deal with those issues by providing an installer or setup application but the app model doesn’t provide any such capabilities. SharePoint has the capability to store configuration data on a farm, web application, site collection or site basis but apps don’t have access to any of those repositories. They don’t even allow for provisioning of dynamically named artifacts at runtime – the developer must force the user to accept their object names for things like lists and libraries or calls the app makes into the SharePoint site will fail. That’s ridiculous – especially in multi-lingual scenarios.
In the cloud, deploying apps is a relatively easy process, as it should be – after all, that is the scenario apps were designed for in the first place. Select an app, authorize it, and off you go. But on-premise app deployment is an entirely different matter. By adopting OAuth as the mechanism for app authorization (made even worse by the absolutely horrible 2.0 implementation of the protocol), Microsoft made it entirely too difficult for apps to be deployed inside the corporate firewall. The need to establish server to server trusts (also known as "High Trust Apps" – see my deployment walkthrough here and related posts here and here) and bind them to individual web applications causes too much friction. Getting an app to run in production is a multi-step process involving SSL, certificates, metadata endpoints, token issuers, identities, realms, and a host of other variables. Why would any developer go through that much trouble when they can simply write a full-trust solution and get access to everything the server object model has to offer?
This leads directly into another major area of concern – the limitations of the client object model. It’s all well and good to hype up the app model as the way forward but until it has feature parity with the server object model all that marketing hype is just that – hype. Pretty comparison charts showcasing all the things the client OM can do aren’t very helpful when they only focus on the Foundation-level workloads. The truth is that even within this very narrow set of features the client OM only provides access to a portion of the currently available server methods. And it gets worse – what about enterprise content management (ECM)? Publishing and web content management (WCM)? Business intelligence (BI)? Workflow? Taxonomy and metadata? You know – all those killer Enterprise features that make SharePoint the biggest, baddest collaboration platform on the planet? The client OM has very limited capabilities in these areas and getting there will take years of development just to reproduce what we already have in the server OM – talk about running in place and not moving the ball forward. Until an app can do what even the simplest web part or application page can do it’s not really an app – it’s just an add-on.
Furthermore, the isolation model for apps is confusing, fractured and ill-suited to its task. The concept of app webs as a pseudo site collection that inherits permissions from the host web and attempts to hide or obfuscate basic SharePoint functionality is laughable at best. Users deploy apps to SharePoint sites – they expect those apps to work in the context of that site. Trying to explain to them that, no, in fact the app doesn’t really live on that site but some other site they can’t navigate to is an exercise in amateur improvisational comedy. Nobody wants to hear such nonsense – if an app deploys a list or page they want that artifact to be on the site where they clicked on the tile in the first place not some weird location that doesn’t even have basic navigational elements. And the gyrations that developers have to go through in order to deploy artifacts where users expect and need them to be completely undermines the whole concept of the app model making SharePoint development easier. Those unfamiliar with the SharePoint platform will either give up in frustration or lose so much productivity trying to figure it out that they’ll end up regretting ever haven been thrown into the SharePoint mess.
And that, unfortunately, is exactly where we are today. The app model in its present incarnation doesn’t make customizing, extending or enhancing the platform any easier on customers, developers or vendors. It just adds more confusion, with a heap of half-baked features and ill-designed integration points. That’s not to say the model is wrong or misguided but rather that the implementation falls well short of what is needed to gain widespread adoption in the same way the on-premise development model has. At least in the full-trust solution scenario we now have enough experience to provide best practices and proven strategies for limiting the negative impact of a nearly complete customization framework – apps, much like sandbox solutions before them, are being promoted as a viable alternative but currently have too many restrictions and limitations to come anywhere close.
It is tempting to brush aside these concerns with misdirected arguments that are all about Office 365/SharePoint online and the whole cloud initiative. The discussion here is about adoption of the model in the enterprise and the truth is that SharePoint always has been, and will continue to be, an enterprise application. While small businesses can certainly benefit from the deep and rich feature set that SharePoint brings to the table it is the enterprise customers who have made it into a standalone multi-billion dollar business. And much of the sticking power of the platform has come from the efforts of third-party vendors whose products enhance and extend the platform. In order for the app model to gain any traction it must facilitate the ISV ecosystem or enterprise customers will ignore it at best and abandon it altogether at worst.
Expanding the context of the argument into the area of overall strategy, a cloud-based solution to the collaboration problems of small to medium sized businesses is an important market initiative and Microsoft is quite right to try and exploit a market they have all but ignored for the past few years. But doing so at the expense of enterprise customers, whose spending far outweighs that of smaller customers, is a recipe for disaster. The powers that be should remember that low-cost solutions which are easy to buy are also easy to abandon – all it takes is one major outage or security breach for flocks of customers to switch to another vendor. That’s difficult if not impossible to do with large enterprise customers – they will invest in a platform for the long term and stick by a vendor until it becomes infeasible to do so. If some portion of those customers are willing to accept a limited-feature version of the application that runs in the cloud then that’s fine but the vendor had better find a way to keep them happy – otherwise the cloud gives them an easy out that they never had before if they become dissatisfied.
A tightly integrated enterprise app story would be a great way to achieve large customer loyalty. Even if they could switch to someone else for core collaboration features the amount of effort invested in app customizations would keep them from jumping ship the first time the winds blow in an unfavorable direction. And if the model can truly be made portable between the cloud and on-premise implementations it would be a real game-changer, allowing enterprise customers to choose which deployment model they want without having to worry about extensibility limitations. At some point the powers that be are going to have to wake up and realize that many large customers are never going to go all in on the public cloud – they may let cloud vendors have bits and pieces of certain non-essential functions but the risk is far too great to allow valuable company data outside of a controlled computing environment. And a hosted solution like Office 365 dedicated isn’t going to suit their needs either so long as the vendor continues to impose unrealistic restrictions.
[As an aside, it is amusing how many times the IT industry has gone through this same cycle of central versus distributed resource ownership, each time acting as if the latest swing in one direction or the other is the way everything will be done in the future. A note of caution to those who can’t remember that far back – mainframes were the "cloud" to terminal "clients" way back in the 60’s and 70’s. Nothing has changed much – racks of 1U servers look an awful lot like those big IBM boxes of yesteryear, with thousands of "clients" all connecting over a "web" of discreet endpoints. Everything old is new again – indeed.]
The SharePoint app model could have promise within the enterprise but only with significant changes. The capability, deployment, delivery and licensing issues all have to be resolved before customers with real money to spend will come to the table. I believe it can be done but only by focusing on the core framework and not running in circles around the edges looking for the next shiny object to get the fickle consumer’s attention. Take a step back, build it right, and SharePoint can continue to occupy center stage in the collaboration space, regardless of whether it’s on premise, online, or both. Failure to do so by simply extending the status quo with incremental improvements will likely lead to disaster. There’s too much money at stake – it won’t take long before another vendor steps in to do what the current vendor is unwilling or unable to do. And then we’ll all be talking about the old days when that SharePoint thing was cool…way back when.
UPDATE: For clarification, this post is not intended as a slam on the app model, SharePoint 2013, Office 365 or the cloud in general. I’ve been shouting from the rooftops about the app model for over a year and have helped many organizations create a roadmap for development on it. There is no question that this represents a new direction for Microsoft in general and SharePoint in particular and that there are a lot of opportunities for improvement. What I have noticed is that most of the conversation in the community around the model in general has been from a consumer or seller point of view and driven primarily by marketing. My intention is to bring the discussion around the the bread and butter of the SharePoint market – enterprise customers. Adoption of the model by this customer segment is crucial and attention must be given to their needs as opposed to the small business customer or casual consumer. I am hoping that by taking a stand on behalf of a specific customer segment that more attention will be given to this not only in the greater SharePoint community but within Microsoft itself.
SmartTrack Operational Intelligence for SharePoint
This is a great post with a lot of good points. One thing though, this statement: “And it gets worse – what about enterprise content management (ECM)? Publishing and web content management (WCM)? Business intelligence (BI)? Workflow? Taxonomy and metadata? You know – all those killer Enterprise features that make SharePoint the biggest, baddest collaboration platform on the planet? The client OM can’t touch any of those yet” is not true. There are CSOM assemblies for publishing, document management, taxonomy, user profiles and workflow.
They don’t have parity with the server OM, but they do exist.
The other comment I’d like to make is that there really is no such thing as the app model, but rather a large number of independent pieces and architectural options. This makes them hard to discuss and even harder to build. As you probably know I’ve been pretty vocal in my overall support for the idea of apps, but I quit writing about them because discussing them in the abstract just doesn’t work because the whole thing is squishy.
Hopefully I’ll be done with the business side of things in the next couple weeks and I’ll launch a couple of sophisticated apps I can use as concrete examples to back up my opinion, but until then let me say that the challenges you outlined in this post are very real, but not insurmountable.
Excellent post, Eric. I’ve seen lots of rants; this is a well thought out article.
My data points are admittedly few, but the other thing happening here is that few organizations understand the app model or its benefits, so they are simply doing what they know. Why change if what they already know simply works? And that doesn’t mean sandbox solutions, either. Anyone who started with SharePoint 2007 is blithely churning out “full trust” solutions still.
Changing the “right” way to do things every version and swearing that it solves everything has eroded credibility down to the bedrock for many people. As you point out, there are other options out there, and they may start to seem far more appealing.
Lastly, the concept of portability is one that will be exceedingly important vs a vis on premises and cloud deployments. No large enterprise will want to deploy some workloads to the cloud if they have little possibility of pulling it back in later if they so choose. An example would be a simple extranet to start working with a vendor. Depending on the cost structure and the vendor relationship, it might make perfectly good sense to start with Office365 then move into an on promises installation over time. That will be exceedingly difficult with the development and app options available to us at this point
Very well written article Eric, have distributed to team for reference.
Oh no…here comes the Microsoft propaganda :).
Kidding aside, I think this is a fantastically well-thought posting that points out all the right things an organization should think about when considering a development approach in SharePoint. I know first hand, that you have pushed the app model as far as anyone out there (I even had developer envy when I saw some of the creative things you pulled off with SharePoint’s REST API).
One thing I won’t argue is that the app model is definitely a v1 platform with significant limitations/constraints. I’ve shared many of your same frustrations around API limitations and app isolations (app webs…really?!?). However, I know for a fact that Redmond is a) committed to the app model and b) looking to update it in a more frequent cadence than the past. Here are a few thoughts based on the issues you outlined:
– I’m not seeing the Store being the primary place for “enterprise apps”. That statement might get me in trouble, but I still see most enterprise apps being developed/deployed in-house (or by SIs) similar to how farm solutions are today
– licensing has sucked…especially for cloud-hosted apps, but I know subscription-based (read: recurring) licensing is coming very soon. This doesn’t solve all the issues, but an example of the model evolving quickly. A “pushed” deployment through the app catalog is another way of simplifying licensing, as it generates one app web and remote web.
– BIG changes are coming to the tooling so that high-trust apps are easier to develop and dealing with TokenHelper might be a thing of the past. Some of these changes can be test driven today in the VS2013 preview
– The Office 365 impact is bigger than almost anyone realizes. I don’t know many customers that don’t own some flavor of SPO by now. This includes many organizations that say “we’ll never move SharePoint to the cloud”. That doesn’t mean they have deployed it or even have it on the radar of the SharePoint team. I predict SPO deployment will increase significantly in the next 12 months to catch up with sales. I don’t expect many of these deployments to be “big bang” moves to the cloud, but moving a workload or two at a time (ex: MySites/SkyDrive, or maybe team sites). For these SharePoint Online customers…the app model is their only hope.
Doug – regarding the Client OM surface area, what I was trying to say was that it can’t touch enterprise workloads in any meaningful way – perhaps I should modify it to say “…the Client OM has very limited coverage in these areas”. And I agree that the challenges are not insurmountable but we have to keep asking – loudly – for the right kind of changes or they won’t get any attention.
Rich – Thanks 🙂 I’m already having lots of conversations with companies who have tried O365 and are pulling back to the on-prem model for a number of reasons – and a big issue is the limitations of the app model. I’d like us to have a really great story around app portability and integration so that question becomes moot. There are plenty of reasons to pick one deployment model over another – it would be great to remove app dev from that conversation altogether. I know it can be done but these typically aren’t the kinds of things where engineering time gets spent unless we keep the conversation front and center.
As with what others have said, a well-considered and written article. Great reading and highlights some of the things I’d also flagged up (though your list is much bigger!).
Another issue I come across more early on in the discussion, is explaining to senior stakeholders the app model in SharePoint is not as easy to take on as their well-known ‘fruit’ branded phone they have got. It’s simply not ready for the enterprise in my view, so this post resonates completely. As Richard says, it’s very much v1, so it won’t get much traction in my view until the issues noted in the article are addressed. Anyone have access to any sales data from their app based products, worthy of a mention?!
PS. Doug W…”…the whole thing is squishy”…hope you don’t mind me quoting that phrase in future! Superb!
PPS Richard D, just one point, “I don’t know many customers that don’t own some flavor of SPO by now”. With respect, I am guessing you work for Microsoft, so therefore by definition you only work with very large customers (lucky boy!) as this in their target customer profile. They are more inclined to have investments in a range of options, and the budgets to support it. Most others, and from my SI based experience would put that in the high 85%-95% (or higher), certainly from a UK/Europe perspective do not have any investment in SPO. It’s very much a slow burn this side of the pond in my experience, granted this is gaining traction and speeding up I’d suggest.
Great write up Eric! Well thought out and to the point. I had my own thoughts which you linked to (thanks BTW). The only comment I have is that while this is v1 of the app model, this feels much more like a prototype as it only works for a limited set of use cases and scenarios. It does not live up to it’s marketing in most enterprise cases.
To address one thing @RichardD said: agreed… with the new frequent release cadence with Office 365, Microsoft has the ability to revise, refine and improve the current offering. However we’re looking at a product that has now been in general availability (GA) since February, for over a half-year, and we’ve yet to see any such improvements. Redmond is frequently doing updates to O365, but mostly bug fixes… not fixing things that have been well known about or following up on promises (such as “we’ll give you more info on how to do auto-hosted apps on prem”… a statement from July 2012). Frankly, I’ve given up on waiting and Microsoft has provided zero reason to believe these statements or promises. I’d love to change this frame of mind, but for now we, or at least I, have passed the point of offering the benefit of the doubt. The time is passed to “put up”. I’d include “shut up” but their have been silent with the exception of a social roadmap.
@AndrewW – I’ll disagree with you on customer size…although I tend to work with larger customers, the service has a bigger sweet-spot with small and mid-sized businesses that can’t afford traditional data centers or full-time support staff. The BIG customers have been a harder to transition, but it is definitely happening (again…maybe just a workload or two).
I completely agree with you on the UK/Europe perspective. Microsoft has some ground to makeup there and embarrassing NSA leaks don’t help with EU confidence. I’ll admit I sometimes take a US-centric view of things since that is my world…typical American 🙁
@AndrewC – You’re right…I’m still waiting for the quarterly love that was promised to me. Even bigger than bug fix has been the effort to migrate existing SPO customers to 15 farms in the service. I HOPE big migrations like that are a thing of the past and we can get back to the quarterly feature updates. We have announced BIG new features like Power BI and major WAC updates (not technically SPO) with more on the way. Nothing has hit the developer community or apps yet, but I assure you that some love will be shown there very soon. Organizations and MVPs can sign-up to test drive SPO vNext today: https://prereleaseprograms-public.sharepoint.com/
Congrats on the post! I can’t agree more.
Nice post and well put together! Loads of great points!
I think it’s worth pointing out where the new app model came from and what it was designed for.
It wasn’t designed to cater for the big enterprise solutions or current slew of on-prem ISV products. It just wasn’t. It was done to allow/promote apps for small and mid-market folks that can use Office 365. I fought this thinking as much as I could while at MS and grew frustrated at the lack of care for the existing SharePoint ISVs as the move to the cloud became a priority. Beers would be needed to talk about all that!
Having said that, nothing happens in one version 🙂 Especially at MS! I do think the direction of moving code out of SharePoint is the right one long term and I hope we see the model develop more over time to allow for things that people do with full trust solutions today, tomorrow. It will take time, and i know people at MS are thinking/working on these issues.
One could argue that MS is going about this in the absolute right way. 365 is only really fully used by small/mid-market customers is a broad way today. The app model caters to them today. When Enterprise customers are ready for the cloud in general (not specific to 365, i mean the cloud at all!) who knows, SharePoint Online may just have the app model features we need in order to customize, build on and deliver the kinds of things we do today on-prem. Time will tell i guess.
In short my point is this. Take the app model for what it is and what it is supposed to address. Don’t try and stick a square peg in a round hole, but keep an open mind and design today with the future in mind.