Free ThreeWill Webinars for 2017

Danny serves as Vice President of Business Development at ThreeWill. His primary responsibilities are to make sure that we are building partnerships with the right clients and getting out the message about how we can help clients.

We’re excited to announce our Webinar Schedule for 2017 (all times in EST)…

  1. Moving from SharePoint Online Dedicated to Multi-Tenant – 1/26/17 @ 1:00pm – Listen Now
  2. Migrating from Jive to Office 365 – 2/23/17 @ 1:00pm – Listen Now
  3. Complex SharePoint Online/2016 Migrations – 3/30/17 @ 1:00pm – Listen Now
  4. Creating Award-Winning SharePoint Intranets – 4/27/17 @ 1:00pm – Watch Now
  5. Find Anything in SharePoint with Amazon-Like Faceted Search – 6/29/17 @ 1:00pm – Register
  6. Integrating Office 365 and Salesforce – 7/27/17  @ 1:00pm – Register
  7. Creating Killer Office 365 Apps – 8/31/17 @ 1:00pm – Register
  8. Building Popular Products for Office 365 – 9/21/17 @ 1:00pm – Register
  9. Budgeting for 2018 SharePoint Initiatives – 10/26/17 @ 1:00pm – Register
  10. Successful SharePoint Farm Assessments – 11/30/17 @ 1:00pm – Register
  11. Creating a SharePoint Governance Plan – 12/14/17 @ 1:00pm – Register

The schedule is subject to change (especially if presenters get overloaded on projects). Let us know in the comments if you have other topics that you would like us to cover.

Sign up below to get notified about upcoming events or follow us on twitter.

SharePoint is a web application platform in the Microsoft Office server suite. Launched in 2001, SharePoint combines various functions which are traditionally separate applications: intranet, extranet, content management, document management, personal cloud, enterprise social networking, enterprise search, business intelligence, workflow management, web content management, and an enterprise application store. SharePoint servers have traditionally been deployed for internal use in mid-size businesses and large departments alongside Microsoft Exchange, Skype for Business, and Office Web Apps; but Microsoft’s ‘Office 365’ software as a service offering (which includes a version of SharePoint) has led to increased usage of SharePoint in smaller organizations.

While Office 365 provides SharePoint as a service, installing SharePoint on premises typically requires multiple virtual machines, at least two separate physical servers, and is a somewhat significant installation and configuration effort. The software is based on an n-tier service oriented architecture. Enterprise application software (for example, email servers, ERP, BI and CRM products) often either requires or integrates with elements of SharePoint. As an application platform, SharePoint provides central management, governance, and security controls. The SharePoint platform manages Internet Information Services (IIS) via form-based management tooling.

Since the release of SharePoint 2013, Microsoft’s primary channel for distribution of SharePoint has been Office 365, where the product is continuously being upgraded. New versions are released every few years, and represent a supported snapshot of the cloud software. Microsoft currently has three tiers of pricing for SharePoint 2013, including a free version (whose future is currently uncertain). SharePoint 2013 is also resold through a cloud model by many third-party vendors. The next on-premises release is SharePoint 2016, expected to have increased hybrid cloud integration.

Office 365 is the brand name used by Microsoft for a group of software plus services subscriptions that provides productivity software and related services to its subscribers. For consumers, the service allows the use of Microsoft Office apps on Windows and OS X, provides storage space on Microsoft’s cloud storage service OneDrive, and grants 60 Skype minutes per month. For business and enterprise users, Office 365 offers plans including e-mail and social networking services through hosted versions of Exchange Server, Skype for Business Server, SharePoint and Office Online, integration with Yammer, as well as access to the Office software.

After a beta test that began in October 2010, Office 365 was launched on June 28, 2011, as a successor to Microsoft Business Productivity Online Suite (MSBPOS), originally aimed at corporate users. With the release of Microsoft Office 2013, Office 365 was expanded to include new plans aimed at different types of businesses, along with new plans aimed at general consumers wanting to use the Office desktop software on a subscription basis—with an emphasis on the rolling release model.

read more
Danny RyanFree ThreeWill Webinars for 2017

Moving from Full Trust Code to the Cloud App Model

Pete is a Director of Technology at ThreeWill. Pete’s primary role is driving the overall technology strategy and roadmap for ThreeWill. Pete also serves as ThreeWill’s Hiring Manager and is constantly looking for new talent to join the ThreeWill family.


Danny:             Hi, this is Danny Ryan from ThreeWill. I’m the Vice President of Business Development, and I’m here with Pete Skelly, he’s the Director of Technology for ThreeWill. We’re just covering, today, the five things you need to know about transforming Full Trust code to the Cloud App model. I appreciate you writing this blog post, Pete.

Pete:                Thanks, Danny.

Danny:             Starting off, you hit a couple of acronyms. Tell me a little bit more about the acronyms that people need to know to sort of get started with this subject.

Pete:                There’s really two primary acronyms for the blog post that you want to be familiar with. First, is Full Trust Code, or FTC. Full Trust Code is really the old server side way of doing things, so classic C# in having, essentially, full trust on the server. So, you had an assembly that was deployed to the server, it might have been deployed into GAC, for example. And, the other is CAM, or Cloud Application Model. The Cloud Application Model is really the, not just the SharePoint app model, but some additional ways of moving to the Cloud, and some of the patterns and practices you need to be aware of when developing Cloud based solutions.

Danny:             Awesome, awesome. What I’d like to do next is just sort of go through the five things that you mentioned here, maybe add a little bit of light to them. The first one that you started off with was “Avoid the Customization Tax of Declarative Code”. Tell me more about that.

Pete:                Sure. Typically, if you’re going to be declaring XML values and deploying your code using the old feature framework, what most people didn’t do is take time to use the feature upgrades. To be honest, it wasn’t the most robust and easy framework to use when you were trying to upgrade features. So, typically, what would end up happening is you would accrue a bit of technical debt when trying to do those upgrades. You would either deploy a brand new solution or try to do some things which weren’t declarative, and in the end, you’d be writing code anyway. So a lot of times, you might have gone through and created the XML files, created Element.XML files, and deployed your code using features, which was the suggested model. It was what we knew back then.

Danny:             Mm-hmm (affirmative)

Pete:                And what was suggested, but at this point, now you begin to, essentially, pay a tax. So, every time you’ve got an update, you’re going to have to find a way to make those changes. And, either you’re going to be coding them in the end anyway, or you’re going to have to add and bolt on additional features, and it’s just going to turn into a Franken-feature over time.

Danny:             Okay. Okay, gotcha. The next one that you have up, and you’ve mentioned this, I remember you talking about this before, which was “Transformation Not Migration”. I think I was saying “migration” once, and you were like, “No, no, let’s say transformation instead.” What do you mean by that?

Pete:                I think it’s pretty clear from Microsoft, at this point, that some of the things that you’re going to have to learn, and this is true in my opinion, at least, for Cloud App development in general. If you’re going to take dependencies on an external services, or consume rest based API’s, or you’re going to basically push code into the Cloud and have to deal with the resiliency issues, or compensation patterns, et cetera, you’re going to have to transform code and not just kind of pick that code up and bolt it into another place. So, migrating your code isn’t necessarily the right thing to do.

Danny:             Mm-hmm (affirmative)

Pete:                All too often, folks kind of look at it and say, “Oh, I did an SP Timer job”, is the connotical example in the old Full Trust world. “Why can’t I do that in the new world?” You really can’t. You really need to consider, should that be a timer job at all, should it be something that might be a workflow, should it be a web job that runs in Azure or some other pattern? So, you really need to consider what business problem you’re trying to solve, and what functionality you’re trying to address.

Danny:             Mm-hmm (affirmative)-

Pete:                And transform that solution, not just migrate the existing code. And, yes, that does mean you’re probably going to have to rebuild some of these solutions, but we’ll get to one of the other items, and you’re going to have to just pick and choose some of these things, and probably transform gradually.

Danny:             Gotcha. In the third one, you said that “To Control the Provisioning Process”, that that’s a critical piece. Why is that?

Pete:                Yeah, I think controlling the provisioning process is really the most critical portion or aspect of moving to the Cloud App model. If you can begin to enlarge provisioning scenarios, if you can begin to control that provisioning process, you’re going to move away from having to pay that customization tax. You’re going to be in a better situation, you’re not going to have some of those files that are deployed that are dependent on features, and that are using unghosted files. So, if you learn to control the provisioning process, or you can take advantage of that and utilize the code to deploy your new asset sites, you know master pages, any files list, content types, et cetera, you’re going to be better off in the long run. Really what you’re trying to do is isolate your maintenance and upgrade surface, and reduce that customization tax.

Danny:             Gotcha. The fourth one you have is “To Transform Gradually”. Tell me more about that one.

Pete:                We keep referring to that customization tax, and I think a lot of organizations today, they’ve made a significant investment in SharePoint. So, if you can control that provisioning process for your new sites, that’s one way to kind of move towards the future. But, if you’ve already got a huge investment in SharePoint, say you’ve got thousands of site collections, you’re probably not going to be able to move all that content really quickly. But you can do some things like use C-Song to actually create new elements and upgrade the existing content, and move slowly over time. And, you can do that in place, you’re not disrupting business, you’re not losing business continuity, you’re not impacting your “whatever or why” you’re trying to get out of those older “sites”. So, I think transforming gradually, really, you have to look for those green field projects to move to the Cloud App model, but even if you have Full Trust Code out there today that you can’t completely remove from the existing farm, you can start to move that, and actually move existing content to this new model. So, you do have some options to move gradually.

Danny:             Green field means a “brand new” project?

Pete:                Brand new project.

Danny:             It’s just a brand new, all your brand new projects.

Pete:                Yeah.

Danny:             Got it. Gotcha. The fifth one is “Finally Because You Can”. Tell me more about that one.

Pete:                For a lot of our clients, working with some other developers and some of our clients, a lot of times people will ask, “Well, I can do this in Full Trust Code and I can do this still using features.”

Danny:             Uh-huh.

Pete:                And even in the past, it’s always been, at least from our perspective, just because you can doesn’t mean you should. You’ve got to look at the business problem you’re trying to solve, and with all the things that you can do in SharePoint, it’s really trying to find those patterns and practices that the Office development team is pushing that will make your life a little easier. If you’re going to go to the Cloud, great, you need to have these models and patterns that are going to let you get those updates on a regular basis. You’re trying to consume those services in a commodity fashion, so if you code yourself into a corner and can’t get those updates, you’ve done yourself a disservice, right?

Danny:             Mm-hmm (affirmative)

Pete:                So, just because you can create a custom master page, doesn’t mean you should. Now, does that mean you should never do that? Probably not. There are cases where I would probably say, “Yes, go ahead and create a custom master page”, or use some of the older patterns. But, you’ve got to kind of look at it and be pragmatic in your approach. If you’re going to be On-Prem for a long time and you’ve got a huge investment, it might be worth keeping some of those things in place. So, just because you can, doesn’t mean you should do those things. It’s really kind of looking at it and determining what you want to do, when you want to do it.

Danny:             Gotcha. I appreciate you taking the time to write this blog post, and spending some time with me today. For all those listeners, I wanted to let you know that we are going to have an upcoming webinar in May of 2015, so please feel free to drop by our blog. It will have more information on that webinar. If you want to see any of the webinars from Three Wheel, go to, and it will have a list of all of our webinars. Thanks again, Pete, for your time today, and I really appreciate it.

Pete:                Yeah, thanks.

read more
Pete SkellyMoving from Full Trust Code to the Cloud App Model

New Business Operating System Webinar

Pete is a Director of Technology at ThreeWill. Pete’s primary role is driving the overall technology strategy and roadmap for ThreeWill. Pete also serves as ThreeWill’s Hiring Manager and is constantly looking for new talent to join the ThreeWill family.

Hello everybody. My name’s Pete Skelly. I’m a principal consultant and Director of Technology here at ThreeWill and I’d like to thank y’all for joining me today. We’re going to do a quick presentation on the new business operating system what ThreeWill’s calling the new business operating system and discuss the combination of Office 365, Microsoft’s Azure and on-premises products and how they can create value for your business.

So, let’s dive right in. We’ve done this presentation a couple of times and typically I start off and explain Why Live Event. So, in October of 2014, we published a white paper that really described what we call the new business operating system and why we believe that the new business operating system really provides some compelling opportunities for enterprise collaboration, increases in productivity, and innovation.

Second, we wanted to share how we see clients using the Cloud today. For most of our clients, hybrid is their reality. So, really explaining that the hybrid environments in Cloud on your terms is really what the Enterprise Cloud is going to be like for quite a while.

Then finally to discuss some benefits and success stories that ThreeWill’s learned over the course of about the last two years moving clients to the Cloud, working on some proofs and concepts, and also find out how some folks are using the Cloud offerings today from Microsoft and from other vendors and how that hybrid story is playing out.

First, the Cloud means a lot of things to a lot of people. There’s a lot of … some information about the Cloud that, frankly, can be cloudy. Pun intended. So, let’s define some terms. To start off, Cloud computing can be a really scary topic to a lot of folks. A lot of clients are very concerned about moving to the Cloud. They often have concerns about compliance or how do I move an existing app? What does it mean for Office 365? What does it mean for my users? What does it mean for my investment and share points? So, let’s start with some terms and some models, some delivery models and then we’ll dive into a little bit about what the new business operating system actually is.

So, to start, the first delivery model is something that everyone’s familiar with. It’s the traditional IT Model where you own the entire stack of delivering and application. So, from the networking physical storage, the actual server hardware managing the OS all the way up through any data that you have to provide, disaster recovery solutions, the application itself and all the clients that would consume it. These can be on-premises, they can be private in a private Cloud like PC Mall or Rackspace, and they can also be in public Clouds like Microsoft Azure.

The second hosting model, or delivery model, is an infrastructure as a service and this is when you start to move to managing some of your infrastructure as a managed service. So you begin by virtualizing some hardware, some storage and a portion of the OS. These can be on-prem, these can be, again, in the Cloud with a private provider like PCM, Rackspace and also with Azure or another Cloud provider. The key here is moving up that stack so that you’re concerned with less of the physical hardware and less of the management of that infrastructure for servers and hardware even to the point of patching some of that OS. You may be responsible for some of it, but you’re moving up that stack.

The next delivery model is platform as a service and platform as a service, or PAS provides a solution as a service typically built on top of infrastructure as a service, or IAS. This can be provided, again, on-prem, private or public situations and here the focus pulls all the way up to the top of the stack to where you’re more concerned with your applications and your data. We’re less concerned with the OS, that’s even taken out of our hands, in most cases. We’re very concerned with how the data and the applications provide value to our business.

Then finally, there’s a business model which is software as a service and this is a full solution. So, SAS, or software as a service, is a business model where everything is delivered to you from networking storage, servers, data, the application itself. You’re consuming that service and you may have multiple clients, a desktop, a laptop, a phone, etc.. This is just one perspective. If we take a different look at how those delivery models are consumed, you begin to see a little bit of a different picture. So, in an IAS, or infrastructure as a service delivery model, we’re typically going to migrate to it. So the physical resources we may take those physical resources and actually package those physical resources up and put in a new, or an old Legacy system on a new virtual machine management system in the Cloud. So taking something like an old accounting application that has to run on Windows server 2003 or Windows XP and actually putting that up into the Cloud using infrastructure as a service, that’s one way of migrating to infrastructure as a service, or one of those delivery models.

The second, in a platform as a service, we’re typically going to build on it. So, in platform as a service, or PAS, we build the solution on top of the platform typically something like e-mail or storage. We’re going to interact with the compute cycles or we’re going to consume some of the data storage for image processing, for example. So, we typically build on top of an operating system. All the middleware may be provided to us. Some of the frameworks may be provided to us and this enables us to customize and build applications that are really providing our business value and not having to worry about some of those resources that are in the infrastructure data center physical resources.

Then finally, from a SAS, or a software as a service perspective, this is really the [consume 00:07:19] it model. So with a SAS solution, you’re consuming the entire app, UI, configuration, across multiple devices, etc. This is a different perspective and the reason I have the shading here will become a little more apparent in a different slide. So, remember how that shading appears.

There are also four compute patterns that are often associated with challenges that the Cloud delivery models address. The first computing pattern is On/Off. So this is typically used for development tasks, or prototyping, very intermittent compute needs. Think here of business intelligence processing, or nightly processing call center data for reports and this is all things that you would typically over provision hardware for. You’re just going to have something running for a short period of time and then it’s going to be off for quite a while and then run again in the future.

The second compute pattern is Growing Fast and this represents pattern of growth in which it’s unlikely that you can provision hardware fast enough to respond to increases in need for your application. Think of Facebook, or Twitter, probably Snapchat or any of the consumer apps that kind of take-off and grow extremely fast. They have zero deployment lifetime so they need hardware as quickly as possible and typically you can’t think of, “How am I going to deal with that?”

