3 Reasons Why Microsoft Acquiring Yammer Will Change SharePoint Forever

And a lot of other thoughts on the matter that are probably just TLDR

So recently, some of my colleagues have been asking me what I think about Microsoft acquiring Yammer. My short answer is that I think it's a good thing (if you want my long answer, keep reading.) But you've just got to love these news articles that are saying things like it signals some cosmic shift in the way businesses and software companies will think about social. I mean really guys, seriously?

Sure, I guess this might be big news if you’ve been living in a cave in Tora Bora for the past ten years. From where I've been standing, it's just a logical move in the same direction that Microsoft was already heading a few years ago when they started working on SharePoint 2010. It may be an exaggeration, but at SharePoint Conference 2009, it seemed like you couldn’t swing a dead cat around in the Mandalay Bay without knocking over 3 or 4 sessions about "Enterprise Social."

I especially love this quote from a Seattle Times article. "For all its successes, here's one thing Microsoft has never managed to do: Create a consumer product that people like so much they clamor for it in their workplace." Um, wait -- what? Microsoft may have a fairly mundane batting average when it comes to their products' overall success record, but to say something like this you'd have to have basically forgotten the journey that SharePoint has taken since it was originally released (under that name) in 2001 to where it is now the dominant platform for enterprise collaboration and file sharing.

SharePoint's ascendancy wasn't something that happened because CIOs saw the vision Microsoft was trying to pitch -- far from it, IMHO. First versions of SharePoint were clunky. It couldn’t make up its mind if it wanted to be a poor man's version of Documentum or MS FrontPage++ (*shudders*). In 2001, I tried in earnest to convey the great features of SharePoint search but my appeals too often fell flat. It wasn't until 2003 when Microsoft unified the free and pay-for versions of SharePoint under a single name that things started to get real and I believe it was precisely this "freemium" model that caused SharePoint to take off at a viral adoption pace.

True, we're not directly talking about the consumerization of IT -- more like the consumerization of the IT department. It was information workers who elevated SharePoint into ubiquity by deploying it everywhere they could put it to work. The fact that users approved made it a done-deal.

Of course, a good bit of my time over the next few years was spent cleaning up messes made in the essentially-free-but-not-technically-really-free Windows SharePoint Services that could have been avoided or solved with SharePoint Portal Server (or MOSS, if you prefer). But that's not my point. Rather, I want to emphasize that Microsoft has been talking about Software as a Service and pushing what is essentially ShareWare (no pun intended) for over a decade; so it's silly to think that this acquisition is about them trying to buy something that they couldn't do for themselves.

Or is it? One of the things I have noticed over the past 15 years as a Microsoft developer, consultant, and partner is that Microsoft seems to have a systemic problem imagining what customers will actually want to do with their products. This leads to craziness like pie charts where you can't pick the colors for the pie slices. (Seriously, you can't make this stuff up!)

My exposure to this phenomenon has always been from the outside looking in -- thank goodness; I can't even begin to speculate as to why this might be the case. But it occurs to me that there are so many examples that perhaps even Microsoft is aware of its own limits and may simply be acquiring companies like Skype and Yammer because they do a better job of understanding and predicting what customers want.

However, rather than trying to read the tea leaves about why Microsoft is doing what they're doing, I'd rather speculate on the impact for those of us who -- for good or ill -- have come to rely on Microsoft products. I think there's a compelling story to tell there and I have some experiences that might inform -- or perhaps confuse -- in an entertaining way.

So here it is, with a full disclaimer regarding my lack of credentials as a fortune teller and an explicit request that if my prescience should make you a million dollars you should buy me a nice steak dinner (or at least a beer).

Prediction #1: More Business Solutions Incorporating Yammer
While I'm technically not sure if I can say that this means "more than 0", it does strike me that in spite of Yammer being a compelling service we don't see more business solutions based on this technology. Essentially, Yammer is Twitter in a walled garden, which is exactly what anyone would want if you like the connectedness and real-time sharing of Twitter but don't like pictures of your boxers (or your books) hanging out there for the public (or your competition) to see.

That workgroups adopt it as a way to share information is not especially surprising, but there doesn't seem to be a lot of apps on their platform that do very business oriented things. Whatever happens, both companies will want to make a compelling case that Yammer can have more uses then just letting employees chat with each other sans water-cooler; they can already do that in Lync.

