Category Archives: SP2013

Thoughts on SharePoint Conference 2014

Posted on by

My thoughts on the Microsoft SharePoint Conference 2014.  The event was a great success, held Mar 3-6, 2014, at The Venetian, in Las Vegas.  Compared to previous SharePoint Conferences, SPC14 was held at a bigger venue, it was easier to get around in, the exhibition hall was more wide open, the keynote speaker was about as big a deal as could have been had (Would Hillary have been a bigger coup?) and The.WIFI.Worked.  A tremendously successful conference.  The SharePoint and Office 365 teams at Microsoft deserve to take the next 36 hours off, perhaps attend the Las Vegas NASCAR race, and then bask in the success of their conference.

The new product announcements show some good new direction. I’m particularly excited about

  • the New Office 365 APIs that bring Office 365 closer to parity with SharePoint Server 2013 as a platform for business applications (http://bit.ly/PkMEO2),
  • the new content enablement that is provided for PowerPoint, Excel, and Outlook applications (http://bit.ly/PkMEO2)
  • Improvements to Power BI across the board and the release of Power Map. (Even though this was announced a month ago, I’m adding it here (http://bit.ly/PkOvmd)
  • The concept of Working Like a Network (http://bit.ly/PkO23e). It will take a while for this to roll out, but the application ideas are already starting to roll around this one.
  • And the biggest one, for me and my new company, BluLink Solutions, will be the patterns for migrating Trusted Code solutions to the App Model (http://bit.ly/PkOXkj).

SPC14 was the 5 year reunion for those attendees of the tremendous and inimitable SPC09 conference, and it was the 10 year anniversary of the launch of SharePoint 2003, which started the enterprise-wide push and where “SharePoint” started to find its legs, as it grew into MOSS 2007 and SharePoint Server 2010.

SPC14.InfoPathFuneralOne of the things that makes for a great reunion is a strong community.  I consider myself lucky to have been able to observe the growth of the community and the depth and breadth that it contains now is fantastic.  No longer can anyone single group, or collection of groups, control, manage or “provide direction” to the community.  There are many groups within the community, and the overall group is large enough to support new groups as needed.   I attended the meetings of the MSFT Technical Communities and the SharePoint Saturday leaders and the SharePoint User Group leaders and some very useful coalitions are building helpful tools to support different locales and groups of different sizes. I heard that the Women in Technology (secondhand, as I wasn’t on the list) group overflowed its planned meeting space and that is tremendous. Impromptu activities such as the funeral procession for InfoPath, small groups such as SP FitBitters and SPRunners, or around evening events or side trips to local attractions, and countless others, are great examples of where the community is diverse enough to take care of its own.  This is so encouraging.

On the other hand, it does mark the maturation of the SharePoint community and marks the time when messages will be more and more difficult to ensure are delivered and received accurately.  The good old days of one person being able to understand all of SharePoint is gone. One person can now understand most of SharePoint, and can track most of what is goingon through diligent following of multiple blogs, RSS, and twitter feeds, but that can be difficult to maintain when we also have to work…

The early three social kings of SharePoint have changed, as well.  Mark Miller (@EUSP), it seems, has moved to greener pastures, Joel Oleson (@Joeloleson) will always continue to drive a large group of followers as illustrated by his leading a procession in a Monk’s robe through the conference, and Jeremy Thake (@jthake) has now moved to join Microsoft in leading developers to new depths. No longer are the three of them driving the community audiences (Devs, IT Pros, End Users) in a coordinated broad direction.  True, the trio has been divided for a little while now, but I think SPC14 marks the official passing of the torch back to the community as an entity.  Even at SPC12, the community booth efforts were spearheaded by a group with these three providing much of the guidance.

Moving forward, though, I think that SharePoint as a whole is too large for a single group of friends and workers and associates to be considered the leaders.  Each of us has our own path to carve out of the world of business solutions. The relay baton has been passed. SharePoint has grown up.

Where will you, as an attendee of SPC14, shine your light?  Whatever you are working on, share it. When you come up with a best practice, or a new approach to using OOB features combined in a unique manner to provide new functionality, let others know.  As you see your companies using SharePoint as a platform for new vertical applications and to support solid business processes that have been rebuilt to mash up data in a new way and expose it to new business groups who couldn’t access it before, share what you see! Talk about the impacts, and help other groups realize the potential locked within their SP OOB mentality.

SharePoint Friends Don’t Let SharePoint Friends Work Only with OOB Functionality.

I had a great time at SPC14 and I hope that all of you did, as well.  If you didn’t, let MSFT know. If you did, let the community know!    I can’t wait to see everyone again next time.

Should Microsoft Kill SharePoint?

Posted on by

This is a pretty sensationalistic title.  Memeburn wrote an article based on word spoken by Gartner Analyst Jeffrey Mann (@jeffmann) at the 2013 Gartner Symposium. 

Disclaimer: I don’t have access to Jeff’s original words, only his words as reported by the Memeburn article, so there might be some differences in the interpretation.

The article mixes contexts like flammable fuels.

“Hardly anybody likes it” (yet, still 70% of companies see that at lest 50% of their employees use SharePoint at least once a week)

“The problem is that SharePoint is a victim of its own success”  (I’ve never understood how this comment can be applied generally to anything.  Don’t we want success?)

“It’s too big and complex”  (the implication here is that IT Pros are scared of managing SharePoint, and once it is installed it is unusable…)

These points lead to the summary datapoint that drives the fear: “As a result, many people are using versions of SharePoint that are at least four years old.”

ACK! The Horror!  The platform is dead because not everyone updated within the first six months!  AUGH!  Can you hear the anguished cries of IT Pros who don’t understand it when  SharePoint upgrades don’t roll onto server boxes as smoothly as the most recent version of Microsoft Office?  Or that, given the fact that the release cycle was 3 1/2 years in between SP2010 and SP2013, having a version that is 4+ years old at this point is actually the normal state of things?

A second line of reasoning in the article is that SharePoint “is too big and complex” and that IT shops would be better off using an entire range of point solutions to provide specific features instead of one large platform, such as SharePoint. 

Really?  What happens when you want to upgrade all 32 of the point applications that you had to install in order to match what SharePoint provided you? Certainly, all of them will upgrade at the same time so you’ll never have to worry about mismatched versions, right? 

I’ll be the first to stand up and tell a business group that if you only want to do 4 things, then you should use stand alone tools, and SharePoint is not for you. However, for most medium-to-large enterprise that I’ve worked with, the amount of integration and services that are needed to meet business requirements just simply cannot be managed more efficiently with point solutions.  If the organization does not work with SharePoint, they are probably working with another relatively large collaboration platform, from a large vendor.  Point solutions are best for small companies, but not for medium-large.

The third point in the Memeburn article is that Microsoft should kill the on-premise version of SharePoint because Microsoft wants to move everyone to the cloud.  And Microsoft will be the first to tell you that they believe that every employee can work just fine in the cloud.  We have to remember, though, that enterprises are called large organizations because they have a lot of moving parts.  It will take time.  No need to rush.

And then the icing on the cake that just caused me to shake my head.  “The installed base is so large that Microsoft will of course keep supporting it, but upgrades will be slower coming, and users shouldn’t expect the latest or greatest functionality.”

This statement is the most important of all of Jeffrey Mann’s quotes in the Memeburn article, and it is being treated as a consolation point.  Users need to have this last quote etched in their minds, and instead of getting all sensational about “Should Microsoft Kill SharePoint???”, the article should focus on the meat of the news – that is, that your investment in SharePoint on-premise is going to be supported going forward, so don’t do anything crazy, but you should be moving to the cloud as your systems and enterprise software packages and tools allow.  Moving to the cloud needs to be important.

But, please don’t shoot the horse while it is still attached to the plow. 

Veronique Nails It

Posted on by

While scanning a few blogs today – something that I haven’t taken the time to do frequently enough, it seems, I ran across Veronique Palmer’s blog entry which was a recap of her visit to SPC12 last week. (http://veroniquepalmer.wordpress.com/2012/11/26/thoughts-on-sharepoint-2013-after-the-conference)

I had the good fortune to run into Veronique at lunch one of the days and it was good to see her again.  She has a huge source of energy running through her, and anyone who strays too close to her can’t help but feel the energy that she brings to SharePoint and, I can only imagine, the passion that she brings to her clients.

First, there was a lot of confusion and frustration about how Microsoft and SharePoint decided to release information about SharePoint 2013 (SP13) during this release cycle.  Veronique was not the only one who complained about the seemingly targeted approach to the release of product information.

It seemed that the SharePoint team was following the lead from the Windows 8 team and keeping things as quiet as possible to avoid competitive product offerings as well as to maximize the “Wow” effect on the day of launch.

It might also have been the opinion of the SharePoint marketing team that with SharePoint 2010 doing so well in the marketplace, that the need for pre-launch buzz generated from conversations in the ecosystem about the product was minimal.

The potential downside of this is a reduction in the number of end-to-end product reviews that SharePoint could have received from partners and developers about the product, when each different type of developer or user was shown only the pieces of the product that were most necessary for them.

Another potential problem, which Veronique pointed out, was that time was “lost” in allowing consultants to be up to speed with the product at the time of launch.  This had an impact on partners, as well, as many partners and consultants had a difficult time predicting the launch date, and many products had their timing set for post-January 2013, instead of being able to be ready for a November 2012 release date.

I can only imagine that Microsoft decided that it was, in fact, getting a good amount of feedback, and that these negatives were manageable.

The next set of points that Veronique makes in her blog entry apply to all users of SharePoint who are considering a SharePoint deployment.

It’s important to consider the following when considering/planning a SharePoint deployment:

  • Do the research and go into your project with your eyes open about the possible alternatives.
  • Make sure that you are listening to multiple sources for your information. Microsoft, consultants, partners, blogs, analysts, and other community sources for SharePoint are useful in rounding out your strategy.
  • Understand that different SharePoint versions have different user interfaces and have different user expectations.  Your training and procedures may have to regularly go through modifications as you move from version to version, so plan accordingly.
  • Don’t cause yourself to feel too much pressure to move to a specific SharePoint version just because it is newer.  By understanding the features of each SharePoint version, combined with the capabilities and experience of your teams, your developers/consultants, and partner solutions, combined with the lifetime of your expected deployment and when you might be ready for an upgrade, you will be able to select the right version for your current deployment and plan ahead for future releases.
  • It should be understood that your users are going to resist change.  Build this into your operations and training plans.

Thanks, Veronique, for getting the conversation started, and for giving me the impetus to write a blog entry again…  (I really need to do this more often.)