The third compute pattern is Unpredictable Bursting and this unexpected growth. So, my service or application may be going along perfectly and then I have this giant spike. Here you might think of something like when Ashton Kutcher tweets about he’s going to back your start-up and you get billions of hits to your website instantly. There’s no way you can predict that, but the Unpredictable Bursting model is something that you have to deal with.

The fourth compute model is predictable bursting. This is for things like seasonal, or predictable loads. Things that are cyclical, tax calculations, for example, seasonal staffing. If you’re a logistical company that needs to have an increase in staff or a retail industry that needs to increase staff and compute time for some of your retail operations. You know those things are coming so you can actually compute … you can deal with compute needs you’re going to have based on those cyclical needs.

We talked a little bit about Cloud delivery models and about the compute patterns that they can address. So, let’s dive a little bit deeper with what we mean by that operating systems analogy. First, the new business operating system really starts with that top layer, an application layer if you will. On a desktop operating system, we’re all familiar with using different applications: e-mail, word, word processor, any app that you can think of. With the new business operating system, this is now a transparent layer. You have to be able to consume applications from a browser from an android or IOS device, desktops, laptops. I can use all of them in this application layer, but I also have to have access to things like business apps, not just things like Office 365, or Yammer, or my typical office productivity apps.

The second layer of the new business operating system is a security layer. With a traditional desktop operating system, I typically want to know who the user was for audit reasons, perhaps I wanted to have group policies that provisioned applications, might want to know what they were accessing, might want to be able to say which locations on this they could save files, etc. With the new business operating system, I need to know that as well, but I need a mechanism that is going to work in that transparent mobile world. I need something that will enable my identity and my user’s identity to be location transparent and more and more [O-Off 00:11:53], specifically [O-Off2 00:11:55], is being that security mechanism that providers are using to enable that transparent, or location transparent identity and still provide things like audit access, group management, etc.

The third layer is a services layer and in the traditional desktop world when you use something like Microsoft Word, or PowerPoint, or Excel and you click Save, I doubt that anybody really cared about how that document got saved, but there were services that are taking care of this. In the new business operating system is no different. In the new business operating system we just have those services at a higher level, things like e-mail, task, calendar, search, workflow and many others, but I’m not limited to just consuming Office 365’s APIs. I can consume my custom business APIs or services and third party services. I can also consume other Cloud services from other providers as well.

Finally, the fourth layer of an operating system traditionally deals with things like storage, caching, memory management and a whole host of other things. For example, if I send you a five megabyte Word file and you click Save, you’re not thinking about thread management, or how that file’s going to get stored to disk, or any of that. In the new business operating system, we have that same series of needs for things like scheduling, caching, we have to have hardware that things physically run on, but in Azure … in the new business operating system, the combination of Azure, on-premises services and that operating system layer it manages memory, CPU usage, responds to application needs and it automatically can scale to meet those compute models we just talked about.

So, this is all great, but why is it important and why do we think this is going to help enterprises be more productive and potentially innovate? What problems does this kind of new business operating system really solve? We said that the Cloud, for the enterprise, is about hybrid. So, let’s kind of take a quick step back and look at what a view of your Cloud profile might look like when you’re dealing with moving to solving delivery model and compute pattern problems that we just described and how that new business operating system might help.

So, first there’s the on-premises world. This is that traditional IT, you own everything, on-premises situation. It’s familiar to everybody. Everything on-premises. We’re all happy of consuming maybe SharePoint data and Exchange, etc. and I’m in control of all of this. At some point, my CFO may come along and say, “I’ve heard about the cost savings from the Cloud and I want to start consuming that software as a service for things like commodity services like e-mail, calendaring and this is great. So now we’re starting to dip our toe into the world of the Cloud. I may see some opportunity to use infrastructure as a service for something like that accounting app that I mentioned, something that is a Legacy application that we could potentially package up and move to the Cloud as an infrastructure as a service capacity. This may or may not work perfectly. You may have some adjustments to make, but you can get that service off into the Cloud and maybe mitigate some risk of some old hardware that’s about to fail.

Then you might say, with new projects, we’re going to start to move to the Cloud by creating platform as a service applications, or PAS, solutions that you can develop using SQL storage, for example, or mobile notification features, anything that you can do to kind of pull those services up into that PAS environment and reduce your IT operations burden. At some point, you may have a sales person come to you and say, “You know this is great. I have marketing data that our sales people have put out in the public SharePoint environment and I have private information that is sales related, and sales figure related that I need to make sure that I’m pulling the data from both locations.” How can we deal with that? So, you’re probably going to end up with a hybrid Cloud search situation. So, in this case, you might want to search across SharePoint [and 00:16:52] the Cloud and SharePoint on-prem and actually have a unified search experience.

At some point, you may find another company needs to have services like a private Cloud. For example, I may need to host virtual machines and networkings, etc. outside of my own environment. So, I’m going to probably work with a private hosting company and try to get those IS Services, or infrastructure as a service, into a private Cloud. Maybe I have specific needs for more compliance, or I need more control, maybe we’re ready to go do the Cloud, but not totally ready to go to a public Cloud.

Once we have that private Cloud, we may find that we actually can manage this environment and we do have the need to actually get more benefit from those commodity type services. So we could, potentially, move to a dedicated [inaudible 00:17:49] Office 365 and actually have dedicated services or an isolated environment for those commodity services.

Then we may find that that same sales person, or sales team, that was working with external customers for marketing and sales data now they have to have some integration with additional SAS services, or software as a service, that they’re consuming and their clients are consuming from the public Cloud. So, at this point I may need to integrate with a CRM system, for example in my on-prem or my IS Solutions may also need to save documents back to another public SAS service.

Finally, I may have infrastructure as a service on-prem and using virtual hardware etc. that I need to connect up to the public Cloud IS services for things that might be big data analysis, or I have a factory floor that has IOT devices that I want to update from on-prem to the Cloud, or I want the Cloud to process the data, but I want the reports built internally. So, based on this kind of diagram, or picture of how the Cloud really will operate for most enterprises, the reality is hybrid Clouds are in your future and that new business operating system that we just described helps you interact with this type of Cloud, manage your business processes, and your infrastructure, securely, transparently, and in a really scalable way.

So we talked about what the Cloud is and what the new business operating system. Let’s talk about some of the benefits that we think the new business operating system can provide to your business. The first is the new business operating system really helps you move to the Cloud on your terms. This is the most critical benefit. Since most enterprises are likely to require some sort of hybrid environment, that new business operating system is delivery model independent. You can combine public and private Clouds as we said. You can use e-mail, or storage, any of those commodity type services. You can then use infrastructure as a service to host some CRM application that you have to have that’s Legacy and it’ll take you a while to get off of that. You can combine all of these things on-premises, private, public, and hybrid scenarios, things like search, reporting, big data analysis.

A second way that this enables on your terms architectures is incremental adoption. You can incrementally adopt the Cloud. It’s not an all or nothing situation. You can slowly adopt the Cloud by using on-premises, or a private IS solutions and migrate slowly to the Cloud when you have the opportunity. You can gradually decrease your IS footprint and increase your PAS footprint, or platform as a service, over time as those applications need to be replaced.

Finally, you can consume those SAS services when they make financial and business sense. If you can do it, great. If not, you still have those other options. In the new business operating system enables you to move from on-premises to private and public Clouds transparently. So, I can have new business apps using the new app models, of today, on-premises and this enables me to kind of future proof my applications as I want to move those into the private or public Cloud. This also lets me manage virtual machines across Cloud boundaries with an easily managed, simplified, single control surface for all of my hardware, all of my virtualization needs, and all of my application needs.

The second benefit is it reduces the time you spend on routine maintenance. So, using commodity services like e-mail, SharePoint, link and more decreases your IT operations management service area. The [second 00:22:21] thing is by looking to reduce your IS management and increase your PAS solutions over time, you’re going to spend less time in routine maintenance. As you increase those platform as a service, or PAS, solutions in your environment, you’re also increasing IT’s ability to participate in adding or [inaudible 00:22:45] to the business. You’ve got tons of IT folks that are really smart people that aren’t necessarily wasting their time but spending time on low value tasks when they could spend time really impacting your business because they know a lot about your business.

As just a point of reference, in late 2013 80% of IT budgets were still tied up in routine maintenance. Just think about if you could unlock some of that potential and turn your IT folks loose on helping your business.

So, the third benefit is the new business operating system enables innovation together with Microsoft moving to what’s called the continuous delivery model, this is a really critical change in the way that they do business. So no more three-year product life cycles, no more waiting for SharePoint 2007 to 2010, or 2013 and 2016. If you’re using Office 365 or Azure, futures are continuously and incrementally released monthly, weekly, even daily if needed if they have security fixes or critical bugs. This continuous delivery life cycle of products and services means that we have to change as well. So, how we, as consultants, or you, in your particular business, how you provide value has changed.

The second thing is the Cloud moves faster than Moore’s Law. Moore’s Law states that every 18 to 24 months processes will cost half as much to produce and be able to perform twice as many operations. I probably butchered that a little bit, but you get the gist. So, we use this plan to actually plan our business and IT strategies for years. So, according to your two to three year cycle, what did we use to do? License cost, we used to redo licensing agreements every two to three years. We would purchase hardware every two to three years. For servers, we might do a hardware refresh for phones or laptops for our end users, but we’re not constrained by that two to three year cycle anymore. The Cloud moves much faster than Moore’s Law.

Third, the new business operating system allows us to incrementally innovate. So, I can move more and more to those PAS solutions. Once I do that, I can find opportunity to innovate because now I’m not constrained to these two to three year cycles, I can innovate much more quickly and perhaps differentiate myself for my customer from my competitors. So all of these combine to make businesses more efficient, IT more productive and focused on ways to innovate.

The fourth benefit is that the new business operating system promotes process cohesion. If we look at a traditional full stack application, typically you’re required to create and deliver everything in that application. So, let’s take a look at kind of theoretical, hypothetical onboarding solution. So, if I were going to onboard a large amount of users I had to build the entire solutions provision hardware, patch the OS, I had to go through and make sure networking was set up correctly. As far as integration with other systems in that middle tier in that PAS layer that we would typically think of now, I had onboarding functions that were specific to my business value, security issues, but all the way up that stack, I was responsible for everything. This solution does not scale well. For those delivery models that we discussed earlier, those delivery models and compute patterns are limiting to me in this environment.

So, the new business operating system promotes a more cohesive process in application. If we were to build that onboarding process today, we might start with our business logic and really figure out how can I provide that as more of a service that can be consumed across multiple layers? Well, if I start with a service from my onboarding logic then I can start to consume other PAS services like storage. I can consume an e-mail service. I can start to integrate with other third party apps that they’re responsible for their own infrastructure as a service or PAS solutions.

Then we can start to think of [inaudible 00:27:28] as a consumer of our services versus something that we’re providing and tightly coupling ourselves to so we can provide SharePoint as an interface, Outlook, and even Word. So, if we’re building on the new application model from Microsoft, I actually have the ability to write even a single code base that can be consumed from those three environments.

This trend of cohesive business processes, things that are tightly defined and very small and composable compact services. It’s not new. It’s not kind of the nouveau thing, but it does hint at a larger trend. So, if everybody’s using the same SAS solutions, or consuming some of these PAS solutions how do you differentiate? Well, if you start to notice these little changes you can start to look at how are these things going to impact me, long term? What are the bigger changes that are coming? Increasing the number of PAS services that you have over time will increase your integration opportunities exponentially. So, this is really where innovation can start to occur.

The fifth benefit is this stack is technology agnostic. The new business operating system enables us to use the right tool for the job. So, if you are familiar with .Net, and ASP .Net, and C#, and SQL server, etc., then go ahead and use those tools in your tool bag. But, if you have a different tool bag and, you have a different skill set, or different business needs you might want to use the LAMP stack, you know using Linux and Apache and PHP may be what your developers internally know and you’re not constrained to that anymore. If these things make sense, use them. A frequently asked question is: why would I not use a relational database, or why wouldn’t I use a document store for this? Now, you can do those things when developing Office and SharePoint solutions.

As your business grows, you’re going to see new opportunities to innovate and those opportunities may require some new architectures or software designs. So this new business operating supports massive scale and all those compute models. There are a variety of services that you can consume from storage and mobile messaging and, all sorts of things. These are all possible so using high [through 00:30:12] put processing for IOT media services and more. Those things are not only going to be available to you, but you also have to think of, “If I take a dependency on another PAS service, how do I create a resilient design that can compensate for some of these failures that might occur?” Networks will go done. Services will have interruptions. There is no such thing as 100% uptime. So, you’re going to have to learn to look at some new opportunities for architecture and design.

Finally, the new business operating system gives you the freedom to choose the right technology based on your business scenario. So, if you look at SharePoint, Outlook, Custom Web, Web Axe, and Workflow for your departmental processing needs, you can also use the new business operating system for media integration, IOT, Power BI, and SharePoint, all those things. So, when you find something that is critical for your business to be successful, you can utilize the new business operating system to impact that change and you’re not driven by technology. You’re driven the solution … the problem you’re trying to solve, the right solution.

So, to recap the five benefits of the new business operating system really, if you look at the top benefit on your terms architectures, it’s really what this new business operating system is about and what ThreeWill’s really trying to kind of explain this to some of our customers and reduce some of this anxiety about moving to the Cloud. It’s not an all or nothing proposition. You can move to the Cloud on your terms and get all of these benefits out of moving to the Cloud.

So, some success stories. We created, about 18 months ago, a perfect concept application that was an Azure based sales enablement application called Popcorn. This was a contextual based search application that aggregated content across multiple SAS services. So, this really proves that kind of those cohesive services that once you start to combine them, you can get new powerful applications out of those different services. This not only has search but integration with other technologies like push technologies for mobile phones, dial technologies. So from a search result actually being able to dial my phone and start a conversation with someone.

We had a recent client that we completed a seasonal staffing application for so that onboarding application, that fictitious example isn’t so fictitious. It’s a real world example of an Office 365 intranet and an Azure based public facing web application that eliminates a paper based, Excel based hiring and termination process. The internal processes for approval, routing, some of the process automation, all the status management, and internal HR review process, that’s all handled within Office 365. The background checks and integration with termination process and hiring and payroll all those are done from the Azure side, but this is a great example of that predictable burst pattern. So consuming Office 365 commodity services, the intranet, and the HR staff go about their business on a daily basis and just perform their job like normal. As their season starts, that cyclical need for compute power it’s automatic.

The third example is a hybrid search environment that we created for a client that needed to have search from on-premises and an Office 365 environment actually deliver aggregated search results. They needed single sign on, they needed people that were external to an office be able to actually log-in, search o-premises data, and Office 365 data but get an aggregated search results.

The fourth example is an IOS application proof of concept that we wrote that uses Office 365 and Azure to access SharePoint documents and SharePoint document libraries using single sign-on from Office 365 provide native capabilities of the IOS device like search, offline storage, sharing, texting, etc. This was an application that really kind of suits the need of, if I need to have an application that really has native functionality and pushes into that familiar experience that users have as consumers, it’s more than possible. I can integrate with all of Office 365 and Azure from different devices today.

Finally, we’ve recently completed an infrastructure as a service based SharePoint 2013 portal for a law firm. This portal is an IS based for clients and matters which enable internal users to have that single sign-on experience, external users, their clients, to actually log-in and access resources all using infrastructure as a service to manage and house a complete SharePoint 2013 [form 00:36:08] because they needed some special features, they had some special code that needed to run and this enabled IT full control of that environment.

In summary, the new business operating system really lets you provide value to your business by consuming those Office 365 commodity services like e-mail, and SharePoint, and link. It can also help reduce long term costs gradually by letting you reduce your on-premises IAS needs and increase those PAS solutions over time.

As hopefully, we’ve made a case for hybrid Cloud is probably in your future. It is the enterprise Cloud. Using the new business operating system can help flatten that control plain that IT, operations and your enterprise has to deal with in order to manage that hybrid environment.

Finally, ThreeWill can help define your business application profile and see how that new business operating system can help start moving you to the Cloud today. In probably a final note, the Cloud isn’t just about compute power and, the cost of storage. Many people say it’s a race to the bottom as far as storage costs, etc. To us, the decision about using hybrid Cloud is about creating new opportunities, finding new ways to use the data and provide value to your business by moving to these different compute models and finding ways that the new business operating system can add value to your business today and in the future.

Hopefully, the Cloud is a little less scary at this point. Thanks for everybody’s attention. Here’s some of my information. Feel free to shoot me an e-mail, or ask any questions. There are my social media handles, so if you want to talk to me on Twitter @pskelly, or @ThreeWillLabs, and thanks for your time.

read more
Pete SkellyNew Business Operating System Webinar