I wouldn't be surprised if within a year or so, you see a proliferation of apps for Yammer that appeal to business uses like tracking interaction with customers or entering your expenses. Also, I think you'll see some solutions built on top of SharePoint that start to incorporate the Yammer message feeds directly into SharePoint sites. Why do I think this? Because this is exactly the sort of avant-garde work we were using Yammer to experiment with as far back as 2009 while I was working at the IMF. (Also, some of those apps and solutions might end up being written by me – just sayin'.)

Prediction #2: Office 365 Users Will Benefit First - You Other Jerks Get in Line
One thing I've noticed since Office 365 was released last year is how it's changed the maintenance cycle for SharePoint (and probably Office, Exchange, and Lync as well.)

It used to be that service packs were primarily focused on improvements to SharePoint for on premises deployments. Sure, I'm assuming that hosting partners with armies of SharePoint farms probably had significant influence over which bugs received attention first. Whatever their size, customers who had purchased SharePoint would open tickets with Premier Support Services and those would get turned into KB articles and possibly somewhere down the road your bug might see a hotfix and get scooped up into a service release.

This still happens, but now there is a new seat at the table for the Office 365 team -- and their motivations are very different than those of existing customers. For one thing, they are forward focused on selling new subscriptions as well as retaining existing ones. As a result, we've seen features added to SharePoint 2010 that were meant specifically for Office 365 servers; in some cases these are not even supported for on premises customers. In other cases, the Office 365 team has quietly deployed fixes across their entire farm (think Monsanto, not the Kent family), for problems that are notorious for plaguing on-premises deployments.

So, it should surprise nobody if a SharePoint/Yammer expansion pack, software development kit, or CodePlex project experiences its first life as a set of enhancements or features that are only available for Office 365 customers. Personally, it'd be an amusing turnaround from having to say "No, you can't do that with SharePoint in Office 365," to "Sorry, only Office 365 customers have access to that SharePoint feature right now."

Maybe the rest of us will just have to wait for Office 15 in order to take advantage of Yammer in SharePoint. I guess only time will tell.

Prediction #3: What Yammer Does Well Can – And Will - Be Done Well In SharePoint
One way to get more free Yammer users would be to offer more Yammer interoperability in SharePoint right out of the box. Now that Microsoft owns Yammer, this makes absolute sense. Why shouldn't the bump that Yammer already gives to SharePoint go both ways?

As far back as the 2010 beta I've stated that Microsoft was incredibly excited about social. I heard the phrase "Facebook for the enterprise" mentioned at least often enough that I still remember it now a few years later -- despite filling my head with myriad technical trivialities and my belly with what feels like probably a good stiff drink for each of them.

SharePoint 2010 does indeed have a lot of great social features. There's folksonomy / tagging / "I like It", tag clouds, and even knowledge networks that can recommend people at your company based on your need to share knowledge and skills. Ubiquitous presence indicators have been in SharePoint since 2003 and are inherently social; they let you reach out and tap someone at the moment you’re looking at a document they wrote. How about the fact that two people can work on a Word document at the same time -- how cool is that? I have to give Microsoft props. There are a lot of compelling "social" features already in SharePoint and there always have been, which is why I think it’s been such a compelling platform for collaboration.

Given all this, I still see three thorny problems with the push for social as implemented in SharePoint 2010.

First, I think Microsoft didn't know what to call it. (See above reference to "tagging", "folksonomy", "I like it", etc. which probably goes by a half dozen other names that I'm not remembering offhand.) This is partly a problem with Microsoft in general that's been true for years; they take an awesome name like Vertipaq and change it to xVelocity (whatever that means!) There's a running joke around the office here that if Microsoft made cars they'd call them something like "Microsoft Car", "Microsoft Go", or maybe on a stroke of genius "Travel-X-lerator". I suppose when you're *that* bad at naming things, nobody can blame you for changing the name every couple of years, which is how SharePoint itself came to have something like 6 slightly different names over a 10 year timespan.

The second issue is that Microsoft’s social implementation is -- well, it pains me to say things that will hurt my friends' feelings, but sorry Microsoft -- just plain clunky. I know this because the main reason we've never used it or had any success in getting our clients to use it is that it just takes too much effort. 99% of folks don't even know where to start filling out their user profile on My Site. The tagging interface is dreadful, and the activity feed is even worse. (How bad? Start here and here; Chris O'Brien has an excellent article on improving SharePoint social.) And if the interface is terrible, the API is a nightmare! I'm well informed on this topic because we've recently created some solutions that improve SharePoint's social features. Fortunately these dovetail very well with Yammer since they focus on adding hash-tag capabilities to SharePoint and fixing e-mail alerts. We're looking forward to building some exciting products with Yammer as part of our strategy.

