What would be reasons to develop SharePoint Apps?

A really good debate sprouted up in Facebook recently, stated by SharePoint guru, pin-up and conference legend Christina Wheeler when she asked the interesting question:

“For customers that are on-premises only what would be reasons to develop SharePoint Apps versus farm solutions?”

Talk about crowd storming! This turned into a fascinating but short brain dump of some world leading SharePoint experts. Just too good a piece of collective guidance to ignore!

Before we get into the responses, what exactly is an App? The official line reads something like “Apps for SharePoint are easy-to-use, lightweight web applications that integrate popular web standards and technologies to extend the capabilities of a SharePoint website.”

Hmm, the campaign for plain English would be enamored with that lovely phrasing but if you work in SharePoint world, you should really be able to understand that. For those who like things simply (like me) let’s rephrase that a little in that Apps in SharePoint 2013 are building blocks of functionality, usually self-contained that anyone can install if they have the right permissions. They do not contain custom managed code that runs on SharePoint servers like traditional sand boxed or farm solutions. Farm solutions are packages of SharePoint components that are uploaded to an On-Premises or Azure (or similar) hosted farm-wide gallery from where they can be installed. They cannot be distributed through the Office Store, and they cannot be installed on SharePoint Online, or O365D.

It takes skill to build an App from scratch, in fact for most SharePoint developers it’s a learning paradigm shift they have yet to embrace and it is not an easy skill to learn. If you are wondering just how difficult and need some very sensible guidance read Mark Rackleys blog post “So you still want to be a SharePoint developer”.

http://www.markrackley.net/2014/03/12/so-you-still-want-to-be-a-sharepoint-developer/

A scarily telling post on how to go about shifting your mind-set to the App paradigm, but remarkably accurate.

The benefits of apps are fairly well documented and most people when asked kind of repeat almost parrot fashion along these lines:

  • Using any language ( like HTML, JavaScript, PHP, or .NET)
  • Distribute the app’s logic, so data and user interface. Presentation logic in HTML5, with client API libraries talking to business logic in .NET that runs in Windows Azure, consuming data stored in some backend service.
  • An ability to consume other web services so can talk to other none SharePoint services.
  • Wide authentication support

All well and good, but still very focused on the development paradigm, when a good App strategy should reach across the whole Enterprise Architecture concerns around Governance,, Boundary Scanning, Goal Alignment and Innovation. The benefits and considerations are really much wider than just the development sphere of influence as the debate showed.

To elaborate on how wide that level of thinking needs to be, you only need to look into the following diagram.

 app_tiers

http://msdn.microsoft.com/en-US/library/fp179930.aspx

The question about which hosting option (and you could choose all of them depending on your platform architecture and technology strategy) in itself is far from a development question, but that strategy choice hugely impacts the options available. You need to know about these things to make good strategy choices to steer Solutions Architects, who will then steer the Developers.

Incidentally, there is a really clear article on that very thing here:

http://msdn.microsoft.com/en-us/library/office/fp179887%28v=office.15%29.aspx

Even simple things like how many app catalogues do you permit on your service and do you allow apps from third party App store providers have to be considered. How would these things be supported, what is the SLA for a provider hosted service, how do these choices impact our emerging (and rather critical these days) BYOD strategy, what happens when we upgrade SharePoint, How does this paradigm shift impact our Hybrid SharePoint strategy? The list gets fairly endless and really quite scary even for experienced Enterprise Architects as you need to know a ton about SharePoint to even contemplate these things, and most EA’s just don’t!

I’m currently working within a huge Hybrid SharePoint 2013 global architecture and I can tell you the App strategy is and is rightly so, a long way from completion.

So, a very difficult space to navigate! What did the pool of experts say?

“Decoupling, limited amount of future proofing, leverage “new” development tools and approaches, engage/keep decent developers”

“Getting custom solutions off sharepoint is the single best benefit from an OSM perspective”

Why do we constantly introduce an upgrade challenge (answers on a postcard please, winner to be drawn at the release of SP 2015)

“To be cloud ready?”

However, we all have customer which have stated they cannot and will not move to the cloud.

“Heck, they are still running XP and are just barely upgrading to Windows 7.”

“Moving to the cloud is largely irrelevant frankly – all the benefits of a decoupled app model are still relevant/pertinent to an on premises deployment. But so are the drawbacks, some FTC may be needed, but anytime you can decouple you should. Customisations remain the #1 reason why deployments fail or have operational problems.”

“App’s get IDs, getting into the marketplace”

“Easier upgrades, easier to replace customisations in the future, easier to update custom solutions, avoid unsupported “issues”

“The biggest challenge to SP Apps is the deeply broken authZ model, which for a banking customer could be a deal breaker”

“There have been misconceptions on customers thinking that Apps are just for O365 which brings up them questioning “Why would I want to build Apps on-premises?”

First Q should be “why am I customizing at all?” 2nd Q “if I need customization, why am I using SP at all?” 3rd Q “is oAuth2 acceptable for my business data?”

“You can still build off box solutions for SP without using the “App model” but it sounds to me as if they need to sort out their strategy and think about SP being the right platform for what they are doing”