Free Office 365 / Azure / Salesforce / SharePoint Webinars for 2015

Danny serves as Vice President of Business Development at ThreeWill. His primary responsibilities are to make sure that we are building partnerships with the right clients and getting out the message about how we can help clients.

We’re excited to announce our Webinar Schedule for 2015 (all times in EST)…

  1. OneDrive for Business – Tommy Ryan – 1/23/15 @ 1:00pm – Registration –
  2. Migrating to Office 365 – Chris Edwards – 4/17/15 @ 1:00pm –
  3. Moving from Full Trust Code to the New Cloud App Model – Pete Skelly – 5/22/15 @ 1:00pm –
  4. Get Up To Date on Microsoft’s BI Offering – Bo George – 6/26/15 @ 1:00pm –
  5. Integrating Office 365 and Salesforce – Eric Bowden – 7/17/15 @ 1:00pm –
  6. Getting Started with Salesforce Development – Tim Coalson – 8/21/15 @ 1:00pm –
  7. Moving from Office 365 Dedicated to Multi-Tenant – Kirk Liemohn – 9/25/15 @ 1:00pm –
  8. Integrating Visual Studio Online and Office 365 – Lane Goolsby – 12/11/15 @ 1:00pm –

The schedule is subject to change (especially if presenters get overloaded on projects). Let us know in the comments if you have other topics that you would like us to cover.

Sign up below to get notified about upcoming events or follow us on twitter.

SharePoint is a web application platform in the Microsoft Office server suite. Launched in 2001, SharePoint combines various functions which are traditionally separate applications: intranet, extranet, content management, document management, personal cloud, enterprise social networking, enterprise search, business intelligence, workflow management, web content management, and an enterprise application store. SharePoint servers have traditionally been deployed for internal use in mid-size businesses and large departments alongside Microsoft Exchange, Skype for Business, and Office Web Apps; but Microsoft’s ‘Office 365’ software as a service offering (which includes a version of SharePoint) has led to increased usage of SharePoint in smaller organizations.

While Office 365 provides SharePoint as a service, installing SharePoint on premises typically requires multiple virtual machines, at least two separate physical servers, and is a somewhat significant installation and configuration effort. The software is based on an n-tier service oriented architecture. Enterprise application software (for example, email servers, ERP, BI and CRM products) often either requires or integrates with elements of SharePoint. As an application platform, SharePoint provides central management, governance, and security controls. The SharePoint platform manages Internet Information Services (IIS) via form-based management tooling.

Since the release of SharePoint 2013, Microsoft’s primary channel for distribution of SharePoint has been Office 365, where the product is continuously being upgraded. New versions are released every few years, and represent a supported snapshot of the cloud software. Microsoft currently has three tiers of pricing for SharePoint 2013, including a free version (whose future is currently uncertain). SharePoint 2013 is also resold through a cloud model by many third-party vendors. The next on-premises release is SharePoint 2016, expected to have increased hybrid cloud integration.

Office 365 is the brand name used by Microsoft for a group of software plus services subscriptions that provides productivity software and related services to its subscribers. For consumers, the service allows the use of Microsoft Office apps on Windows and OS X, provides storage space on Microsoft’s cloud storage service OneDrive, and grants 60 Skype minutes per month. For business and enterprise users, Office 365 offers plans including e-mail and social networking services through hosted versions of Exchange Server, Skype for Business Server, SharePoint and Office Online, integration with Yammer, as well as access to the Office software.

After a beta test that began in October 2010, Office 365 was launched on June 28, 2011, as a successor to Microsoft Business Productivity Online Suite (MSBPOS), originally aimed at corporate users. With the release of Microsoft Office 2013, Office 365 was expanded to include new plans aimed at different types of businesses, along with new plans aimed at general consumers wanting to use the Office desktop software on a subscription basis—with an emphasis on the rolling release model.

read more
Danny RyanFree Office 365 / Azure / Salesforce / SharePoint Webinars for 2015

SharePoint 2013 App Models Considered – Part 5

Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.

It’s all downhill from here. In the previous posts in this series, I’ve offered an overview of the whats and wherefores of SharePoint 2013’s new app model and taken some detailed looks at three variations I’ve worked with:

  1. In the first post I talked about the new app model and how it marks an important shift away SharePoint’s historic app dev trends.
  2. In the second post I reviewed App Web Apps, the first of two SharePoint-Hosted app variants, and discussed why I think they fall short for most real-world solutions.
  3. In the third post I reviewed Host Web Apps, the second of two SharePoint-Hosted app variants, and discussed why I think they fall short for most real-world solutions.
  4. In the fourth (and previous) post I reviewed Provider-Hosted Apps, and talked about why I believe they represent the strongest option for SharePoint development going forward.

In this final post of the series I’m going to wrap up some loose ends and provide a scorecard tool you might find helpful if and when you need to evaluate SharePoint’s app model options for your organization.

Another Perspective on Provider Hosted Apps vs Farm Solutions

Before I wrap up this series, I want to take another look at Provider Hosted Apps. This time I want to compare them to Farm Solutions, i.e. the go-to standard for heavy lifting with SharePoint prior to 2013. Here’s a section from my previous:

Yes, Farm Solutions still have advantages at the edges. If your customization needs are light, Farm Solutions will get you there much quicker, especially for seasoned Farm Solutions developers. They may look odd and have poisonous claws, but they’ll win those short-distance footraces. On the other end, if your app needs deep access into the SharePoint API, beyond what CSOM offers, Farm Solutions are the only way to get there. Between those edges lies significant territory where the 2013 App Models are competitive: apps with more than a handful of user stories that require customization or domain logic, but don’t need an all-access pass to the SharePoint API.1

Let me unpack this opinion a bit. You may have picked up on the subtext that I’ve been frustrated with the stale, backward nature of SharePoint development since I started working with it in 2009. Nevertheless, I appreciate—deeply respect, really—the power that SharePoint brings to solutions out of the box. If your solutions can benefit from one or more of SharePoint’s core capabilities (content management, collaboration, search, provisioning, etc.), then building on top of SharePoint makes tremendous sense. Farm Solutions provide access to “guerrilla” customizations that are perfect for bridging that last mile gap between SharePoint’s out-of-the-box features and what your users need to be truly productive and happy. And most long-term SharePoint developers are proficient with guerrilla tactics.

The flaw with this approach, in my experience, is that many organizations want (need?) to push customizations way further than the last mile. Many of my recent clients have needed solutions that wind up looking more like web apps running out of SharePoint’s _layouts folder than a simple collection of coordinated SharePoint features and artifacts (content types, lists, web parts, etc.). I don’t blame my clients for this; I think SharePoint contributes to this delinquency in some significant ways2.

  1. SharePoint’s a Jack-Of-All-Trades. SharePoint packs a lot–probably too many–features and services into one set of similarly branded SKUs. From one perspective, SharePoint is really more of a collection of loosely-related services centered generally around “collaboration.” From another, it’s an accomplished provisioning engine, complete with self-service capabilities. From my favorite perspective, it’s a great package of services to plunder in custom applications. All of this disparate potential makes it exceedingly attractive for product owners to over-reach and ask SharePoint to do something it doesn’t do all that well, which spells heavy customizations.
  2. User’s Dislike SharePoint’s User Experience. People tend to like applications that have focused areas of competency and well-designed and defined ways of completing certain tasks. SharePoint tends to lean the other direction, supporting a breadth of malleable activities out-of-the-box. This makes it perfect for power users who can directly harness that flexibility and/or are adept at grassroots policy management, or for rapid prototypes and versions < 2 of a solution. But this flexibility translates to “vagueness” in the hands of less experienced users, and they frankly don’t like it. SharePoint’s long release cycles and technology lags (review the app dev timeline again for details) don’t help, either: SharePoint’s user experience feels perpetually behind the rest of the web by 3-5 years. And again, all this spells a high demand for customizations.
  3. Scope Creep is Natural. No matter what anyone else tells you, scope creep is the natural state of projects. This is at least as true with custom application development as with other business domains. Change is inevitable, and the app dev world is *filled* with unknown unknowns. Most projects I’ve participated in have experienced significant scope changes prior to the first release. Those that make it to second and third releases will almost certainly see scope changes north of 100% relative to original scope features/stories, code base…however you want to measure it. That SharePoint app that starts out as a handful of features can quickly grow to need custom web services and pages. That’s the point where ASP.NET MVC starts like a better–and cheaper–option.

In short, SharePoint offers some amazing, high-value features…they’re just trapped inside a difficult-to-approach, Swiss Army chimera. Or platypus, if you prefer. The problem is teasing out that value frequently requires you to customize more heavily than guerrilla development tactics can sustain. This is why Farm Solutions quickly loose ground to the Provider Hosted App model.

I’ve mocked up a graph based on estimates from my project experience that compares the productivity of these two options3

Dev Effort Curve Comparison

This chart compares the rate of change in level of effort for Farm Solutions and Provider-Hosted Apps as customization increases.

Following are some talking points for the chart:

  1. On the left side of the chart are projects with low customization requirements. For these projects, the clients are okay with most of what SharePoint brings to the table out-of-the-box. They typically have a small user base, and the user base tends to have a high concentration of power users. Projects internal to IT are a great example. They maximize the “OotB Advantage”.
  2. As the customization needs increase, moving right across the graph, SharePoint tends to get more difficult to work with, while Provider-Hosted apps enjoy a shallower LoE slope due to their high-productivity toolset and their affinity[note] for crafting modern and focused custom user experiences.
  3. At some level of requirement complexity the LoEs cross, and Farm Solutions begin paying a “Customization Penalty.” I’ve seen cases where this penalty becomes extreme; it’s frustrating to watch and even more frustrating to work with.

The App Model Scorecard

Since I’m now solidly in faux-quantitative territory (beware!), I’ll segue to my final thoughts for the series: the App Model Scorecard.

During the early stages of our internal discussions about the relative merits of the new App Model, the discussions (and my own thinking) were more conjectural and ambiguity-prone than I was comfortable with presenting. To give the process more rigor and consistency, we developed a scorecard that scored different app models across multiple features and concerns that are typical with real-world SharePoint applications. In all, we identified just shy of 50 separate concerns across 8 major app dev categories, and scored each app model (or other architectural choice) on a scale of 1 to 5 based on their fitness or ease of achieving that concern. The individual scores were discussed and vetted internally at ThreeWill, and I believe there is general agreement on them, but at the end of the day, if you spot some specious scores I’m the one who has to answer for them. I’m okay with that—bring on the rebuttals!

Rolled-up by category (i.e. the high-level view), the average scores look like the following:

SharePoint App Model Capability Score Card

The capability score card displays the relative fitness or ease of use score for each app model/architecture across 8 high-level app dev categories.

If you’ve read or skimmed the series to this point, these scores shouldn’t surprise you:

  1. The heavy 2s and 3s for the SharePoint-Hosted variants reflect their limited usefulness, constrained by the all the “Where They Fit” questions I presented in post 2 and post 3.
  2. In contrast, Provider-Hosted Apps enjoy *almost* the same level of fitness and productivity of Farm Solutions.
  3. As pointed out in the chart, the “Biggest Delta” is the ground Provider-Hosted Apps give up in productivity and tooling, most of which center on the difficulties with securing communication across the Provider-SharePoint boundary (it really is more painful than it needs to be).
  4. On the other hand, Provider-Hosted Apps do enjoy one area of advantage in the area of User Experience—UXes that put users at ease and get them productive are much easier with an MVC app using modern client tooling than building on top of SharePoint.4

While it might be interesting for you to see my/our scores for these app models, I’m actually more excited about what you might do with it. To that end, we’re giving away the original Excel worksheet we used to generate these scores. If you or your in-house SharePoint SMEs disagree with some of these scores (we know you/they will), here’s your chance to tweak them and evaluate your own posture toward the SharePoint 2013 App Models. I’d love to hear where you land (tweet @seansageek, leave me a comment below, etc.).

Conclusion and Download Our Comparison Spreadsheet

This puts the wraps on my SharePoint 2013 App Model blog series. I hope you’ve learned something, and even better if you’ve walked away with some free code and/or a scorecard tool. Since SPSATL we’ve been woodshedding ideas and proof of concepts related to smoothing our clients’ adoption of 2013 and the new App Model. New posts on those topics are coming soon. In the meantime, if you’ve got questions about anything SharePoint related, just let us know—we’re here to help.

Download a spreadsheet with all the details of the options we compared (with pros and cons of each) here.


  1. You can find this quote in context from my previous post in the “But I Don’t Want To Go To The Cloud” section.
  2. The opinions provided to support this point are not original to me, but I’ve observed them directly in many organizations, and in my experience they’re pretty widely held. A quick Google search will turn up a number of hits. One of my favorite recent blogs on this topic is “Why Do People Hate SharePoint?” from the EndUserSharePoint blog.
  3. I’m sad to admit I have no real-world numbers to feed this chart. I have shared it around internally at ThreeWill, and most of my colleagues agreed with the general concept it illustrates. If you happen to have real-world numbers across a statistically significant set of SharePoint projects and want to share it, I’m all ears.
  4. Apologies to the SharePoint User Experience team for this blunt assessment. They have a *very* difficult job at the conceptual level: Swiss Army chimera’s present a heavy UX challenge. SharePoint’s aging platypus architecture doesn’t help.
read more
Sean HesterSharePoint 2013 App Models Considered – Part 5

SharePoint 2013 App Models Considered – Part 4

Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.

Up to this point I’ve introduced some high-level considerations for SharePoint app development (part 1), and two App Model variants that don’t have real legs in my opinion:

  1. App Web Apps (part 2) are restrictive, offer reduced productivity, and create un-SharePoint-like data silos
  2. Host Web Apps (part 3) are restrictive, offer reduced productivity, and are frustratingly fragile (so far)

This brings us back to the thesis of this series:

The number of “real world” business cases where SharePoint-Hosted App Model variations make sense is very small; most solutions are going to require a Provider-Hosted app.

This post marks the inflection point in this series: for the first time I’m covering an App Model that I believe has serious potential. And the potential isn’t just serious; it’s broad and proven. The truth is, the Provider-Hosted App Model is just a SharePoint-flavored version of modern best practice throughout the rest of the industry: our custom code lives in app environments we control, and we consume other services via their public REST (or similar) APIs. This is the way developers build SalesForce apps. This is the way developers build LinkedIn apps. This is the way developers build Farmville. It has been the industry’s best practice for product integration for years, and SharePoint has finally caught up 1. Huzzah!

To wrap this back to my furry, duckbilled metaphor:

Breathe a sigh of relief and be glad! Now the platypus can stay happily in his backwater, and your app doesn’t have to crawl in with him just to collaborate.

As usual I’ll try to make this palatable and predominantly pain-free for the mildly interested (my entire audience?):

  1. Provider Hosted Apps Overview
  2. Real World Sample App
  3. What’s Good About Provider Hosted Apps
  4. What’s Bad About Provider Hosted Apps
  5. Where Provider Hosted Apps Fit
  6. “But I Don’t Want To Go To The Cloud…”
  7. Pro Tips for Provider Hosted Apps
  8. Notes

Provider Hosted Apps
As covered in my first post, one of Microsoft’s primary drivers for introducing the SharePoint 2013 App Model was to make SharePoint customizations cloud-friendly. To do this they had to get custom code off the SharePoint server. Period. The first two App Models we reviewed (App Web Apps and Host Web Apps) did this by completely eliminating server code from custom solutions. SharePoint 2013 offers a beefed up REST API, beefed up JSOM, and you can get a lot done in SharePoint with nothing more than that. Or at least it seems so on paper.

The difficulty with this approach is that getting rid of the server is a drastic move for most web applications. Most applications need server code for private logic, security, and/or to give the application “agency” beyond a user’s web browser request (i.e. for lifecycle events). And most web developers are more productive when they can write some part of their apps in server code.

So if your SharePoint app needs server code, but it can’t run on the SharePoint server, bring in another server!

This is the exact premise of Provider-Hosted Apps: let SharePoint focus on doing SharePoint things well, and bring in another “Provider” to host custom features and services. I’ll try to frame this in the physical-logical block diagram mash-up (with App Web and Host Web Apps provided for comparison):