Problem number 3 is that Microsoft saw the overwhelming influence of Facebook and got, well, obsessed. Not only did this basically leave them functionally blind to all the other cool social apps out there, it also opens up a huge vulnerability. What happens when people stop being in love with Facebook and decide that they want to go do something else? Will SharePoint 2020 start chasing Google+? (Somebody over at Google will no doubt find that a delicious thought.) While repeating "Facebook of the Enterprise" does cause me to go into uncontrollable chuckles as I imagine Capt. Kirk updating the status of his wall, I notice that nobody says "the Tumblr of the Enterprise" or "the TinyUrl of the Enterprise." And the missed opportunities that really floor me are of course Twitter and LinkedIn (where most of the actual business discussions are taking place, duh!)

Bringing Yammer integration into SharePoint will require Microsoft to clarify its vision of what tags *are* and how to make them easier to use. SharePoint already has the infrastructure to do 95% of what Yammer does under the hood; seeing discussions, folksonomy, and user profiles rolled up under the Yammer banner would give them a much-needed identity. And, while all of these things will no doubt come to Office 365 customers first, we can probably expect them, eventually, to benefit the overall SharePoint community.

So, my hope for Microsoft is that by acquiring Yammer they have gotten over their infatuation with Facebook, they can better focus, and can start making lasting social improvements to SharePoint. I think they will.

Besides, in my opinion, Yammer is a much better cook and wayyy-less crazy; they make a good couple.


SharePoint Content Planning: Marathon or Sprint?

As this is one of my first blog posts for Liquid Mercury Solutions, I wanted to discuss something I feel strongly about. The content planning process is such a critical phase of the SharePoint development cycle because the entire site architecture will depend on the content types and workflows you create. Many companies just slap the content together using OOB types and never really bother to plan them out. Then, when they want to extend, enhance, or redesign the site, oops! Too bad!

For convenience, we’ll follow some of the planning worksheets from Microsoft Technet. Specifically:

  • Document Management Participants worksheet
  • Analyze Document Usage worksheet
  • Content Type and Workflow Planning worksheet
  • Information Management Policy planning
  • Managed Metadata Services Planning worksheet
  • Policy worksheet
  • There are a number of other worksheets, but for the purposes of keeping clients in-line and moving the pace along, we’ll keep those in-house.

Rule: The client should be responsible for a little as possible. That helps narrow down the feedback, minimizes risk of overwhelming the client, and keeps the project moving along quickly. But you do want to have clients participating at some level.

One approach is to show only the most relevant columns and hide the rest. The assumption is that whatever the client fills in will tend to be the most important information to them. You can have them fill out the rest of the information later, which will result in a naturally prioritized list of content types.

1. Document Management Participants
The first thing I like to do is have the client list 5 types of users in their organization whom they expect to use the portal. For this step, I have them fill out the Document Management Participants worksheet. I ask them to fill in the columns for a User’s position (title), the types of documents that user might create or utilize, and the user’s role in the organization. It’s also helpful to ask the client to solicit contributions from potential users in building this list. So ask them to pass it around if they can.


2. Analyze Document Usage
Here, we’ll use the Analyze Document Usage worksheet to identify some specific documents that each participant will use, what formats those documents will be (doc, pdf, web page, etc.,) who will create them, who will use them, and who will need access to them (i.e. for record-keeping.) A good rule of thumb is to populate the roles column first, then think of some document types they would be working with and proceed from there.

For this step, we come up with 2 documents for each of the 5 participants (positions) you identified in the first step. There may be some overlap on some documents and that’s fine. It can be addressed later.

Ex: Employee resume


3. Content Type and Workflow Planning
For step 3, we need to fill in some information to give each document type its metadata. Metadata is information about a document that is used to categorize and classify your content. Metadata is associated with a content type as a column.

In the Content Type and Workflow Planning worksheet, add between 3 and 5 columns for each document type. I’ve added Employee Resume as the example again. Try to add columns that would make each type of document easy for you to find (author, subject, audience, language, etc) as well as editorial columns (date posted, last modified, etc) to help track the document’s history.


4. Information management policy planning 
Stay tuned for the next steps in part 2. Same LMS time, same LMS channel.

SQL Azure Makes Database Administration Fun!

If the thought of setting up load balancing thrills you; if you just can't wait to optimize your hardware; if you're desperately eager to crawl around your data center making sure that your machines are all connected to the network; basically, if you're thrilled with the physical plant planning aspects of SQL Server… well… this is not the blog post for you. Go look at funny pictures of cats instead.

Okay, now that they're gone…

SQL Azure, a highly available and scalable cloud database service built on SQL Server technologies, separates the logical database from the physical hardware.  Your database becomes a Platonic ideal, floating in the astral plane of ideas. Yes, it physically lives somewhere, but aside from the proximity of your data center (and therefore how much latency you have to deal with), you have no idea where. More importantly, you don't care. You can focus your attention on the data itself, on optimizing it, not on physical server considerations.

