SharePoint 2013 and its online counterpart, Office 365, will open up new dimensions for customizing SharePoint farms with the implementation of the new app model.

SharePoint has always been business software, for business users.  The best SharePoint implementations succeeded by focusing on business outcomes.  SharePoint has excelled when it allows information workers without PhD’s in technology to build collaborative web sites or code-free solutions using SharePoint Designer workflows or third party components like Quest Web Parts.  But their choices have always been limited to what IT “puts on the menu”.

That’s all shifting, and users will now have the option of ordering “off the menu” – selecting and installing customizations without requiring the direct involvement of IT.  Potentially.

That’s a lot to swallow.  If you’re familiar with the basic idea, you can probably skip a few paragraphs ahead.  But for some readers, a quick recap is in order.

App Hosting and Storefronts

SharePoint 2013 supports a new API model where application code is no longer directly installed on the server.  Instead, applications can be hosted elsewhere in the data center, or in the cloud, and integrated into the interface using client side interfaces, Jscript, CSS, HTML5 and the like.

For developers, it means you don’t need to write a “SharePoint application” inside the SharePoint server.  Since the application will run “somewhere else”, a SharePoint developer could be a Java developer, or a web service guru.

The officially supported models for app hosting:

• Autohosted – app is served from Azure
• Provider hosted – app is served from another cloud location (internally managed, Azure, AWS, etc.)
• SharePoint hosted – JavaScript based, executes in the browser

In addition, it’s worth noting that the classic API for farm solutions has not been deprecated.  Developers can still continue to write code using the old API and deploying compiled packages on site farms same as ever.

But the new API has very little impact on the servers.  Since all the code is running somewhere else, and since the interface integration runs using client side (browser) code, “installing” a new generation application is, essentially, about adding and publishing an XML definition file to a customized application catalog library.

But where can users find these applications?  That’s the second part of the new app model.  SharePoint 2013 offers app developers the chance to publish their application for download and/or purchase in Microsoft’s online Marketplace (an integrated app store).   Enterprises can also create their own internal marketplace of approved applications. Microsoft’s stated goal is to create a rich a diverse ecosystem for SharePoint apps to rival the app stores for smartphones (iOS, Android and Windows Phone offer over 100,000 apps on each of their storefronts.)

Think back on the app registration process.  Basically, users adding files to a library.  Usually, that’s not a problem for SharePoint.  It’s a core function of document collaboration.  So if adding the app is OK from a capacity perspective, how should we decide about what apps to allow, and where?  That sounds like a governance question.

Governance

Governance remains the essential ingredient in SharePoint adoption.  If SharePoint users are guided and controlled to reach the right business results, usage and adoption usually proceed seamlessly.

But just as you can’t enable unfettered site creation without generating complexity, confusion and redundancy, merely opening up the application floodgates without guidance is a recipe for chaos.  Some major questions to help guide policy formation follow.

Are you likely to be an on premises environment, a hosted environment, or an Office 365 shop in 2-3 years? 

This is a key decision, because applications written for an on premises won’t make a smooth transition to cloud or Office 365-based implementations in the future

On the other, apps written using the new API, and hosted in the cloud, are platform agnostic.  Unsure moving to O365 next month, next year, or ever?  What the freedom to move back?  Use the new model.

However, we know that over 90% of SharePoint users connect to an on premises farm.  In two years, as Office 365 grows (40-50% CAGR according to analysts’ surveys) will that number be 80%?  70%?  Either way, it’s safe to say that the majority of SharePoint farms will continue live in on premises datacenters for the next interval.

SharePoint makes it hard (impossible) to use classic farm solutions in Office 365.  Your cloud roadmap will shape your application roadmap.

(I’m distinguishing the customized hosting providers, such as FPWeb and Rackspace from the more homogeneous Microsoft Office 365 environments.  For more information on hosting choices, Richard Harbridge and Sadie Van Buren have written a vendor white paper to explore that decision.)

Which app catalog(s) should we use?

Will we break the server?

Lastly, if you’ve made the decision to allow apps, USERS WILL NEED TO BE TOLD ITS OK TO ADD THEM.  Otherwise they won’t even ask for guidance.  They need to know that it doesn’t “break” the server.

Technical

Minimal impact on servers doesn’t mean there are no technical requirements.  (Silly.)  Although Office 365 and other cloud hosters (Rackspace, FPWeb, etc.) can take care of these details for you, here’s the roadmap you’ll need to consider if you’re going to use apps with your on premises environment:

Service applications.

SharePoint 2010 introduced “Shared Serviced Applications (“SSAs”).  SSAs are web application that provide commonly accessed services to the SharePoint enterprise, such as Search.  At a minimum your SharePoint 2013 needs to enable:

• User Profile Service
• App Management Service
• Subscription Settings Service

DNS and encryption.

Each app is delivered locally from a custom URL inside a farm subdomain.  So if your site lives at http://intranet.company.com

You need to configure DNS to support (for example) companyapps.com and direct it to the same IP addresses.

Also, if your SharePoint farm uses host headers (they almost always do) you also need to create a “blank” port 80 or port 443 SharePoint web application without a host header on the target server.   (This is thinly documented but essential to making apps work. See http://sharepointchick.com/archive/2012/07/29/setting-up-your-app-domain-for-sharepoint-2013.aspx for more)

Each applications is then served from a unique hash code for each app, resulting in URLs like

http://app-aba1117abab20.solutionapps.com/sites/apphome/[AppName]/Pages/Home.aspx

Domains and prefixes are configured using the Apps section of SharePoint Central Administration.

If the apps are high-trust (not full) you also need to create certificates and encryption under https.  (This is the default behavior for OAuth.)  Again, if you have host headers the certificate need to be “wildcard” certs [e.g. *.solutionapps.com] More details at http://msdn.microsoft.com/library/fp179901(v=office.15).aspx

Catalog creation

The catalog is a customized document library for publishing content and task pane apps.  It’s also configured through Central Admin, which allows you to specify a custom Marketplace Host template for the site collection that hosts the library.   Not a big impact,but another step in the process.

Conclusion

So that’s it – the non-development landscape for governing and deploying apps to the SharePoint.  See, developers don’t have to have all the fun!