Let’s cover the highlights:

  1. The SharePoint-Hosted App Remains. Whether you deploy anything inside it or not, your app needs this beachhead in SharePoint to provide an access point and to participate in whichever version of the “identity dance” you choose.
  2. The Provider Makes It Good. Okay, I’ll admit that’s rebuttable, but my opinion leans heavily in that direction. At any rate, the external provider defines this model, and that’s where I’ll focus my attention.
  3. BYO Web App. Your app is all grown up now. What dev stack are you going to use? Frameworks or services? 3rd Party Services? Dev environments? It’s all up to you.
  4. Server-Side Goodness, A La Carte. Being an adult means you get to order from the full menu. You can order a relational data store, or a non-relational one, or pig out with both and a side of your favorite message queue. Mmmm…message queueing.
  5. BYO Web API. I won’t go into to detail here, but SharePoint’s OAuth implementation is a bit non-standard, and SP.RequestExecutor is WAY non-standard. Many important browser frameworks work OotB with standard OAuth or REST, but break with SharePoint. Writing your own API may sound like a headache, but it’s one I’d gladly take versus the headache of shimming JavaScript frameworks. Besides, a clever app can find a number of delicious uses for a fresh API.
  6. Dump That Heavy Browser. Your app has a full middle-tier now, so the browser can eliminate the extra business logic burden, and focus on presentation logic, i.e. what it was designed for.

Are you hungry for a Provider-Hosted App yet?

The (Doubly) Real-World App
In my second post of the series, I mentioned that ThreeWill had rewritten the Fab 40 “classic” Absence & Vacation Request app as technology demonstration of an App Web App. I also mentioned that it turned out to have some glaring flaws due to the limitations of that model. In the wake of that and several other bad trips with SharePoint-Hosted variations, we decided to try another Fab 40 app, but this time as a Provider-Hosted App: Help Desk.

Following are some screenshots of the much-improved Help Desk application:


The features are stripped down, but under the hood this app has some nice specs: The server code runs ASP.NET MVC5, with Web API 2.0 providing services to the browser. In the browser it’s running Angular and Bootstrap for a SPA2 with a responsive user experience. This is a modern stack that is a pleasure to work with, and I don’t miss the platypus even a little bit.

In addition to that, it includes some key demonstration points that a new-to-Provider-Hosted-Apps developer will find useful. Things like application lifecycle event handling, and some helpers for identity management and navigating SharePoint security in both MVC and Web API controllers3. Trust me—those alone are worth the price of admission.

Just as we have for the Absence & Vacation Request app, we’ll be providing the full source code of this app for anyone who’d like it. It’s still too alpha to post to GitHub or similar, but you can request a zip of the code from me via email.

What’s Good
The Provider-Hosted App Model has a lot to recommend it, not only in comparison to the SharePoint-Hosted app models, but in some cases on an absolute level:

  1. Full Middle Tier. You gain so much here it’s difficult for me to overstate its value. Let me put it this way: remember the list of “bad things” about App Web Apps? This alone cancels out or significantly mitigates the first six of those seven issues. For most web developers, this will drive the value of Provider-Hosted Apps well past that of any SharePoint-Hosted variation. More on that below.
  2. Best-Of-Breed Dev Stack. You may have picked up that I’m a devout believer in the power of the right dev stack. Provider-Hosted Apps give you full control here, at every tier of your application.
  3. Design Freedom. The set of architectural and design controls for browser-hosted code has become significant, but it’s still tiny compared to what you can do when you have control over one or more servers or services. The only real restriction is you still need a SharePoint beachhead, but you have several choices on how you use it.
  4. High Availability. Remember my gripes about our downtime with SharePoint-Hosted apps? This is your best bet for high-availability customizations, period. Even more so than Farm Solutions, which have their own issues. More on high-availability below.
  5. Longer Reach (Into SharePoint). SharePoint 2013 has greatly expanded and improved its REST API, and expanded JSOM access with it, but CSOM can still scratch itches that REST and JSOM can’t. It’s nowhere near the coverage you get with Farm Solutions, but it covers a wide array of activities.
  6. Lifecycle Management (ALM). Seasoned JavaScript developers can manage ALM convincingly with tools like Jasmine or Mocha. But from my experience, most developers can get further faster with test automation, requirements management, and other ALM activities when they have access to the server tools of their choice in addition to these excellent frameworks.
  7. Performance Controls. When you only have code in the browser, your have meager controls for app performance. Adding a server or service to your mix opens up significant options. If that service happens to be running in a cloud environment, your control goes from significant to tremendous.
  8. Revenue Options. If you have any desire to derive revenue from your app, please don’t try it as a SharePoint-Hosted app. You’ve got no private IP (i.e. someone will steal your code), and very poor revenue controls. If you want revenue, the SharePoint-Hosted path offers nothing but headaches and heartaches.

What’s Bad
Nothing’s perfect, right? That’s at least as true with application architectures as anywhere else. Here’s what I find most troubling—or maybe not—about Provider-Hosted apps:

  1. More expensive than SharePoint-Hosted Solutions…Maybe. I concede that a Provider-Hosted app is going to have higher operational costs than a SharePoint-Hosted app4. But if you consider the big picture of how SharePoint apps provide value, and what drives costs in application development (hint: developer productivity is almost always a huge factor), the picture improves. If you’ve got questions about that math for a specific project, you know where to find me.
  2. More complicated than SharePoint-Hosted Solutions…Maybe. You definitely have more moving pieces and operational support requirements. But in my opinion you simplify your architectural and ALM picture because you’ve regained the most productive and mature part of your dev team’s stack: the server.
  3. More up-front effort required. Once the farm and site collections are configured for apps you can crank out a hello-world App or App Part about 15 minutes after you install the Office Developer Tools extension. For most organizations, getting the provider infrastructure setup and configured will take two to four weeks, varying by IT overhead.
  4. Steep learning curve. This will vary based on current skill sets. Anyone who’s been a full-time SharePoint developer for the last several years will need a significant firmware upgrade. Refer back to my app dev timeline—full-time SharePoint devs like me have been creating solutions with a strange brew of platypus, tribal knowledge, and black magic. The Venn diagram of Farm Solution dev skills and SharePoint 2013 dev skills has significant non-intersects:
    The SharePoint Developer's Dilemma

    The SharePoint Developer’s Dilemma

  5. Missing tooling & rough edges. We experienced some higher-than-expected pain with managing user identity and the SharePoint context, especially when moving our server code to the Session-less Web API controllers. As of this writing, the community is rallying around this issue with some community-sourced solutions, including the ones featured in the Help Desk Application.
  6. They give up ground to Farm Solutions. There are still a number of areas, especially in Farm administration, where Full-Trust code is required. I expect to see and recommend solutions that wrapper these basic functions in Farm features and then expose them via custom APIs. Only the logic that requires Full-Trust code will be deployed directly to the Farm; all other logic is free to move to the new App Model.

Where It Fits
In the previous checklists for App Web and Host Web Apps, they were all inclusive: you needed to be able to answer “yes” to ALL of the questions before I’d recommend that model. Except for the last two questions, the following Provider-Hosted App checklist questions are independently qualifying: if you answer “yes” to ANY of the first seven, I’d strongly recommend a Provider-Hosted App. Why are the last two questions exceptions? They’re crucial organizational gut checks .

  1. Your Use Cases Exceed UX. If your app has concerns beyond user experience (business logic, dependencies on external services, its own lifecycle, etc.), the extra security, privacy, and productivity will make this your best (or only) option.
  2. You Need Private Logic. You just can’t get there with an app written in 100% client-side JavaScript.
  3. You Need App-Specific Security. Other than the Task & Time Entry app, I can’t remember the last time I worked on an app that didn’t need some kind of app-specific security. And as demonstrated in the second post of this series, the lack of private, tamper-resistant logic in JavaScript makes real security unattainable. But on the server you can lock features down all day long. Sometimes without even coding5.
  4. You Need Complex and/or App-Specific Data. If your app needs complex relational structures or large data sets, SharePoint lists will disappoint you pretty quickly. Add a server, and you have tremendous storage options to meet all your data needs.
  5. You Have Strict Availability Requirements. JavaScript running in a browser against an API that’s still a bit squishy is no place for a high-availability app. Configure up some geographically redundant, load-balanced servers or services, use message queueing for your cross-service communication, and you’ve moved a couple of orders of magnitude up the high-availability food chain.
  6. You Want To Leverage Server-Side Code. If you have existing server-side customizations or libraries that you want to leverage, you need a server to host them. This might seem obvious, but it’s worth calling out because it’s an extremely prevalent issue. In spite of Atwood’s Law, there’s a lot of high-value, server-only code in the world.
  7. You Need Agency Beyond A Browser. Many apps have concerns that can’t be reasonably transposed to the app user browser request context: lifecycle events, scheduled activities, state monitors, batch processes, long-running asynchronous tasks, compute-intensive processes, etc.
  8. You Have Tolerance For Additional Complexity. Gut check #1: if you choose the Provider-Hosted path, you will own the care and feeding of another server or service. It very well may be a value-add that pays for itself, but it’s still another moving part. You should fully consider the implications of this.
  9. You Have Time To Learn. Gut check #2: if you saw the Venn diagram above, and you or your team are not already in the distributed app cognoscenti, then you’re going to be playing catch-up. If you’re a long-time SharePoint developer, my advice is to lean into it. You proved yourself once with your platypus-husbandry-black-magic chops. This will be better, and at the end you’ll have two sets of very marketable skills instead of one.

“But I Don’t Want To Go To The Cloud…”
Okay, then here’s my advice: don’t go to the cloud. At least not until you’re ready. And if you’re never ready, that’s fine, too. What’s the worst that happens? Microsoft goes all-cloud after the next SharePoint release, 6, and in 2026—WAY too far into the future to speculate on effectively—you’ll lose all support for SharePoint 20167. You’ll have better options before then. Heck, you’ll have multiple generations of better options before then. Keep your investment on-premises for as long as you think it makes sense for you.

The truth is, I’ve been purposely quiet on the On-Premises vs. Cloud issue throughout this series because I don’t believe it matters for a discussion about app models. I don’t think it matters because regardless of where your SharePoint infrastructure is located, I’d strongly urge you to plan your move to the SharePoint 2013 App Models now. Not because they’re shiny and new, but because they’re better—legitimately, straight-up better—for many applications, even those confined to private networks.

Yes, Farm Solutions still have advantages at the edges. If your customization needs are light, Farm Solutions will get you there much quicker, especially for seasoned Farm Solutions developers. They may look odd and have poisonous claws, 8, but they’ll win those short-distance footraces. On the other end, if your app needs deep access into the SharePoint API, beyond what CSOM offers, Farm Solutions are the only way to get there. Between those edges lies significant territory where the 2013 App Models are competitive: apps with more than a handful of user stories that require customization or domain logic, but don’t need an all-access pass to the SharePoint API. I estimate that 50-75% of the apps I’ve worked on for SharePoint 2010 could have been written as Provider-Hosted Apps, and almost all of them would have been better for it. Your mileage may vary, but it’s worth serious evaluation.

Before I move off this topic, I want to say a few words in favor of the cloud:

  1. Your data is *very* safe in the cloud. I’ll bet you a doughnut your data is safer in Azure or AWS than on your network. Cloud providers run tighter ships than the vast majority of internal IT organizations. That’s not a shot at your IT pros; it’s a realistic assessment of economies of scale and the value of focusing on core competencies. They stake their paychecks on a spotless security record, and they’re investing in it in ways which you can’t compete 9. No disrespect intended.
  2. There’s plenty of value in cloud hybrids. Maybe you have a data sovereignty issue. Or maybe you’re in a business where there’s value in the traditional subpoena process. Fine—but don’t throw the baby out with the bath water. Are there parts of your business that don’t require that coverage? Consider moving those to the cloud. Have you thought about solutions that outsource processes to the cloud but leave your data in place? These things are possible, and a great consultant can help you navigate complicated issues like this (hint: we’d love to help).

Pro Tips
Yet again, most of the pro tips from the previous posts (here and here) can be carried over. But now we’ve got some new server-side considerations. Some of these will be platform-agnostic, but I’m working with the explicit assumption that most SharePoint developers are going to favor .NET technologies. That will bleed through everything that follows, especially in the examples and supporting arguments.

  1. Learn From Others. There have been a number of trailblazers in this area, and they have tremendous insights (and code!) to offer. Not to slight anyone, or to state the obvious if you’re a SharePoint veteran, but these are the folks I’ve leaned on most heavily: Kirk EvansScot Hillier, Andrew Connell, Bas Lijten.
  2. Don’t Suffer In Silence. SharePoint developers, as brothers and sisters bound by the sacred vows of platypus-husbandry-black-magic, have significant simpatico and camaraderie. If you hit a tough issue, head to SharePoint StackExchange or tweet-out at somebody. Tweet at me (@seansageek) if you have to. If I haven’t covered it already in this series, I probably won’t know the answer, but I might know someone else here at ThreeWill or elsewhere in the community who will.
  3. Consider PluralSight. I can’t speak to all learning styles, but PluralSight fits mine very well. And for SharePoint developers committing to cross the chasm and join the cool kids, PluralSight has your back. Plus, if you want to maintain your SharePoint edge, Andrew Connell has hours of great content there, particularly for SharePoint 2013 workflow.
  4. Consider Dependency Injection and Inversion of Control. It’ll feel funny the first three or four times you do it, but using DI and IoC gives your app tremendous freedom and flexibility. And if DI and IoC are old hat to you, take a look at what IoC ninja Matt Honeycutt has done with StructureMap in his Build Your Own Application Framework with ASP.NET MVC PluralSight course. Yowza, that’s strong juju!
  5. Consider No-SQL Data Stores. If you’ve been in a SharePoint foxhole for years, No-SQL data stores like Mongo and Couch are the real deal at this point. If you need simple object persistence, check here first.
  6. Consider an ORM. If you checked your No-SQL options and couldn’t commit to that route, at least consider using an ORM like the Entity Framework or NHiberate. I’ve used both and found they’ve added tremendous value. Don’t spend time writing your own DAL if you don’t have to.
  7. Queue Activities for High Availability. If high-availability and recoverability is a concern, there are several good queueing options these days. Rabbit and Azure Service Bus Queues come to mind.
  8. Automate Your Testing. I’m not a TDD purist, but I am an automated testing evangelist. It takes time and discipline, but for most projects it pays huge dividends. Visual Studio’s own testing tools have made tremendous strides in the last several versions, and they’d get my nod as of now, especially if you’re a testing n00b.

Next Up: Conclusion & Next Steps
Have you already had your fill? Great! If not, I’ve got one last post in this series to top you off. The final course is dessert: I’ll draw some final conclusions about the SharePoint 2013 App Model, and offer you something for the road: a scorecard to help guide your thinking about which solution architecture offers the best fit for your applications.

Has this post given you heart burn? Let me hear about it! There’s always an open chair next to me in the comments or on Twitter (@seansageek).


  1. See my technology timeline from the first post for my take on how SharePoint has historically struggled to keep up.
  2. Single-Page Application
  3. These include customizations to the standard the SharePointContext and TokenHelper classes provided by Microsoft in the Provider Hosted App solution template. These customizations are necessary to extend access to the SharePointContext to Web API Controllers. This code owes a great technical debt to Bas Lijten–you can read more at his excellent blog on the subject here.
  4. Unless your needs are purely developmental, investigational or fairly trivial, in which case you might be able to skate by with a developer-oriented freebie from a friendly hosting provider.
  5. With ASP.NET MVC and Web API controllers, security can be as simple as marking methods with an attribute or two.
  6. There are exactly zero real indications that this will happen
  7. I keep hearing people say “SharePoint 2015”, but I’ve observed Microsoft release dates for a long time, and 2015 sounds stretch-y to me. It’s a judgment call.
  8. Male platypuses have poisonous claws. Yes, I’m running this metaphor into the ground.
  9. You can find the impressive details about Azure’s security posture here, and the even more impressive list of security certifications it holds here.
read more
Sean HesterSharePoint 2013 App Models Considered – Part 4

Choosing a SharePoint 2013 App Architecture Webinar

John Underwood is a Technical Evangelist at ThreeWill. He has nearly thirty years of software development experience. He is an experienced technical instructor with superior presentation skills and is proficient in delivering standard curriculum as well as developing and delivering custom curriculum.

Good afternoon folks. John Underwood here welcoming you to another webinar. I’m coming to you live from the ThreeWill offices in Alpharetta, Georgia, just north of Atlanta. I hope you’re having a pleasant day wherever you might be across the country or even in other countries.

A few quick introductory notes and then we’ll get started. First up, for those of you who’ve not attended one of our webinars before, my name is John Underwood. I hold the position of Technical Evangelist and ThreeWill. You can see a couple of contact points for me there. If you have follow-up questions after the event, you can reach me by email.

Also a couple of Twitter feeds that I participate in if you’re into using Twitter. I think you’ll see some pretty interesting and fun things come out there. One other thing, both for the sake of maybe some of your friends that didn’t get to join us today, or if you do have to leave us early, the video replay of this will be available at MIA website at the end of the event so please be sure and take advantage of that.

Today’s presentation’s a little different than some of my others in that I have to acknowledge another person. Generally when I bring you a webinar, it is content that I’ve created from scratch and had the good fortune to research, but in this case I’m actually covering material that was harvested and put together by a co-worker of mine named Sean Hester.