Issues to Consider

Sure, there are quasi-physical issues you still have to consider.  For one, your cost will largely be determined by storage and transfer levels, and there's an upper limit to how much data you can have at all.

Also, performance degrades as size increases, to the point where some have found it makes more sense for their applications if they divide a 150 GB database (the maximum size allowed by SQL Azure) into three 50 GB databases.1

A Different Mindset

It’s not just that you don't own the box; the box won't even do things you'd expect it would do if it were really a SQL Server.  When I used to maintain an application that was hosted on shared SQL Server hosting, because it was still SQL Server, I had the commands available to run a backup.

But if I tried it, I wouldn't actually get a backup, because the backup would try to write to the physical hardware that the server was on, and as a mere client of the hosted SQL Service, I had no access to that. 

SQL Azure has solved that problem by just getting rid of the backup command.  You can sync the data with a local SQL Server of your own. You can write queries that extract the data and access them via your own SSMS client.

But you cannot actually do BACKUP (or RESTORE, for that matter.)  You don't have to manage the size of your logs (in fact, you can't.)  Your data lives in a world where the file system behind it is not just inaccessible, it’s invisible.

Is SQL Azure Mission Critical?

This can be a little scary.  It's hard to let go of the idea that your data is a thing – that you can’t look at the physical object that houses it, or control the load balancing2, or that there's little you can do to improve uptime… I'll admit it, this would bother me if I were running mission-critical apps with highly sensitive proprietary data on them via SQL Azure.

I do, however, think that if I were doing that, someone would need to check my blood sugar for me3, because I can't see any reason why any rational person would ever want to run a mission-critical app with highly sensitive data on SQL Azure.  That's not what it's for.4

I mean, I suppose you can.  Microsoft promises 5 9's of uptime and will restore your stuff from their backups if anything goes down.  You can purchase two Azure "servers", and Microsoft will fail them over to each other automatically.  You can run your own backups by syncing to a local copy. And your data's encrypted every time it goes anywhere, so you probably could run Very Important Apps on Azure if you wanted to. 

But odds are, if you actually have Very Important Apps to run, you can afford to buy on-premises SQL Server, or at least virtual SQL Server hosting on your very own VM.  Also, odds are, your Very Important App probably does not want to deal with potential latency issues that you have absolutely no control over whatsoever.

What SQL Azure Is Really For

SQL Azure democratizes web-capable relational databases, so that small businesses and hobbyists can afford them.  Access was never particularly web-capable (unless you're talking about Access Services on SharePoint… but if you have SharePoint, generally speaking, you have SQL Server), and MySQL, like most open source software, is harder to use for most people because it's created to the specifications of the highly technical folks who are creating it in their spare time for fun.

SQL Azure also reduces the footprint of your SQL Server on-premises requirements, so you can cut down the amount of hardware you need to maintain and the amount of time your DBAs need to spend pretending to be network admins or DBAs. 

Additionally, like all cloud services, SQL Azure will probably be up during a problem that affects your data centers, so you can use it for emergency failover or backup services. When you're suffering from bailing your office out after a hurricane, you can at least be confident that your web site was sorta kinda continuing to run and capture data in the background.

So it's a different way to think about your data -- but honestly, I never wanted to be a network admin anyway, so I think I can get used to a world where I might never have to trunc the logs ever again.


1. Actually… is that something normal DBAs ever have to do, or is it just me? You gotta imagine the performance degradation must be impressively awful… because you also cannot join across databases.  So if your data has been split into three db's, you'll need a lot of logic at the app layer to control where you're writing a given record and then remembering where to go back for it when you need it again.

2. This isn't 100% accurate.  If you purchase two SQL Azure "servers", Microsoft will allow them to load balance.  However, SQL Azure still handles the actual load balancing algorithms in the background, and you can't really control them.

3. I am, in fact, hypoglycemic.  So if you ever find me building mission-critical apps with highly sensitive proprietary data with a SQL Azure back end, please give me something to eat.  String cheese is great.  It actually ought to have protein in it; the idea that hypoglycemics need a candy bar to bring up their blood sugar is sort of similar to the idea of giving a guy with a hangover a screwdriver, in that maybe it will solve the immediate problem but in the long run it'll probably make things worse.

4. I'm going to be a big Star Trek geek here: don't give a Vulcan a job as a stand-up comic, don't employ a Klingon as a starship counselor, don't have a Q sitting around reading numbers to you off a screen, and don't use SQL Azure for what it's not good for.  When something is very valuable doing one thing, don't make it do a different thing it's really no good at.