Oh, and in case it isn’t bleedingly obvious; don’t make important decisions based on preliinary information. You’ll stand a fair chance of getting burned, but hey, if you’re willing to risk it, that’s entirely up to you.
If you are looking for more bleeding edge information on SharePoint 2013, though, I try to keep up to date and post interesting findings on my twitter account too. You can follow me here
SharePoint Server 2013 keeps many of the existing SharePoint 2010 features, such as:
- Excel Services
- Access Services
- InfoPath Forms Services
- User Profile Service
- Search Services
- Business Connectivity Services
- PerformancePoint Services
In addition, however, there are new, or at least radically expanded services, such as:
- Content Management Service
- Translation Services
- Workflow Services
- SharePoint Quiz Client-Side Object Model Protocol
- Education Services
- Work Management Service
Other Functionality
Although probably not for the layperson, the protocol documentation also reveals a rich framework for managing Apps, rights, and licenses. This means that not only will there be a SharePoint App marketplace from Microsoft, but it will also be possible for third-party vendors to build their own marketplaces.Already there are several vendors who do this, with varying success. Although the new marketplace model may seem to compete, I am certain that most of these vendors will welcome better tools for building their solutions, deploying their products and services, and even competing with Microsoft in providing the best applications for users.
One clear sign of this is that the SPWeb class, which in the object model represents a site in a site collection, contains a new method in the SDK called LoadAndInstallApp. This method allows developers to send an App package into the web and install it.
Note: There is a class called SPSolutionExporter which may trick someone to believe there is a way to export an app, but this class exists in SharePoint 2010 and is only use to export a site as a template to the solution gallery.I have found no evidence, and it would be strange if there were, of a method to export Apps using built-in functionality. I’m sure someone will make it, though.
Beyond these functionality extensions, the SPApp model also supports easy database provisioning. Many custom applications require data storage, and with SharePoint 2010, the methods for doing so is limited to what are known as Service Applications.
The problem, though, is that Service Applications can be difficult to build and maintain. When developers want custom data storage, they often either store data in SharePoint itself, or just build a custom database outside the realm of SharePoint, adding burden to administrators and dependencies on external resources.
Hopefully, the new functionality in Apps allow for easier provisioning of custom databases so that this hassle is removed from the development cycle. The methods suggest so, even including the aforementioned support for SQL Azure databases, but of course, nothing is known at this point.
I’d like to mention that Apps are deployed on sites (SPWeb) or possibly even as sites. That means you can deploy an App highly targeted to ensure you get the functionality you need only where you need it.
Note: I mentioned security as a main focus of the SDK App documentation. There is a rich model for ensuring applications can’t behave in a way you don’t want and for ensuring only the right people get access. However, I’m not going to detail these features in this issue because of space constraints.The huge question, however, is whether SharePoint Apps will be full farm solutions or just sandbox solutions. I have some thoughts on that too, but I need to do a bit more research first.
Also, I’m thinking that these features are what’s going to be most important to most readers, but please feel free to correct me if I’m wrong.
Licensing
Microsoft will also add support for licensing of the application packages that developers deploy. What this means is that vendors or even regular folks can put a price on their application and sell it through the marketplace.The first clue to this is a method attached to the SPWebApplication class called IsUserLicensedForEntity.
Note: Apparently, licensing can also be turned off, which could mean that either no applications requiring licenses will be installed or that the application developer has not set a license at all (in other words freeware).
However, there’s much more information in the protocol documentation, specifically in the MS-APPMD document (or SharePoint App Management Database Protocol Specification if you insist on the full name).
That document says that there are four license types that you can add to your package:
- PerpetualMultiUser marketplace license type.
- PerpetualAllUsers marketplace license type.
- TrialMultiUser marketplace license type.
- TrialAllUsers marketplace license type.
“The commercial type of the marketplace license, used for commercial purposes and stored in the protocol server.”From the documentation, it does not seem like this is an alternative license type to the perpetual or trial licenses, but something that is added on to every license, regardless of license type.
The ‘protocol server’, by the way, is the SharePoint server. Wonder why they can’t just call it that.
The model also defines a license director who is a person (or maybe group) who are allowed to assign licenses to users. For example, a company may buy 10 user licenses for a product, but have 50 active users. The license director will be able to select which of those users get access to the product.
Licenses can also be timed so that they expire after a certain time. The expiration applies only to trial licenses, so perpetual licenses aren’t affected.
Upgrading to SharePoint Version 15: The Planning Starts Now
SharePoint 2010 is version 4 of the product, but is labeled “version 14” to align with Microsoft Office versions. While the rest of us are battling to align SharePoint 2010 with our current business requirements, Microsoft is busy planning SharePoint version 15. While there is nothing near to a release date yet, let’s step out on a limb and call it SharePoint 2013 (software branding isn’t that creative, is it?). In fact I’ve heard a Microsoft employee refer to “vNext” meaning version 16… The product group lives in a different plane of space and time.
At the SharePoint Event at Microsoft in last month, an attendee stood up at the end of the keynote and asked, “Upgrading to SharePoint 2010 has been so painful… What can I do to reduce the pain of upgrading to the next version of SharePoint?”
His statement—that upgrading has been painful—is something I hear all the time. It’s true, upgrading can be painful, though it does not have to be painful. His question really nailed it, though: It’s not the upgrade to a new version of SharePoint that makes our lives painful, it’s everything we do between upgrades that makes an upgrade painful. So now that you’ve upgraded to SharePoint 2010—or are planning an upgrade to SharePoint 2010, what can you do to make the next upgrade easier? The answer, in my opinion, lies in careful planning and design of your farms, web applications, and site collections.
Consider a vanilla SharePoint 2007 farm, with web applications and site collections that use only out-of-box features of SharePoint. How difficult is it to upgrade that farm? Not at all… you run the Preupgrade Check, then do an “in place upgrade” and voilà you have a SharePoint 2010 farm.
But that’s a fantasy, isn’t it?
Who among us has a vanilla SharePoint 2007 farm with only out-of-box features? Most of us have added custom solutions, custom code, and tools that sit on top of SharePoint 2007. Those are the bits that make upgrade challenging. We have to validate each component for compatibility with SharePoint 2010. We discover some components—like some of the “Fabulous 40 Templates” that Microsoft itself produced in SharePoint 2007 days—cannot be upgraded. We learn that some of our third-party vendors don’t yet have a SharePoint 2010 compatible release, or that the cost of upgrading those tools is too high. We find that some of our custom code was written by developers or consultants who are no longer available to help us remediate compatibility problems.
These are the painful parts of upgrade. Evaluating and validating all the “extras” and customizations is a time consuming and sometimes futile task. Meanwhile our customers are clamoring for the incredible new features of SharePoint 2010—whether that’s Office Web Apps, FAST Search and PerformancePoint, managed metadata, in-place records management, or any number of myriad improvements. And our administrators want to take advantage of improvements in SharePoint 2010’s infrastructure and management story. We can’t get there fast enough, but we’re stuck in a quagmire of compatibility.
Folks, this is going to be the story, moving forward. Thought the upgrade from XP to Vista/Win7 was tough? Now, instead of one user’s computer being a problem because of an incompatible application that is mission critical to that user—which prevented us from upgrading that user’s system while we moved on to other users’ systems—we now have components that are mission critical integrated into a server-based platform that blocks upgrade of an entire farm.
What’s the solution?
Honestly, I don’t have a “silver bullet” answer, but rather I have a proposal that I hope will generate discussion and experience-sharing. The proposal is to stop throwing every component that a team requires into a single site collection, web application, or even farm. Instead, consider aiming for a logical architecture—a “containment hierarchy” of farms, web applications, and site collections—that give you a clear delineation between “vanilla” and “customized” SharePoint. Consider giving each team a site collection to support their collaboration—using the 80/20 rule—using only out-of-box functionality. If they need functionality that requires a custom component, put that functionality into a separate site collection. Add a navigation link from the vanilla team site to the customized site collection so that users perceive it as a single “solution”, but behind the scenes you’ve actually got a containment hierarchy that keeps vanilla and customized elements separate.
Consider, then, the upgrade story to SharePoint 2013. You can upgrade the vanilla site collection quickly, giving immediate access to the improvements Microsoft will make to the platform, but the specific functionality that required a custom solution can remain on a SharePoint 2010 farm, with a link from the upgraded site collection back to the customized site collection. Think about it—if the functionality was that “custom”, it probably won’t need upgrading—it does its job and meets requirements already. Or, Microsoft will introduce a new feature in SharePoint 2013 that replaces the need for the customized “container”, and you can just retire the custom solution and use the new out-of-box functionality.
Take this to the level of web applications and farms. Let’s jump up to the farm level. If you’re going to install a farm solution, do you want that in your “primary” farm as a potential block to upgrade? Or are you better off hosting that custom solution in a separate farm?
Those of you who have seen me present “live”, or who will join us at SharePoint Connections or in one of the cities we’re visiting on the SharePoint Coast-to-Coast tour will know I go into great detail about how to structure a SharePoint service—the farms, web applications, site collections, and sites—to align with your business requirements. The better you do that, the better your upgrade experience will be. If you have everything in a single farm, in a handful of Web applications, and in a limited number of site collections, you’re going to find that there are incompatibilities that must be remediated and dependencies between compatible and incompatible components that make life miserable. If your containment hierarchy is modeled in alignment with your business requirements, you’ll find that you can upgrade the parts of your service that will benefit from new features—easily—and continue to get the functionality that you built to meet specific requirements from your “old” farm.
It’s a tough concept to boil down into a column, but hopefully you can consider that fantasy of a completely vanilla farm and how easy it is to upgrade, and then look carefully at where you are intentionally and for good reason deviating from a vanilla implementation, with full awareness that the decisions you make about how to meet your business requirements with customizations now will absolutely impact your upgrade to SharePoint 2013. Because I’m sure that, as with SharePoint 2010, Microsoft will make the upgrade to SharePoint 2013 from its own SharePoint 2010 “bits” pretty easy and straightforward… It’s only our choices about how to make SharePoint 2010 align with our business requirements that can make it more painful.