I’ve had the good fortune of working with Sean at a couple of jobs over the years and he’s just a really bright guy when it comes to researching and finding this, co what you’re seeing today is a derivation of a presentation he recently did at SharePoint Saturday. Again, all kudos to Sean there and some contact points for him if you’d like to follow him on Twitter as well or reach out to him with questions.

With that, let’s talk just a little bit about who’s attending today and what I hope to convey to you. Generally, my webinar audiences fall into 3 categories. The first of those being users, business leaders, IT management, people who aren’t programmers. For you, what I hope you get out of this webinar today is that if you do SharePoint customizations, you have some decisions to make in the near future.

While you will have to make those decisions, with the input of technical people, I think it’s important for you to understand the implications of what this will mean to you in your environment.

If you find yourself in an administrative role, either for SharePoint or other server products in your company, then the choices that your developers and you users and business leaders make about applications and customizations in SharePoint, they’re going to influence what happens to your servers.

I don’t think it’s a negative influence, but it is something that’s going to be important for you to know about and understand. Then most of all developers, this webinar really is going to talk about how if you’re a SharePoint developer, or you do SharePoint customizations, your world is changing in a pretty significant way.

We’ll talk about those changes and maybe some good opportunities that will come out of them. At the very least, what you’re going to see is that the choices of how we build SharePoint applications have changed significantly as are the tools that we’re going to use to build those apps. With that, here are the topics that I’m going to cover for you today.

First us, I’m going to kind of draw a line in the sand with a bold statement about what I, and collectively we, think here at ThreeWill about your application architecture choices when it comes to building SharePoint apps on SharePoint 2013.

Then from there we’re going to take a look at an evolutionary timeline of what it means to be a SharePoint developer. It’s not so much that I want to bore you with historical facts, but rather I kind of want to set up how we got to where we are and how this change that we’re facing, I believe, is mostly a positive change.

Then from there, we’re going to look at the various app models and obviously by the time we do that, I’m already going to have made a statement about which one we kind of collectively think is the best path. Having said that, we will look at both of the models and try to compare and contrast some of their pros and their cons and their intended usage.

Then finally some conclusions about what we’ve learned and covered in the webinar and how, perhaps, we can take that back to our companies and do something meaningful with it. When it comes to making a bold statement, again, you’ve got to be able to back it up with some facts, and that’s what I hope to be able to do for you over the next 45 minutes to an hour.

If you follow the Microsoft line when it comes to building SharePoint apps, in particular customized bits of code that are going to run inside SharePoint in some fashion. Basically Microsoft says that you have 2 models. The SharePoint-hosted model and the provider-hosted model. Now, quick aside, those of you who’ve kind of been on the SharePoint 13 train a little longer, may also remember something called AutoHosted.

Just in case you don’t know, AutoHosted is no longer available. It was put out as a preview and Microsoft decided, for whatever reason, to pull it back. If you’re not familiar with that, just understand that it was a variation on provider-hosted. I have no doubt that some of you in then environment, or excuse me, in the audience have a clear understanding of the differences and the pros and the cons of SharePoint and Provider-hosted.

If you don’t, don’t worry. I’m going to lay the ground work for that before we make a decision. However, what I think you’re going to see by the time we’re done today is that you really don’t have 2 choices, you really only have 1 choice, and that is you’re going to have a provider-hosted app and you just got to decide where you’re going to host it.

We’ll talk about that as well. A lot of times when I present I like to save the punch line for the end, I’m giving you the punch line at the beginning here. Really feel strongly that the provider-hosted model is the one that you’re going to be able to build real “apps” on. Then we’re going to talk about why and how over the next few moments.

This analogy that I’m going to lay on you, courtesy of Mr. Hester may seem a little out there, but I think it’s a perfect explanation so consider the strangeness of the animal we know as the platypus. A duck-billed, web-footed, egg-laying, venomous mammal. Almost an evolutionary freak, if you will, stuck in time somewhere back in the centuries and the eons.

How does that relate to us as SharePoint developers? You can see on the next slide, I’ve got a little timeline here that just kind of shows you the history of SharePoint and then the timeline of programming innovations along that line. I’m not going to bore you by reading every single point to you. What I would just offer is to look at a couple of things.

Number 1, if you look at the range to 2001 and 2003, that’s really the point at which it became viable to call yourself a “SharePoint developer.” You could actually build things like custom web parts and custom forms to customize the environment.

Then you can see over the time frame to 2007 and 2010, SharePoint obviously progressed and we would have to say that from the developer prospective, it got a lot friendlier, particularly upon the release of SharePoint 2010 where we could legitimately open visual studio and build a SharePoint project and not have to have a lot of magic in order to make it work.

Here, however, is the challenge that we have faced up to this moment as SharePoint developers. That is we’re based on a technology that is essentially nearly 15 years old. SharePoint’s fundamental web technologies up through 2010 were really based on the ASP.NET 1.x, and yes I know they changed framework versions as they went along, but this whole idea of building web forms and using server controls.

Serpa 2002, that was an awesome, innovative model, and it was something we were very happy to have. If you look at where we are today, there are a lot of things that have come along since then that for all practical purposes, as SharePoint traditional developers, we really couldn’t take advantage of that.

If you think of all of the parts that make up a modern web application, a responsive user interface, the use of the latest versions of the HTML, being able to take advantage of some of the more innovative JavaScript libraries that are out there, such as Angular or Backbone, none of those were really on the palate for us.

There are clever people who figured out how to kind of wedge these into the 2010 model, but the truth is, up until the moment that we get this app model in 2013, those things are really not on the table. What does that mean to all of us, both developer and non-developer? The world has just changed radically when it comes to doing SharePoint development.

Yes, we’re going to have some new challenges. We’re going to have to learn some new technologies, but on the positive side, we’re going to have a lost of opportunities to write applications in a way that just simply wasn’t practical in the old model.

If you’re a business leader, here’s another one. You have a larger pool of developers to choose from now. I can think about our own experiences, here at ThreeWill, where how many times we’ve said, “We need to hire a SharePoint developer.”

When you say you need to hire a SharePoint developer, what you’re really doing is saying, “I need to hire someone from a fairly small, fairly specialized pool” whereas with these new app models that we have, we can now more easily integrate developers that know a lot about JavaScript programming or a lot about DotNet programming, and help them come in and be productive in the SharePoint world.

Then just kind of in a more humorous way, what we’re really doing is moving up on the evolutionary scale. We now have a world where we can take advantage of all of the latest innovations when it comes to web-based programming.

If you think about one of the primary drivers in customizing SharePoint, and that is to give it a more pleasing user experience, then the fact that we can now take advantage of a lot of browser-based technologies that innovate on UI, that is really a big thing.

If you are a developer, if you’re already onboard with these changes, that’s great. If not, this is kind of a wake-up call. Your career is changing as a developer and you need to take advantage of the opportunity to expand yourself and to expand the opportunities of your company.

With that, I want to spend a few moment now doing 2 things. Number 1 I’m going to explain the 2 app models that you have available to you, SharePoint-hosted versus provider-hosted. I’m going to try to give a little primmer on what each one of them represents because, while I’m sure some of you know that, a few of you may not yet have that knowledge.

It will not only help you understand your choices, it will also help you understand why we’ve drawn some of the conclusions that we’ve drawn about which ones you might want to use. Let’s start with the SharePoint-hosted app model. Before I even get into any bullet points, one sees the name SharePoint-hosted and you think, “Okay, Well it must be hosted in SharePoint” and with the risk of being over-simplistic, that’s really what it is about.

At some level, the SharePoint-hosted model is desirable because it doesn’t bring any other server elements into play. Whatever it is you’re building, whatever it is you’re doing, ultimately it’s going to get deployed to SharePoint and then it’s going to run in some fashion.

What is it that you’re going to be writing when you write a SharePoint-hosted app? You’re really going to be writing client-side or browser-based technologies. You’re going to be writing Markup, you’re going to be writing JavaScript. You’re not really going to be doing anything with the server side code.

Now, giving JavaScript the credit that it is due, it has certainly evolved in some amazing ways over the past few years. There are a lot of innovative thing that you can do with it. I think what you’re going to find, as we go through this little journey, is that having the browser as your exclusive runtime engine and JavaScript as the language within that is going to pose some limitations that we may or may not be happy with. More to come on that as we go along.

Another thing to think about when you write a SharePoint-hosted app model, the presumption in almost all cases is that if you’re writing a SharePoint app, you’re writing it to manipulate list or libraries. It could be that you’ve built an app where you’re trying to track invoices or expenses or maybe even resumes. Generally it’s a combination of SharePoint building blocks such as lists and workflows and libraries. Then your code is acting as an integrating agent around that.

Given that, the way you’re going to do customizations now are a bit different. When we build an app we really have 2 websites that come into play. The first is called the host web. That is the site that is actually hosting the application. Then we have the app web, and for lack of a better way of explaining it, you can really think about the app web as being a special kind of sub-web or sub-site that lives under the host web.

Even if you say, “We’re using SharePoint- hosted, and we know what we’re getting into”, you still have to make a choice about where you’re going to store your data, either in the app web or in the host web. Let’s talk a little bit about what those choices are and why you might choose one over the other.

The first opportunity, or the first alternative that I would put out there is storing your lists in the host web. You can almost think about your app web is running and it’s calling up to the website that’s holding the data, and it’s going to interact with it there.

There are some distinct challenges in that approach. One of the first one is that you cannot declaratively create your lists. Excuse me. Those of you that are used to writing camel for provisioning a list, be it a task list, or an announcement list, or some kind of custom type, you literally can’t do that in this case.

Then how are those dependent lists going to get created? Essentially you have 1 of 2 choices. You can programmatically create them, although that’s going to be very difficult, and the reason it’s going to be difficult, when you think about it, a natural place to allocate a list would be when your app gets installed.

Unfortunately, SharePoint-hosted apps do not have an event handler that fires when your app gets installed, and the reason for that is you don’t have any server code. In effect, if you were going to programmatically create those lists in the host web, what you’d have to do is every time your app landed on its homepage, you’d have to do a quick check to see if they were there. If they weren’t there, creating them on the fly.

There’s a lot of entanglements with that, not the least of which the user that’s doing this action, probably doesn’t have that level of permission in the host web. Bottom line is you’re not going to be able to easily, programmatically create them.

What was the second option? The second option is you just go in and manually create them. I can tell you that on the app I’m going to demonstrate for you today, that’s precisely what we had to do. We have a little readme that says, “When you install this app, you’ve got to go up to the host web, you’ve got to create a list, and it’s got to look just like this.

That’s kind of a kludgy, sort of duct taped way to do it, but it really is your only other alternative. Another big challenge for storing the lists in the host web, and that is, by definition, if the users have permissions to interact with that list, then they’re going to be able to actually navigate to that list in the UI and manipulate it.

You think about your app assuming certain dependencies on how data gets manipulated and updated. It’s entirely possible for the user to circumvent that, navigate directly into the list and change it accordingly. Imagine, if you will, writing an app where you have a database and the database is surfaced to the user so that they can interact with it directly and bypass your app.

That’s essentially what we’re saying here. Yes, there are some UI tricks that you can do to kind of partially hide those, but in the end you’re just running this risk that the users would change the data in such a way that would be inconsistent or confusing to your application.

Your other alternative is to store the lists in the app web and, in fact, a lot of what comes out of Microsoft, in terms of sample code and so on, kind of presumes that this is what you’re going to do. On the strong side of this, it has a declarative creation model. You can write camel just like you did in the past, and you can allocate those lists as the app is being installed.

There’s not any kind of contingency code that you have to write to create the list. You don’t have to manually do anything. You just deploy the app and the lists get created and everybody’s happy. That is a huge upside. Not only that, it’s very difficult for a user to interactively navigate to such a list and manipulate it.

I don’t want to say impossible, because there are trap doors they can slip through, but by and large it’s much less likely that a user would directly manipulate a list that had been stored in the app web. That’s a big positive.

On the negative side, well there’s a couple of big negatives. Probably the biggest one that we’ve encountered in some of our experiments, there is no security model. This concept that you’re used to in SharePoint of being able to create groups and add users to those groups and then grant permissions in such a way so that certain groups may or may not get to a list, that’s not even possible in an app web.

By definition, if a user installs an app, then they’re going to have access to all the lists in that app. There’s really nothing that you can do about that. Here’s another big one. If you store the data in the app web, when you remove the apps and one decided to uninstall it, that’s it. The data is gone. You’ve lost that data, and if you “reinstall” the app, you’re kind of starting over fresh.

We can say that’s an implied positive of putting your list in the host web. At some level if you delete the app, the data is still available in the host. You would have the burden of perhaps going and cleaning that up at some point in the future, but at least of somebody kind of trivially deleted an app, they wouldn’t wind up nuking all your data.

That’s a lot of verbiage. Let’s see if we can do this in picture form. Some of you probably do a little better with pictures. You can see the outer gray block there that represents SharePoint. In this discussion, this could be an on-premises SharePoint farm that’s running in your company, or it could be SharePoint online by an Office 365.

What you see here are a couple of moving parts. First of all, within the form itself, we have the host web where the app got installed, and then underneath that the app web where the code would actually be interacting with. Then you’ll notice from the dashed arrows that are moving right to left, that essentially my app can interact both with artifacts in the app web, and artifacts in the host web via the API into the app web.

The one thing that we have to be aware of on that application programming interface, is that getting the things in the app web is incredibly easy and straight forward. Getting things in the host web is a bit more complicated. If you’re familiar with the concept of cross-site scripting and being able to call from one domain to another, you probably already know what I’m hinting at. If not, just understand that it’s not as easy as just dialing up a URL and calling into that host web.

We have some plumbing that we have to go through and that plumbing is pretty particular and sometimes brittle. We actually have some real world experience where Microsoft made a change to that plumbing unannounced and it actually introduced a bug into one of our applications.

Now, notice over to the right, the little white block. All of your code is running in the browser. To put it another way, your browser is your runtime engine. Any logic, any [inaudible 00:21:03] manipulation is all going to happen there, and then as you need to retrieve and store data, you’re essentially going to be calling back into your app web’s API and then doing whatever manipulations you need to make.

What’s good and bad about this in kind of a diagram fashion, well one thing that’s good about this model is that unlike what we used to do in SharePoint 2010, this is, in fact, Cloud friendly. When you write an app using the SharePoint-hosted app model, you can deploy both to a local farm and to SharePoint online.

We also have this benefit that is it SharePoint only, so there’s no other dependencies, there’s no other servers that we have to worry about. You just take your artifacts, you deploy them to SharePoint and your job is done. Certainly, from an administrative, a production support point of view, it’s a very simple, very easy deployment model and a lot of people are going to like that.

Another thing that there is to like about this model, if you notice our little symbol there at the bottom, we’re not stuck in the Platypus programming model. We’re riding client-side technologies, so we can take advantage of all of the latest JavaScript libraries. Assuming that the browser supports it, we can HTML 5. We have lots of very, very interesting things that we can do there.

While it does have some problems that we’re going to have to deal with, on the user experience side, a SharePoint-hosted app model has a lot of opportunity to really bring us up to 2014 in terms of what our users expect in the user interface.

There has to be some negatives, and I think I’ve outlined many of these. Number 1, there’s no middle tier so whatever kind of logic you’re used to running at the server that you want to hide from prying eyes, you can’t really do that here.

Yes, I know there are tools out there that will midify and obfuscate your code, but in the end, your intellectual property’s being pushed out to the browser. There are stubborn people out there who can ultimately figure out how to get that code and maybe even co-opt it for their own purposes.

To me, particularly from a revenue point of view, if you’re in the role of an application developer that sells software commercially, that’s kind of a non-starter. This whole notion that your intellectual property’s just out there and available.

Some other things, just the integration that we have here is pretty brittle. I gave you an example of that where Microsoft made a trivial change on their side, and all of a sudden your code is broken. Because you’re really beholden completely to SharePoint for everything you do, you’re really sort of at the mercy of SharePoint when it comes to your integration.

Data limitations come in several forms. The obvious of which is the discussion we had about lists and where you’re going to store data. Not only do you have those issues, you have already well-known issues about SharePoint in terms of large lists and how many thousands of rows you can practically store before you begin to get problems.

Then one here at the bottom that is worth noting. As excited as we might be about these new client-side technologies, unless you’ve got a staff of developers that have already been doing this kind of work, in the short term there’s going to be some kind of reduced developer productivity. They’re going to have to learn JavaScript, they’re going to have to learn one or more fairly large libraries. They’re also going to have to get used to the daily cycle of code, debug, code, debug, using perhaps a new set of tools.

These are all kind of things you need to think about when it comes to using this model. I’ve kind of been hinting at some kind of show-stopper here that would make me say, “Wow, I never want to use that model” so that’s what I’d like to show you now. I want to take a quick look at an app that is using the SharePoint-hosted model and hopefully kind of demonstrate why that might be problematic for us.