A stack of EA thinking, and a scary security model with it – strategy is key!

“Developers are currently stuck in the MOSS 2007 frame of mind. I’m helping them understand SharePoint 2013 and help change their way of thinking.”

“If you are running SharePoint as a Service for a large organization and you want to allow various groups/departments to customize then it makes sense to develop apps v/s FTC”

“I’ve been showing them how to take most of the crap they customized in their 2007 environment that they can do through OOTB web parts in 2013. Changing their frame of mind.”

Just proving how much SP has evolved, perhaps go and look at composites with a new light!

“Additional reasons would be the ability to use development skills they already own for asp.net/mvc. Easier to deploy/upgrade/remove. Fast development as F5 does not need to recycle your SharePoint environment. Moving them off the mindset of using solutions packaged in .wsp files will take a while though. The concept itself is easy to grasp, but once you get your hands a bit dirty and need to think: How will I actually build this using apps is when you need to look at the challenge and its solution a lot differently.”

“The benefits are that it’s going to be the way to dev stuff, so best to embrace the future rather than fight it. I am also a HUGE fan of getting custom code off of SharePoint after having been involved in a large scale upgrade project in the past (circa 100,000 users). Customisations were the single biggest time and cost factors in that project, cloud or not. However, Apps are not always the right way to go just yet and I am hoping that will become a better story over the coming months with the work Chris Johnson and Jeremy Thake’s team will be doing.”

Watch that space with interest!

“There are still a lot of projects where I start trying to solve them with an app and hit a hurdle that makes it impossible or impracticle. So the story isn’t simply “build and app”, it’s still pick the right tool for the job.”
Always!

“I still have issues about locking content out in apps and no having that part of the global information repository / search, etc and waiting to see how that content gets brought back in.”

For most apps, you can surface DB encapsulated content using database connections, from tooling like Excel even – but it’s a lot of extra work.

“For me, apps are the future. But still 50-50 on whether they are the right tool for the job.”

“Start with planning an app and then find reasons not to use an app, rather than the other way around.”

Solid and sensible guidance! Something I told to my developers about using Visual Studio recently, you have told me the positives, now identify all the negatives?

“Having had a very similar discussion earlier and knowing banking environments, I would put it squarely on future-proofing their development efforts and scalability. As they grow and need more horsepower the app model does have some advantages towards being able to bill certain services/hardware back to the department for specific. Even if they never go to a “public” cloud or data center, the scalability of a private cloud is huge. Plus, when it gets down to capitalizing development dollars, it’s a lot easier to prove tax wise if you’re using the latest tech rather than “maintenance” of an existing system. My mantra is usually: customize OOTB, apps, custom .net w/ WS into sharepoint data and then sharepoint solution. Sharepoint designer is probably sprinkled in there somewhere, but I’m not really liking the spd 2013 experience. I try to keep sharepoint focus on collaboration and workflow, but someone inevitably tries to use it for transactional processing”

“I’m moving away from custom dev as much as possible with only small web parts and doing as much client side code as possible for them for our on-premise. Upgrades (been through 2003->2007->2010) kill us on the customizations and frankly, every since version we have a deprecated development model. Basically my plan is to move off as much custom dev from SharePoint to ASP.NET and anywhere we have stuff left over minimize the surface impact by moving things to client side code”

Ooh, ooh – remember that link to read Mark Rackleys Blog!

“Moving to Office365 is much easier if an org follows the current app model and general server performance could be another benefit.”

“In the real world this “decoupling” function costs money in the form of more servers to patch and maintain. Benefits are vs. a WELL-written SharePoint customization. Believing any marketing goo you come across is a recipe for disaster “

It all sounds great, until you look at how complex the App world has become!

“Even a well written customizations today can run into problems with deprecated features in the future and in addition present challenges for upgrade and maintaining performance on a shared platform. Now I appreciate the app model can have similar challenges but by decoupling the customization from the platform you at least get a degree of separation that can make management and updates easier. As for more patching, well that’s debatable since it depends where you host the app to some degree.”

“I think that is always a better way to go, it just depends on the scenario, as there can many variables to consider, depending on the environment. I do think CAM will grow and mature as time goes on as well so hopefully the gaps will close as a result which should make the two technologies no longer quite as opposing”

CAM (Cloud App Model) – applications are expected to live somewhere else (on another server, in Windows Azure, anywhere)

“Much better upgrade story both v2v and b2b. No pesky features and solutions that may or may not break during upgrade. I don’t miss those “
“Sure decoupling comes with a cost, but it’s widely understood that the benefits of decoupling outweigh the drawbacks in the majority of cases.”
Do your research, it is certainly correct but has to fit with your organizations technology roadmap and strategic direction.

“I think a lot of devs would rather be building with the latest and greatest .net tools, frameworks and techniques. In the app model you can abstract away the SPisms in code to provide classes/services that provide the data/events to someone who knows the CSOM etc… Then, the rest of the team are focused on building a kick ass bit of software the solves the business problem at hand using all the tools/frameworks/techniques. This == productive devs == happy devs == world peace”