What you’re looking at on the screen here is running in Office 365. It is a teen site, and prior to our getting together I went in and installed a sample app that we’ve written here in our company called the Absence and Vacation Management app.

You can see I’m logged in as a fictitious user named Alex Darrow, and in this case, Alex is just a member of this site. He does not have an administrative role. I’ll go and click on the Absence and Vacation app. You’ll see as I go along here that there are really 2 views to this app. One view is for a normal user.

For that user they can go in and look at the calendar requests. They can go look at our policies for absence and vacation, and then they can check on the status of their pending or approved requests.

Let’s say in the case of Alex, he decides he wants to submit a new request. He’s going to take a vacation some time this fall with his family. He’ll go out and pick some dates here, and again the dates are insignificant, we just need to have some sample data. He wants to have a getaway, so that’s really nice.

We’re going to click ‘save’ and then at some level now, Alex has submitted a request and it’ll be up to a manager to come along and actually approve or reject that request. The way that we handle security here, remember we have no security inside of the app web, so what we’ve done is actually created a group in the host web and used that to monitor security, and then in our code, we just check the current user to see if they belong to the manager’s group or not.

Here’s what I’m going to do, and this is not all that far-fetched. I’m going to go up here and open my developer tools, and then I’m going to go into a file called ‘app.js’. For this example, this is where my application logic lives, and you can see I’ve got a break point in here that is set at the end of the logic where we check to see if this person is a manager.

Essentially what we’re doing is looking up on this ABR manager’s group to see if they are or are not in there. You’ll notice I’ve set a break point on it. What I’ll do now is refresh the page and then once my break point triggers, I’m going to float my mouse over it, I’m going to go down to the little pop-up window and double click on the word ‘faults’, and I’m going to change it to ‘true’.

This is all happening in the browser. It’s not like I’m some super administrator or anything. I just basically sniffed out where I needed to change the value of a variable, and now if I click ‘continue’, look at my user interface. Now Alex is a manager, and in fact, now Alex can go over to the manager’s page and look at all of the different things that are going on here.

He’s not even supposed to be able to see this. Not only that, he can now go to the request page and he can approve his own request. By simply changing the value in a [inaudible 00:28:08], we totally changed the security profile of how this app is behaving.

That kind of reinforces what we’ve already talked about. Your logic is out there, and it’s not like somebody has to steal it, and modify it, and post it back to the server, they can manipulate that logic in real time using the debugging tools that are built into pretty much every modern browser.

When you see a demo like that, at least when I see it, here’s the first thing I ask, “Why on earth would I ever want to use that model?” I don’t want to just say that you would never use the model, but I think that it is a very narrowly defined set of circumstances under which you would use it.

One reason that you would use it, whatever it is you are trying to accomplish, it’s all related to the user experience. You’re just trying to make it easier for a user to do something that they could do with a standard UI. Let me give you a perfect example. For the projects that we run here at ThreeWill, we actually keep all of our project-related data inside of a SharePoint site. Makes sense, we’re a SharePoint company, but there is a thing that a developer has to do to map out their tasks and their time that requires them to simultaneously update 3 or 4 lists.

Under our old model, that was a pretty laborious thing to do. In fact, it was funny, you could almost figure out when someone was doing it by walking by their desk, and you would see that they would have 3 tabs open on their browser to 3 different lists on the same site, and they’re switching back and forth and copying and pasting.

Instead what we did is wrote a SharePoint … Excuse me. … a SharePoint-hosted app that allows us to go to one page to see all those lists and to manipulate them simultaneously. We’re not trying to impose any app logic, we’re not trying to do any crazy calculation, we’re just making it easier for someone to accomplish a task.

Obviously, in that case, there isn’t any logic, it’s just UI manipulation so we don’t have to worry about someone “stealing’ it. Again, there’s not a security element here. We’re just trying to make the UI easier to use. Our data needs are pretty simple. Everything that we’re doing are stored in lists that are in the host web. If the developer wanted to, they could navigate directly to that list and manipulate it directly.

They just use the app as an easier way to accomplish that. All right, so now that we’ve taken our tour of SharePoint-hosted apps, lets begin looking at provider-hosted apps. What is the biggest or most profound difference between the 2 models? When you build a provider-hosted app, it is a mix of both server side and browser based logic.

What we really hope that we get there is the best of both worlds. Things that should belong in a server code that needs to perform well, that has higher security requirements, that has high availability requirements, great. We can write all of that as server logic and we can write it in a set of tools that are probably more familiar to us.

Then for the things that should be in the browser, markup and user interface manipulation, great. We can still take advantage of all of the crunchy goodness of the latest that JavaScript and other browser-based technologies have to offer. Here’s another thing about provider-hosted apps that doesn’t necessarily shine through initially, but the more you think about it, the more opportunity you see.

That is, when we talked about where you store your data, in a provider-hosted app, you can store it in the host web, you could store it in the app web, or you could store it in any data storage engine that you like. It almost changes your perspective of a SharePoint app where instead of being in this world where SharePoint is the center of the universe and you can’t really reach anything outside of it, now you’ve got an app that could be consuming resources from a database server in your company, from Azure in the Cloud, and at the same time consuming SharePoint as though it is a service.

That’s a pretty radical thing because some of our traditional SharePoint barriers around data capacity, number of items in a list, now if I know that I’m going to have some things that are trivial and some things that are going to be very large, I can put those very large things in another data storage engine but still consume the things that I like about SharePoint.

Another thing that is truly important about provider-hosted apps and that is better event model. In particular, there are a lot of legitimate things that you might programmatically need to do when your app is installed or uninstalled. The most obvious example is the little example I talked about a moment ago where I needed to have a list in my host web that hosted information about my managers.

If I’m writing a provider-hosted app, when the app gets installed, I can programmatically allocate that list and even populate it with data. Conversely, if I want to do a full cleanup, when my app is uninstalled, I can reach up into the host web and delete that data.

I could also do that with any other data storage engine. SQL Server, whatever it might be. There are other events that you are going to hear about, but the fact that you have an app installed and uninstalled event on a provider-hosted app, and you don’t have that on a SharePoint-hosted app, that’s a pretty important point.

Then looking a little more at storing data in a provider-hosted app. As before, we can store our lists in the host web, and as I kind of hinted at a moment ago, the one big difference here is just now that we can programmatically create those and clean those up based on app events. Otherwise, you’ve got essentially the same pros and cons that you had before.

Likewise, you can store your lists in an app web and the experience there is the same. You can declaratively create them. They do not have any security associated with them, and when you delete the app, they go away. Then, this third option, and I’m going to tell you for some of our customers, it’s kind of becoming the first option, and that is we really want to store our data somewhere else. Imagine as an example, you wrote an application that had to track an enormous amount of employee data and as [inaudible 00:34:39] it also needed to track some documents for those data.

It’s really easy to see a model where you would put your verbose employee data in a SQL server database, but then store the supporting documentation in Sheer Point and take advantage of libraries and workflows and all of the things that go around that.

If you’re used to working in this box of a Sheer Point developer, now that world’s kind of opened up, and you’re writing applications now and those applications launch from Sheer Point and use Sheer Point, but they’re not really limited to Sheer Point in their scope.

Once again, for those of you that kind of prefer the picture view as opposed to the written word, what you see here now is the provider-hosted model. If you look to the far left of the diagram, in the gray box, once again, we’re talking about SharePoint. Once again we’re talking about being on premises-friendly, as well as, Office 365 friendly.

In this case, you still have the host web, you still have the app web. What’s probably different here is that you may have little or nothing in the app web. It may just be a toe-hold that lets you get in to SharePoint and launch the app. Then if you look to the right, the next diagram, the one that says, “Provider”, essentially this is the provider-hosted portion of your app.

To put it another way, this is the server logic that’s going to carry out your business plan. It’s going to read and write data from SQL databases or ques or any other storage mechanism. Then it’s going to deliver the client-side payload out to the browser that allows the user to interact with the app.

In effect, your user gets a set of markup, the begin to interact with it. The browser is then making calls to your provider-hosted app and it, on behalf of  the user and the app will consume resources either inside of SharePoint, or any other storage engine that we like.

There’s really not much that’s out of bounds here. Virtually everything that one would have available to them in SharePoint, can be programmatically manipulated in this way. One other thing that I want to point out, and this is a pretty important one. If you notice inside of the provider app block, there’s a little bullet point there that says, CSOM, Client Side Object Model is what that stands for.

What you need to understand is that when we write our apps this way, the programming model that we use is a little richer, and has more capabilities when it’s running in the serve as C-sharp as opposed to the version of this that runs in the browser as JavaScript.

To put that in simpler English, there are things that you can easily accomplish in C-sharp, in this context, that you just couldn’t as easily accomplish using JavaScript in our previous model. In terms of the volume of change, this diagram is accurate, but I’m not sure it conveys the message fully of just wow, all of these doors that used to be closed to us are now open.

Again, if we kind of look at our pros and cons here, there’s a lot to like here. We have a full middle tier, and all of the things that we might need out of that, data storage and retrieval, security, transactionality, all of that.

Because we can take advantage of all of the latest browser technologies, we can use the best that the web has to offer. We can also use the best that Microsoft has to offer. Again, DotNet has gone through several significant releases and added some great capabilities over the last 13 years. Now as SharePoint developers, we can take advantage of all of that.

Another thing that we have here, when it comes to our provider-hosted web and the corresponding services, we can have all of the performance controls that we want. Whatever metering and so on. We wouldn’t have those things in kind of SharePoint. We have design choices about what sort of patterns we want to use, such as MVC.

Other things about that, we have revenue options. Again, if I’m building an app and trying to sell it, I don’t want to push my intellectual property out to a browser so that anyone in the world can see it. In this model, it’s compiled and it’s behind a safe wall and I don’t have to worry about it.

Another thing at the bottom, and I think this is another huge one, because of the tools and techniques that we’re using in this model, we have a much better support for an application lifetime lifecycle management. Doing that in JavaScript is really hard, but having a full-fledged ALM for build management, for repeatable testing, for predictable deployment. It’s more like a “real software app” where you have known, repeatable procedures for carrying out those kinds of things.

I wouldn’t be honest if I didn’t put out some kind of con. I do have to acknowledge that, once again, there is going to be a learning curve for your developers. The best circumstance is that in addition to being Sheer Point developers, your developers have already worked a lot with DotNet, and browser-based technologies, and they’re kind of up on the current state of web programming. Again, the good news is that if they’re not, for those that already know how to program Sheer Point, a lot of what they’re going to know is translatable.

For those that don’t know how to program Sheer Point, they can bring other skills that they do have on the Microsoft and the WebStack and easily add the Sheer Point capabilities. It’s a little bit of short-term pain, but it’s some gain in the long term.

Let me quickly show you a provider-hosted app in action. I’ve navigated to a different site now. This is the demo app that was built to back up what we did for Sheer Point Saturday, the original presentation of this information. Some things that you’ll want to note. First up, you can see over here in my recent list, that there are actually some lists in this particular site. This is an example of storing data in this host web. In fact, those lists got created when the app got installed.

It actually had the logic inside to say, “Okay, this list don’t exist, let me go out and create them in a certain fashion.’ Then once it’s created those lists, if I click on the link that takes me to the actual demonstration application, it’s not any different that what we would have experienced with a Sheer Point-hosted app.

You still have full control of the UI. You still have the ability to take advantage of whatever JavaScript libraries you’d like. You still have the ability to have a completely responsive app that will scale from the size of a handheld device all the way up to a full browser window.

Not only that, whatever tricks I might do about switching myself from being a manager to being a non-manager back and forth, none of that is going to happen here. If I were to fire up the debugger, I might be able to inject some kind of weird data into the  stream, but ultimately I’m going to have hardened logic back at the server that’s going to kick out anything that doesn’t make total sense.

It really is the best of both worlds. Here’s the thing that you’ve got to notice. When we were on the Sheer Point site, you can see this URL that I’m at,, but when I go into the app, I’ve now navigated to a completely different place.

Really what’s happening here is we just had a toehold in SharePoint that allowed us to navigate here. Once we get here, we’re really running the web app in the context of a completely different server, and then our server logic is just making calls into SharePoint on our behalf. Again, it’s a new world, and it’s going to take some learning, but I think what you see is that this is the sweet spot where you get the best balance of risk and reward. Instead of saying, “Why would anyone use this?” I’ll just put it bluntly. Why you want to use this. Why you would use this.

Number 1. You’ve got logic beyond just doing user interface manipulation. You need to write a “real app” that can do real things. You need logic that’s safe, and private, and can’t be stolen, and can’t be manipulated. You need app-specific security. In the example that I just showed you, all of those libraries, all those lists that are in the host web, are secured using the exact same mechanism that we’ve already used.

I don’t have to roll my own and come up with this totally new way of doing things. From the app, it’s not going to let a user manipulate a list if that user doesn’t have permissions to the list. Not only that, in the rare case where I need an app to be able to do something on behalf of the user, where the user doesn’t already have permissions, we have these things called app-specific permissions. Again, it is the absolute best when it comes to not having to roll your own security mechanism.

You have complex data needs, you have app-specific data needs, you need to be able to integrate with other data sources. This is just going to give you a lot more options than what you would have in a SharePoint-hosted and certainly, more than we had in our traditional farm solution.

Availability requirements. Essentially, you’re going to be limited only in the reliability of the server you deploy to. If you’ve got to have strict uptime requirements, you can pay the extra money to deploy that into a high availability environment. Either one that you’ve set up yourself, or one that you’re purchasing from a third party.

Then being able to leverage server-side code, I will admit, I definitely have a bias toward server-side code. It’s just what I have the most experience with and what I feel more comfortable with. Regardless of ones biases, the truth is there are certain kinds of things that should be done at the server, particularly things that are processor-intensive, things that need to be shared across many different users.

Then you need a runtime engine that’s bigger than the browser. That is definitely a reason that you would use the provider-hosted model. We talked about data capacity not being limited by the arbitrary number of rows that one can put in SharePoint. If you’re really talking about needing to manipulate 30 million rows, there are other data storage engines that are going to do a lot better at that.

Just as kind of a fly-by here, I’ve put together this app model scorecard based on some data from Shawn. The numbers here are somewhat subjective, I will admit that, but there are some trends that you would want to spot. Number 1, don’t forget that farm solutions haven’t gone away. If you are an old time SharePoint developer, and you’re used to writing those, at least for the short-term, you can still write them, and you can still take advantage of everything that you ever did there.

The problem there is really kind of two-fold. Number 1, that means no Cloud support, it’s on premises only. Number 2, I think Microsoft has kind of shown their intention that while they’ve not announced a date that farm solutions will go away, it’s obvious that their lifetime is not infinite.

There’s going to come a point where there’ll be little or not support for those anymore, if you read the tea leaves. Some other trends to point out here, if you go to SharePoint or provider-hosted, there’s a learning curve.

Say that the provider-hosted model has a better learning curve only because some of the server logic you used to write as a farm solution programmer, is going to look very similar, in terms of server logic for provider-hosted.

If you’re not a JavaScript UI master, then you’re going to have some things to learn there. Then, really the biggest deal-breaker or show-stopper, the SharePoint-hosted environment is impossible to secure in a meaningful way. You really have to be talking about the kind of app where you’re not trying to enforce security on users, you’re just trying to give them a more convenient way to manipulate data via the web browser.

Let’s look at some conclusions here, and then I’ll send you on your way for the day. One thing you’ve got to do if you’re a developer, you’ve got to embrace change. Even the most open-minded among us can feel a little bit intimidated when we find that all of a sudden things are changing. I honestly believe this, and I’ve been coding now for almost 30 years. This is a positive change. There are so many things that we could now do with SharePoint and integrating it with other apps that just really wasn’t practical given the models that we used to use.

Another thing that you’ve got to do if you’re a developer, not only do you have to embrace the change, but you’ve got some specific things that you need to work on. If you’re not already comfortable with JavaScript, you need to learn JavaScript. You need to work on that right now.

You also, once you begin to learn JavaScript, need to pick some of the more common libraries out there, and begin to familiarize yourself with them. There’s way too many for me to mention, but pick one. Even if you don’t wind up using that one, just the experience working with it will teach you some patterns about how things are done in JavaScript.

I know for us here at ThreeWill, we’ve looked at Knockout, we’ve looked at Angular, we’ve looked at a lot of different things. That’s a journey that you want to begin. Another thing that I didn’t specifically show or talk about in the webinar, but you need to begin to learn about it as a developer, and that is [inaudible 00:48:15]. Think about how I jumped from server to server a moment ago and I did that seamlessly with one identity. Being able to authenticate, and authorize, and identify users, [inaudible 00:48:29] is the way that’s going to happen. While that is a non-trivial topic, it’s something that you’re going to want to have in your tool belt.