World peace – that made me smirk!

“Apps are not a silver bullet and we (MS) get that on-prem will need FTC for certain things, but with time that gap should get smaller and smaller. “

“I love the fact that as an app developer I no longer have to ask when SP will support .Net 4.5 ”

Smirk – provider hosted apps, use whatever you want!

“I agree with most that was said to a degree, but basically proper app is as good as proper FTC, sh*tty code ruins any solution despite the approach, if you think that app model is somehow safer you’re wrong, fencing in bad developers is not a solution, making sure they’re doing it right is the proper solution”

Solid advice, definitely a mantra to live by!

“Only 2 reasons come to mind. 1. Make use of non MS developers to write SP apps. 2. Make apps that can more easily migrate to a non SP platform. My personal slant is I don’t touch V1 stuff from Microsoft, especially in SharePoint. Wait for V2 at least to let someone else go through the V1 pain, and to see if MS will actually support the model over the long term.”

“Just remember v2=SPS2003 . I supported it so I can just as easily laugh at it… And the ISAPI filter, too.”

We all did that – go on own up!

This next one was me piping in!

“Apps can stop SharePoint becoming a developer led initiative and FTC being the answer. Far too many early conversations around requirements and goals for SharePoint involve developers, and you get a bit tired with every solution looking like it needs Visual Studio to fix and FTC, even though it still might do unless you can squeeze the goal. Apps at least allow us to challenge that, and it allows more balanced decisions to be made. Less on-platform complexity so easier upgrades, off-loading demand so more streamlined architecture planning, decoupling and isolating point functionality so better cost planning, retraining opportunities to better staff opportunities, and new approaches to dealing with demand so different though processes around business architecture. I think the SP community has along way to go to embrace this mind shift, but Microsoft have a long way to go to make it work for them.”

Clearly wise words!

“It reduces risk. A lot. The SharePoint farm stays unmodified on any fundamental level so it’s easier to support. Since apps don’t compete for resources with SP itself, you needn’t buy as many WFE servers. App servers hosting the self-hosted apps can be much more modest than the hardware needed to run SP itself.”

Risk isn’t often something developers give two hoots about, but as an EA you live and die by it.

“Making sure developers “do it right” is the right approach, but organizations are more organic and chaotic than that.”
“The only things that still make sense as trusted code — if you’re willing to live with the risks — are apps that deliberately hack SharePoint’s behavior. For example, a couple of ISVs have “field-level security” add-ons that hack the UI and interrupt saves with event receivers. If you *must* have that, you’ll need to use trusted code. Some governance and management solutions must still do this as well, at least until more is put in the client-side object model.”

“There are many things that still can only be done as FTC which are essential extensibility points in ECM scenarios and indeed fundamental elements such as sign in pages. then there are administration components which have to be FTC there are also cases where for throughput FTC is the only practical option. none of these things are “hacks”. It’s not as cut and dry as you make out. there are far worse “hacks” in the actual product than in many point solution deployments of FTC. Whilst staying out of the guts is a good endeavour one should not gloss over the implementation problems of the product itself, which is perhaps the best argument against FTC of all!”

Wow, what a mind dump. It does though show you that there is a lot more to consider about the App paradigm shift than just the scope of development which in itself brings a raft of challenges.

Microsoft would advise us to develop an app for SharePoint instead of a farm solution or even a no code Sandboxed Solution whenever you can. It is good advice for a starting point as Apps have the following advantages over classic solutions:

  • They provide users and administrators with the easiest discovery, purchase, and installation process. However, the setup and thinking up front is vast.
  • Give administrators the safest SharePoint extensions. Customisations are pretty bad things and the cause of many a failing SharePoint platform.
  • Provide you with the simplest marketing and sales system based on a Microsoft online app store. There is a thriving market, this is the way forward and it is set to continue growing.
  • Maximize your flexibility in developing future upgrades. As Apps are pretty much self-contained, they are likely to be much less impacted by patching and future releases.
  • Maximize your ability to take advantage of your existing non-SharePoint programming skills. App logic can be written in any server language, as long as you understand what that means for longer term strategy.
  • Integrate cloud-based resources in smoother and more flexible ways. You can utilize cloud services to host app logic and tap into other web service based resources.
  • Enable your extension to have permissions that are distinct from the permissions of the user who is running the app. The App can operate with elevated permissions on the server hosting the business logic.
  • Enable you to use cross-platform standards, including HTML, REST, OData, JavaScript, and OAuth. The client side libraries are becoming more functional all the time and the SharePoint cross-domain JavaScript library and OAuth means better security options although you must really understand this.

Microsoft realize there is work to do, but we are it seems going in the right direction. Clearly there is a still a lot to think about!

Contributors:

Christina Wheeler, Spencer Harbar, Anthony Pounder, Andrew Connell, Ram Gopinathan, Koen Vosters, Mark Stokes, Timothy Charles, Bil Simser, Ken Price, Neil Hodgkinson, James Blackwell, Anders Rask, Chris Johnson, Zlatan Dzinic, Eugene Rosenfeld, John Timney, Mike Fitzmaurice