If we’re going to use SharePoint-hosted at all, we’re really only going to use it for UI convenience. Not only that, there’s going to be a user-education portion that goes along with that, where we have to train our users and say, “Look, I’ve built this thing for you, but if you circumvent it, and manipulate the data directly, then it’s going to cause problems.”

Then finally, if you’re building “real industrial strength” apps then provider-hosted is the model you want to go. You might build a provider-hosted model that exclusively stores and retrieves data in SharePoint and takes advantage of all SharePoint capabilities, or you may build a provider-hosted app that consumes some services from SharePoint and stores and retrieves or ques data in other mechanisms. Really, you’re only limited by the true need of your application, your imagination, and your skill set when it comes to writing those kinds of applications.

All right, so I want to thank you for giving me the better part of an hour to talk to you today. As always, when it comes to our webinars, I encourage you to ask questions now, and I can respond to those if they show in the question window. If not, again, you see my email address there. I’m more than happy to have you ask me a question after the fact. Also remember that, within a day or two, we’ll have the recording of this up on so, of course, you can send that link to friends and co-workers and let them know about this.

read more
John UnderwoodChoosing a SharePoint 2013 App Architecture Webinar

SharePoint 2013 App Models Considered – Part 3

Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.

In the first post of this series I introduced some high-level considerations about the new SharePoint 2013 app model. In the second post I offered my thoughts on App Web Apps based on my experience, and introduced the instructive but flawed Absence & Vacation Request app. In this post I’ll consider another SharePoint-Hosted App variation: the Host Web App.

As before I’ve tried to cut this into manageable chunks for easy digestion:

  1. Host Web Apps (vs App Web Apps)
  2. Today’s Real World Sample App
  3. Code Release Disclaimer
  4. What’s Good About Host Web Apps
  5. What’s Bad About Host Web Apps
  6. Where Host Web Apps Fit
  7. Pro Tips for Host Web Apps
  8. Notes

Host Web Apps (vs App Web Apps)
Host Web Apps share many similarities with App Web Apps. You can find a quick rundown of the structure of App Web Apps in my previous post. Before we get to a structural comparison, I need to point out the fundamental difference between the two: application permissions.

At install, every SharePoint-Hosted app presents a permission demand to the installer. Even App Web Apps, which don’t require any explicit programatic permissions to the Host Web, do require implicit permissions to access “basic information” from the Host Web. This covers things like read access to the Host Web’s site title and the names, IDs, and email addresses of the site users. Host Web Apps, by design/definition need broader explicit programmatic access to the Host Web. What they need and ask for varies by app, and can range from read-only access for a particular list to full administrative control of the SharePoint farm or tenancy (!!!). Compare the permission demand for the Absence & Vacation Request app to a demo app I created that maxes out the standard SharePoint permissions:


This should give you an idea of both how much control a Host Web App *could* have, and what the permission demand looks like on both ends of the spectrum. I think it’s safe to say that most people are going to have a stronger emotional response reading the permission demand for the second app than for the first.

Now let’s look at what these broader permissions mean for the structure of a Host Web App. Here’s a side-by-side block diagram comparison for both:


The differences are focused, but significant. I’ve tagged the top 3 in the Host Web App diagram:

  1. While Host Web Apps technically *can* deploy some SharePoint schema objects declaratively into the App Web, by definition they won’t, or if they do it will be a limited set. This is the defining factor for Host Web Apps: they are intended to work predominantly with objects in the Host Web.
  2. The application code–still 100% JavaScript running in the users’ browsers—makes API calls to the App Web, but they execute via an intermediary JavaScript class called SP.RequestExecutor. The SP.RequestExecutor’s “service”1 (on the SharePoint server) routes requests to the Host site. Intermediating the API calls serves a couple of purposes:
    1. The app web and host web are in sibling domains, so this solves the cross-domain scripting issue.
    2. The app’s permissions are checked here to make sure the REST or JSOM requests don’t exceed it’s permissions.
  3. While declarative deployments (via CAML) to the Host Web are still limited to App Parts and Custom Actions, a clever application *could* deploy or modify schema objects in the Host Web, Site Collection, or for the Farm or tenancy so long as it is granted sufficient permissions.

The structure of Host Web Apps is more complicated than App Web Apps due to their need to manage permissions and API calls across the domain boundary between the App Web and the Host Web. In the big scheme of web apps, it’s still relatively simple on paper. In practice, crossing that domain boundary solves several problems, but introduces a few more.

Today’s Real World Sample App: ThreeWill’s Task & Time Entry App
ThreeWill recently moved our internally hosted project Extranet from an on-premises SharePoint 2010 farm to Office 365. In the process we identified some user stories that would really benefit from customizing the OotB SharePoint experience. These mainly covered tasks that required managing and entering data across multiple SharePoint lists:

  1. As a project team member, I want to be able to create sprint tasks for the stories assigned to me in a given sprint
  2. As a project team member, I want to be able to track time worked and time remaining for my tasks in a given sprint
  3. As a project manager, I want to be able to view progress for all tasks and all team members in a given sprint.

From a SharePoint standpoint, these stories all require information from at least four different lists: Sprints, Product Backlog, Sprint Backlog, and Sprint Task Times. Even with lookup columns, referencing data from two lists in order to create and update data in two other lists is not something SharePoint does well out of the box. So we created a Host Web App that provides an SPA solution that covers these stories.

Here’s a screenshot of the application followed by a few notes:

ThreeWill's Task & Time Entry application

ThreeWill’s Task & Time Entry application

Each control in the application is populated by data from the Host Web, most of it from SharePoint lists. The two grids on the right also allow creating, editing, and deleting list items. The Task & Time Entry app is not much more than a mash-up of data from the Host Web that extends SharePoint to give the stories mentioned above a user experience that SharePoint doesn’t handle well OotB. As I suggested in the Where-They-Fit Checklist in my previous post, this is the sweet spot for App Web Apps, and I think the same holds for Host Web Apps.

Code Release Disclaimer
Unlike the Absence & Vacation Request app, which was written as a technology demonstration for the community, the Task & Time Entry app was written for ThreeWill’s internal use, so I can’t share the full codebase with you. However, I do have a number of concept demonstrations from the app that I can share. I expect those to show up in future blogs, but if you have specific topics you’d like to see the code for, just ping me in the comments or tweet at me (@seansageek), and I’ll get you as much as I can ASAP.

What’s Good Now?
Most of the good things App Web Apps bought us are in still in full force for Host Web Apps, so I won’t rehash them here. In addition, Host Web Apps solve a couple of problems I had with App Web Apps:

  1. No Data Silo. Now the underlying objects your app is working with live in the Host Web. The Original Web. The *Main* Web. Full access to the SharePoint collaboration toolset has been restored, and your app can be deleted independently of the data.
  2. Improved *Data* Security. Your security scheme isn’t flat, full-control for everyone. Any SharePoint lists your app uses (or creates) can have all the granular security control that we’re used to, and it’s managed from the Host Web in the same ways we’re used to.

What’s Bad Now?
I could *almost* be a fan of Host Web Apps…if the differences stopped there. Unfortunately, moving the app data to the Host Web introduces some fresh issues:

  1. Poor Schema Control Options. As I pointed out in my block diagram, there’s no declarative way to manage schema objects in the Host Web. There’s also no “install event” for hooking in programmatic schema changes. The only way Host Web Apps can directly manage objects (lists, fields, security groups, etc.) is via JavaScript executed somewhere in the app’s runtime. That means you’ve got to do something like one of the following:
    1. Create some clever (read: difficult to write and maintain) sync logic. This would periodically monitor the Host Web and apply schema and security changes *automagically* behind the scenes. Within the context of a user running the application. And oh, by the way, that user also needs to just happen to have sufficient permissions to perform that activity.
    2. Create a dedicated admin user experience in the app. This would allow site admins to run setup and/or periodic synchronization logic. Just keep your fingers crossed that they remember to do it when they’re supposed to.
    3. Manage schema changes out-of-band. This is the route we chose. The Task & Time Entry app is only supported for sites that were created using a specific template. This means we have to make sure the app logic and site template stay in sync, and educate users not to make breaking changes to the lists the app needs.
  2. Reduced Host Security. Recall (or review) the permission demand comparison above. The worst an App Web App can do in the hands of a site admin who’s careless or using a compromised browser is shoot itself in the foot or perhaps leak the site title and site user’s names and emails to evildoers. That’s not great, but the damage is largely contained within the app itself. Not so for the Host Web App. A maliciously written or compromised (read: hacked) app could delete all your site collections or syphon off data or both. A prudent admin will investigate all Host Web Apps thoroughly *before* they touch the App Catalog.
  3. More Fragile Integration. This was the biggest source of disappointment in my Host Web App experience. Allow me to demonstrate the most egregious (of several) scars in the code:
    class SPListExecutor
      constructor: (@options) -&amp;amp;amp;amp;amp;amp;amp;gt;
        @listName = @options.listName
        @appUrl = window.location.getVar(&amp;amp;amp;amp;amp;amp;quot;SPAppWebUrl&amp;amp;amp;amp;amp;amp;quot;) or &amp;amp;amp;amp;amp;amp;quot;local://appweb.local&amp;amp;amp;amp;amp;amp;quot;
        @hostUrl = window.location.getVar(&amp;amp;amp;amp;amp;amp;quot;SPHostUrl&amp;amp;amp;amp;amp;amp;quot;) or &amp;amp;amp;amp;amp;amp;quot;local://hostweb.local&amp;amp;amp;amp;amp;amp;quot;
        if @appUrl.indexOf(&amp;amp;amp;amp;amp;amp;quot;#&amp;amp;amp;amp;amp;amp;quot;) &amp;amp;amp;amp;amp;amp;amp;gt; 1 then @appUrl = @appUrl.split(&amp;amp;amp;amp;amp;amp;quot;#&amp;amp;amp;amp;amp;amp;quot;)[0]
        if @hostUrl.indexOf(&amp;amp;amp;amp;amp;amp;quot;#&amp;amp;amp;amp;amp;amp;quot;) &amp;amp;amp;amp;amp;amp;amp;gt; 1 then @hostUrl = @hostUrl.split(&amp;amp;amp;amp;amp;amp;quot;#&amp;amp;amp;amp;amp;amp;quot;)[0]
        @odataUrl = &amp;amp;amp;amp;amp;amp;quot;[email protected]}/_api/SP.AppContextSite(@target)/web/lists/getbytitle([email protected]}')/&amp;amp;amp;amp;amp;amp;quot;
        @executor = new SP.RequestExecutor @appUrl.toLowerCase()

    Here’s the constructor for the SPListExecutor class in the Task & Time Entry app. If it looks disorienting, that’s probably because it’s in CoffeeScript. If you’re not familiar, just try to roll with it for now. I want to point out line 10, where the SP.RequestExecutor (remember him?) gets instantiated. Notice the “.toLowerCase()” call on the URL? That wasn’t always there. The app worked fine without it for months, but in late February *everything* in the app stopped working. After 9 days of working with Office 365 support, they finally recommended lowercasing the URL. And it worked.

    To say this another way:

    This app experienced 9 days of downtime due to a breaking change in the SP.RequestExecutor API…concerning case-sensitivity in a URL.

    Let me be extra clear: during the downtime, the REST service was working fine. The CSOM API was working fine. But JSOM and REST from the browser were hamstrung because of this error in a JavaScript library and/or the ASPX page that it consumes behind the scenes. Again, this wasn’t the only example of downtime due to fragility on the SharePoint side, just the most frustrating.

    Here’s how I’d summarize these experiences (so far):

    The REST endpoints and CSOM API to Office 365 have proven themselves to be extremely stable; The JavaScript libraries and other artifacts in the SharePoint “UI” have not. And of those, SP.RequestExecutor, has been the most fragile.

    I’m sure this will improve over time, but in the near future I have to caution you to reconsider writing any solution as a SharePoint-Hosted App, and especially as a Host Web App, if the app requires high availability.

Where Host Web Apps Fit
As with the pros and cons, Host Web Apps share most of the recommendation checklist with App Web Apps. Following are the deltas from the previous post:

  1. Are You Okay with A Flat and Open Security Structure? As long as you don’t mind completely piggybacking on the Host Web’s existing security, this issue disappears. If you need something specific to your app, then you’ll need to navigate the “schema control issues” mentioned above.
  2. Are You Okay With Silo-ed Data? Host Web Apps solve this issue convincingly.
  3. Are You Okay With (Extra) Reduced Availability ( 365-specific)? I can’t recommend betting on the availability of any SharePoint-Hosted App, but as covered above, Host Web Apps are even less stable than App Web Apps from my experience.
  4. Are You Okay With Reduced Host Web Security? If you or your organization is writing the app, and you’ve got good security controls in place, then this might be only a minor issue. But if you’re working with external vendors, or your admins spend lot of time on nefarious sites, this might cause more concern.

Pro Tips
Most of the pro tips carry over from App Web Apps post, but let me offer one new and one reiterated tip:

  1. Honor the PoLP. Host Web App permissions are a great time to reacquaint yourself with the Principle of Least Privilege. Your app should ask for the absolute minimum permissions required to perform. If you only need access to one list, use the List scope. If you only need read access, use the Read permission.
  2. Consider ShareCoffee. Again. The ShareCoffee team has covered the ugliness of working with SP.RequestExecutor in a clean, easy-to-use wrapper:
    var executor = new SP.RequestExecutor(ShareCoffee.Commons.getAppWebUrl());
    executor.executeAsync({url:&amp;amp;amp;amp;amp;amp;quot;web/lists?$select=Title,Id&amp;amp;amp;amp;amp;amp;quot;, onSuccess: onListsLoaded, onError: onError}));

    Sure, it’s not as clean as working with a standard REST endpoint, but this is *as clean as it gets*.

Next Up: Provider Hosted Apps
If you’ve read or skimmed this and the previous post—and if I’ve sounded convincing—you might be getting the same vibe from SharePoint-Hosted apps that Gertrude Stein got revisiting her childhood home in Oakland. Luckily there is another 2013 App Model option, one that requires an additional resource, but with significantly more gravitas: Provider-Hosted Apps. Tune in for the next post to find out why I think they’re worth the trouble for the majority of business solutions.

Questions? Comments? Accusations? Leave me a comment or tweet at me (@seansageek). But fair warning: if I smell tar or chicken feathers, I may run.


  1. “Service” is a bit strong: it’s actually an ASPX page.
  2. We use Scrum both internally and externally.
read more
Sean HesterSharePoint 2013 App Models Considered – Part 3

SharePoint 2013 App Models Considered – Part 2

Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.

In my previous post I introduced my series on SharePoint 2013 App Model Considerations, laid out the roadmap and approach for the subsequent posts, and explained why SharePoint has been the platypus of the Microsoft middleware stack. In this post, I’ll review the first App Model option: “App Web” Apps. There’s a lot of content here, so I’ve chunked it up and structured it with lists and bullets to improve skim-ability. If that’s your mindset going in (no judgment), here’s a mini-Table of contents to help you track down the right content:

  1. App Web Apps Overview
  2. Real World App Web Reference App
  3. What’s Good About App Web Apps
  4. What’s Bad About App Web Apps
  5. Where App Web Apps Fit
  6. Pro Tips for App Web Apps
  7. Notes

Running Down App Web Apps
“App Web” Apps isn’t an official Microsoft term, but it’s gaining momentum in the community as a way to describe SharePoint-Hosted Apps (that *is* an official term) that keep their data in the App Web. For the uninitiated, the App Web is a SharePoint Web that is created to host the app when the app is installed in a site collection. It’s a stripped-down SharePoint site that provides provisioning and runtime isolation for the app, and it’s the place where all the app artifacts are deployed except for two minor exceptions. Here’s a quick-n-dirty block diagram of an App Web App package, where its contents are deployed, and where its API calls are routed at runtime:

App Web App Block Diagram

App Web App Block Diagram

  1. The App can deploy several artifact types into the App Web: a reduced subset of CAML for custom SharePoint lists, fields, etc. as well as web artifacts such as HTML or ASPX pages, JavaScript files, and CSS.
  2. The App can deploy a couple of artifact types to the Host Web: App Parts and Custom Actions. As far as I’ve investigated, these are the only two artifact types that can be deployed to the Host Web. That’s an important limitation and distinction between App Web Apps and Host Web Apps.
  3. The App’s logic (JavaScript) interacts with the “local” web domain API (via REST or JSOM) for accessing and creating data, no cross-domain headaches incurred.

This is as simple as it gets for the SharePoint 2013 App Model. Everything deploys and runs in the same domain. The structure of the project looks familiar to what SharePoint developers are used to, minus the server code. The logical structure is basically a fat client architecture in a web browser. Easy peasy lemon squeezey.

“So…About This ‘Real World’ App You Mentioned?”
We re-worked the classic Fab 40 Absence & Vacation Request application as a technology demonstration of a SharePoint-Hosted App. You can see a video demo, get details, and even grab the full code for the app here. But you might want to read the rest of this post before you turn the app loose within your organization. Like its Fab 40 predecessors, it has steep edges and very few handrails. Here are a few screenshots to give you a quick start on the app’s business domain and features:


As you can see, the Absence & Vacation Request application covers a few of the most common use cases an organization might need to track group holidays and individual vacations. Now let’s look at the pros and cons of the architecture.

What’s Good Here?
Despite the gloomy pronouncement about SharePoint-Hosted app variations in my previous post, there are a number of good things happening here:

  1. It’s cloud-friendly. It won’t get much friendlier than this.
  2. It doesn’t require invasive permissions. The logic is self-contained, so SharePoint won’t prompt the site admins for invasive permissions at install time.
  3. It’s simple in several good ways.
    1. The basic CRUD happens with SharePoint’s OotB API.
    2. We’re able to make our magic happen with only one real tier of custom logic.
    3. It happens within one environment (SharePoint), and all in the scope of one web domain (our App Web).
  4. It owns its runtime logic. We have full control of everything between the HTML tags, using only the SharePoint libraries required for JSOM.
  5. It owns its user experience. We crafted a responsive user experience using Bootstrap , and in my opinion, you come out well ahead of SharePoint’s OotB UX. Don’t take my word for it–compare the Absence & Vacation Request calendar home screen to a standard SharePoint 2013 calendar1 for yourself:
  6. Goodbye, Platypus. The custom code may be confined to the presentation tier, but inside that tier you’ve got full control over your technology stack and toolset. And in case you haven’t figured it out yet, getting off the platypus is a high value improvement in my book.

What’s Bad
Unfortunately, the downsides to this approach are serious enough that they severely limit the viability of App Web Apps:

  1. No Middle Tier. It’s kinda like digressing to the client-server anti-pattern…but now you don’t control the server, either.
  2. No Private Logic or Data. If you’ve only ever developed traditional ASP.NET/MVC or SharePoint Farm Solutions, you’ve been “spoiled” by easy access to private logic and data. In App Web App world, you’ve got neither.
  3. Not “Tamper Resistant” (Read: “No Security Story”). As if it weren’t bad enough that you have no private logic, you don’t even have tamper resistant logic. Consider the following chunk of code from the Absence and Vacation Request App:
    function isAVRManager() {
     console.log("checking user's memberships.");
     //var dfd = $.Deferred(function () {
     //iterate through users in groups
     var groupCount = userGroups.get_count();
     var isManager = false;
     //loop through all of this user's groups
     for (var i = 0; i < groupCount; i++) {
     //Check for existence in Managers
     if (userGroups.getItemAtIndex(i).get_title() === 'AVR Managers') {
     isManager = true;
     console.log("User is an AVR Manager.");
     return isManager;

    The isAVRManager() function loops through the current user’s group membership via JSOM, and if they have membership in the AVR Managers group, it returns true. This unlocks all the manager-specific features I pointed out in app’s screenshots above. It’s well meaning enough on paper, but it’s so easy to unravel:

    Absence & Vacation Request - Hacked!

    Absence & Vacation Request – Hacked!

    1. Using Chrome’s Dev Tools anyone can get access to the running source of the application. In this case, all of the application logic runs from the app.js file.
    2. Here’s where the app calls the isAVRManager() function.
    3. Once that line has executed, I drop into the JavaScript console and manually set the isManager variable to true.

    The bottom line: a mildly clever and malicious user can approve their own vacation requests, or anybody else’s, or create holidays. In my book, that’s a HUGE problem.

  4. Fragile Integration. SharePoint has always been a bit of a volatile product to customize. Take that volatility, and move it to javascript running in a user’s browser, and you get the picture.
  5. Reduced Productivity. Writing your *entire* app in JavaScript presents serious productivity challenges for even seasoned JavaScript developers.
  6. Design Limitations. Kiss all your favorite .NET framework libraries and products goodbye.
  7. Silo-ed Data. You’re creating a separate SharePoint web that acts as a container for your entire app, which isolates it in ways the Farm Solutions we’re used to do not.

Where App Web Apps Fit
Given the limitations I’ve experienced working with App Web Apps, I have to recommend treating them with extreme suspicion. Following is a checklist of questions; if you can’t confidently answer “Yes” to each of them, an App Web App is probably not the right choice for you.

  1. Are All Your Use Cases Strictly UX Related? If your app needs to do more than reformat, repurpose, or extend the SharePoint OotB user experience, then an App Web App will be in over its head.
  2. Are You Okay with 100% Code Transparency? If you need privacy for your code for security, intellectual property, or other reasons, this is not the solution architecture you’re looking for.
  3. Are You Okay with a Flat and Open Security Structure? If you have any need to for multiple tiers of user privileges, you can’t get there from here (see my point about tamper resistance above).
  4. Are You Okay With a Simple Data Structure? You’ve got one real data storage option for App Web Apps: the SharePoint lists you provision to the site, and SharePoint lists have important limitations (example: item count).
  5. Are You Okay With Reduced Availability ( 365-specific)? So far this year we’ve experienced 10 days of downtime for apps caused by updates to our * tenant, caused by a combination of changes to SharePoint JavaScript libraries, and the server code that support them. ‘Nuff said.
  6. Are You Okay With Silo-ed Data? If there will *never* be a compelling need for end-user collaboration with your data, you’re golden. From my experience SharePoint users really like the collaboration tools, so I’d be skittish about starting down this path.

Pro Tips
So you’ve read and understood the warnings, you’ve reviewed the checklist above, and you still want to choose an App Web App. If you head down that road, here are a few suggestions that may make life better for you:

  1. Don’t Fake The Funk On A Nasty Dunk.You just read where I think App Web Apps make sense, right? My top tip is to keep your app in that box. Above all else, don’t try to cruft up fake security–it’s bad mojo.
  2. Keep Requirements Manageable. You’re in a reduced-capability environment. Your product requirements need to reflect that, especially early in your release cycle.
  3. Beef Up Your JavaScript Toolkit. JavaScript isn’t the most developer-friendly language, especially if you’re accustomed to compiled languages. Life will be better if your workbench includes tools and process that maximize design-time productivity and minimize reliance on runtime testing. I use and endorse all of the following:
    1. The Super-Amazing-Must-Have Web Essentials extension for Visual Studio
    2. CoffeeScript if you’re JavaScript savvy and like tight, functional logic or…
    3. TypeScript if you’re C#-oriented and crave design-time type checking
    4. JSHint to keep your code squarely in The Good Parts.
  4. Test Locally With Mock Data. If your dev process requires a SharePoint deployment–especially a deployment–to test any changes, you’re doing it WRONG! It will kill your development velocity. At a minimum, grab some sample REST query results and stuff them into a JSON file as mocks for dev and testing.
  5. Use Community Libraries. Don’t re-invent the wheel—this is no time for NIH syndrome. I use and endorse all of the following:
    1. Backbone or Angular. Pick one or the other—they’ll both jumpstart the structure and core service of your app
    2. ShareCoffee for REST and other client API helps. NOTE: ShareCoffee does not require CoffeeScript
    3. Breeze for data access, along with Andrew Connell’s Breeze SharePoint SPA code samples and patterns
    4. Bootstrap to get your CSS rolling quickly
  6. Constrain Your Consumption of SharePoint UX Assets. SharePoint’s REST and C/JSOM endpoints have been up every time I’ve tested, breaking changes to the SP.* libraries have been the largest source of downtime so far.
    1. Determine how you need to call the API–REST, JSOM, or a mix–and get that code stable as early as possible.
    2. Minimize the number of SharePoint JavaScript references. Somewhere between zero and three is the right answer, depending on your answer above.
    3. Keep your API call logic in one place. If possible, have a JavaScript class (or two) dedicated to it.
  7. Familiarize Yourself With SharePoint’s REST API. This is one of those cases where an hour or two of reading will pay off with big dividends. Here are some MSDN resources I recommend:
    1. Apps for SharePoint REST API Reference
    2. How to: Complete basic operations using SharePoint 2013 REST endpoints
    3. Working with lists and list items with REST

Next Up: Host Web Apps
Phew! Did you make it all the way through? If you skimmed through, I hope you found the list structure helpful. If you haven’t had enough abuse yet, in my next post I’ll examine the Host Web App as an architectural option. Spoiler alert: it improves on App Web Apps in one key area, but introduces some new issues. In the meantime, if you have questions or comments about the troubles I’ve seen, the conclusions I’ve drawn, or the code we’ve shared, leave me a comment or tweet at me (@seansageek)–I’d be happy to discuss it with you .

1: The standard SharePoint calendar screenshots are from a standard Calendar App in circa June 2014. The Mobile Browser View feature was enabled.

read more
Sean HesterSharePoint 2013 App Models Considered – Part 2

SharePoint 2013 App Models Considered – Part 1

Sean is a senior consultant at ThreeWill. He has over 16 years of experience developing web applications. His primary passions are in usability, group collaboration, project and process automation, data visualization, and social media tools. He is an MCSD in Web Applications and an MCTS in SharePoint Application Development.

Over the last year, one of the hottest topics of discussion at ThreeWill has been the new SharePoint 2013 App Models; and specifically where each model might make the most sense given a particular solution requirement. Choosing an App Model is a critical decision for your solution, and as I worked with each of them, I hit a number of gotchas with their architecture that weren’t obvious at the project outset. These gotchas happened despite the effort I put into researching them in SharePoint blogosphere.

My top takeaway from the experience so far is simple but provocative:

The number of “real world” business cases where SharePoint-Hosted App Model variations make sense is very small; most solutions are going to require a Provider-Hosted app.

You can find a number of big names in the SharePoint community—people I have tremendous respect for—who’ll disagree with that statement. I don’t like offering unsubstantiated opinions, so over the next few blog posts I’m going to share my experiences developing apps for SharePoint 2013, across three App Model variations.

Here’s the roadmap for the series:

  1. Part 1: Introduction, a.k.a. “This Post”. A high-level introduction to SharePoint 2013 App Model considerations with some thoughts on why we’re here and a word of encouragement.
  2. Part 2: App Web Hosted Apps. My thoughts on SharePoint-Hosted Apps with app data stored in the web, and where the app deploys to and runs in.
  3. Part 3: Host Web Hosted Apps. My thoughts on SharePoint-Hosted Apps with data stored in the web that activates/installs the app. The differences between Host Web and App Web may seem subtle, but a couple of the distinctions are critically important.
  4. Part 4: Provider-Hosted Apps. Apps where the primary logic and runtime are in an application external to the SharePoint site. Bringing secondary environments to your solution has complications, but it offers tremendous power.
  5. Part 5: Observations and Conclusions. I’ll wrap up the series by offering a high-level comparison of each app model across some common application features, requirements, and concerns. I’ll also provide a matrix you’ll be able to adopt and modify for making App Model architecture choices in your own apps.

Note that the three App Models I’ll investigate in this series are not a comprehensive list. There’s plenty of room for variation and nuance, and in all likelihood hybrids (in multiple senses of the word) will be the most common solutions. But the three architectures I’ll feature are certainly representative of the SharePoint 2013 App Models, and they cover two of the most basic decisions you’ll need to make for any App Model-based solution:

  1. In SharePoint, where will the data for my app live: in the App Web or in the Host Web?
  2. Am I going to need to use an external provider? If you start without one, I’m betting you’ll want one before release 1.1.

As I cover each App Model, I’ll provide code in one format or another from a real app that I’ve worked on. I’ll offer my thoughts on the strengths and weaknesses of each model. I’ll also provide “pro tips” (I’ll allege that they’re pro tips) based on my experiences and battle scars.

But First, Some Background
Before we dig into the specifics of each model, I want to set the table. We’re standing at the most significant inflection point in SharePoint’s product history for a handful of converging reasons. The most obvious is SharePoint needed a plausible story for cloud-hosted custom development. Sandbox solutions didn’t inspire tremendous adoption in the industry, and even in their unappealing state they relied too heavily on the server to be truly Office 365 friendly. In contrast, both SharePoint-Hosted and Provider-Hosted solutions completely remove custom code from the SharePoint server while still offering an effective presence and broad support for customizations. If the primary goal of the SharePoint 2013 App Models was to provide cloud-friendly customization routes for SharePoint, mission accomplished. They’re not without limitations and corners, but overall they’re a success.

From my perspective, the new App Models pursue a more intriguing secondary goal. When I’m feeling cheeky I sum it up like this:

Pre-2013 SharePoint was the platypus of the Microsoft middleware stack, and in desperate need of an evolutionary reboot.

SharePoint Is A Platypus
Pre-2013, SharePoint had been stuck in a strange evolutionary backwater. It’s architecture was still firmly rooted in concepts from ASP.NET version 1 and 2: Web Forms, Web Parts, Server Controls, etc. Concepts more than a decade old at this point, and to me they feel even older than that. And though Pre-2013 SharePoint may be highly adapted to certain environments, there are steep capability edges if you need to grow beyond its natural habitat.

Outside of this backwater, the rest of the Microsoft web development world has enjoyed amazing progress courtesy of the ASP.NET and .NET framework teams. The advances I miss most when writing pre-2013 (i.e. Farm) Solutions are:

  2. Entity Framework
  3. Visual Studio Test Automation
  4. Single-Page App Frameworks like Angular and Backbone
  5. HTML5
  6. Web API 2

In short, the web development world has been passing SharePoint by. To illustrate how large the gaps are, I’ve worked up a timeline comparing SharePoint’s product release cycle with major milestones in web development tooling:

SharePoint App Dev Timeline

SharePoint App Dev Timeline

The kicker is that these advances aren’t just available; they represent the prescribed best practices for the web development community at large. We might disagree about the impact of these developments, or how workable the workarounds are, but I can make a strong case that SharePoint has been perpetually riding the tail of web development technology curve, and that story wasn’t going to improve much without drastic intervention.

The good news is that the SharePoint 2013 App Models are that drastic intervention: they’re an end-run around the platypus’ limitations. Even within the constraints of an App Web Hosted solution, the choice of UX tools and frameworks feels liberating compared to the nip-tuck approaches to client-side development for Farm Solutions. And with a Provider Hosted architecture, you’ve got complete access to the latest versions of your preferred development stack and community tools. You’ll run out of time to research your options well before you run out of options.

Don’t Panic
If you’ve stuck with me this far, let me offer you one last word of encouragement: Don’t Panic. Almost always good advice, but now it’s particularly apt for the seasoned SharePoint developer who’s been paying bills by writing custom features, web parts, app pages and server controls for for the past 3+ years. You know – those of us who’ve been riding the Platypus. We’re all having a serious who-moved-my-cheese moment over SharePoint 2013, but in the long run, I think our lives will improve as the new App Model adoption rates climb. Yes, we’ll have to invest time learning new tools and development patterns. But those tools and patterns are going to make us more productive, align our skills more closely with the larger web development community, and offer us opportunities to extend the reach and value of our solutions.

Good times.

Next Up: App Web Hosted Apps
In my next post, I’ll take a deep dive into my experience working with App Web Hosted Apps, and try to explain where I think they make the most sense. Spoiler alert: it may be User Experience related.

1: TL;DR is geek shorthand for “Too Long; Didn’t Read”. It’s used either derisively by commenters as a response to an over-long post, or pre-emptively by authors to indicate a quick summary of an over-long post.

read more
Sean HesterSharePoint 2013 App Models Considered – Part 1

New Webinar – Choosing a SharePoint App Model Architecture Webinar

John Underwood is a Technical Evangelist at ThreeWill. He has nearly thirty years of software development experience. He is an experienced technical instructor with superior presentation skills and is proficient in delivering standard curriculum as well as developing and delivering custom curriculum.

Choosing a SharePoint App Model Architecture Webinar

SharePoint Hosted? Provider Hosted? What do these mean, and beyond that, which one is right for your app? In this webinar we’ll look at the choices and draw some conclusions on the proper usage of these different architectures. Learn what you need to make a good decision about choosing a SharePoint App Model architecture.


Software architects, developers, and business stakeholders that are investing in SharePoint Apps.

Apps for SharePoint Hosting Options

The SharePoint 2013 app model provides the following ways to host the components of an app for SharePoint:

  • Provider-hosted: Apps that include at least one remote component and may also include SharePoint components. The non-SharePoint components are deployed by your logic on your hardware or cloud account, or deployed on the customer’s hardware or cloud account using installation programs and instructions that you provide.
  • SharePoint-hosted: Apps that include only SharePoint components and logic that runs on the client.


Register Now
read more
John UnderwoodNew Webinar – Choosing a SharePoint App Model Architecture Webinar