What if Microsoft split itself in two?

Many IT pros are frustrated by Microsoft's changes, so Tim Mangan contemplates a few radical solutions in this thought exercise.

It's not like it’s a novel idea. The US Government wanted to force it to happen 18 years ago, but later settled on an agreement for Microsoft to reign in some of its monopolistic practices. But what if Microsoft decided to split itself in two now? HP, Motorola, and others have done so. I am not claiming that I have heard any noise whatsoever about a split up, it's just an idea that I like. I like it for what it could do for our industry, and I like it a lot.

But a breakup doesn't happen because I, or even all of Microsoft’s customers, think it is a good idea. It only happens if the stockholders and management think there is money to be made in splitting. I’m no financial genius, but a split would allow each side's management team to better focus and hopefully compete in their market space. Second, such a split would likely mean potential short-term stock valuation gains. Investors only act on the second reason, and we don’t control that, but you and I should care about the first reason, as improved products would be the result.

The rant

Microsoft won the PC and desktop world by providing a platform and ecosystem that enabled companies to be more productive than they were before. Today, Microsoft again says they want to empower customers to do more. But far too often, they lose track of the things that we actually do today, and why we do them.

I am utterly convinced that Microsoft has a focus problem. CEO Satya Nadella, busy driving Microsoft to the cloud, might view any focus issue as "why can't I get everyone focused on Azure?" However, I view it quite the opposite. I see employees that are often actively avoiding anything that looks like helping the products, and customers that want to deploy things on-premises rather than in the cloud. And many of the nitty details for this—details that IT depends on Microsoft to get mostly right—are getting destroyed.

Let's say, for example, that you are an IT admin that wants to deploy the latest Windows 10 release to hundreds or thousands of desktops. You count on Microsoft to help you make all those employees as productive as possible, and that means a seamless upgrade process. In the past, you would customize a standard OS image that adds and removes the required features, adds some common third-party applications which everyone uses, and locks down the product from a security perspective. You then dynamically deliver the additional apps that only some groups need directly to the provisioned machines using something like Configuration Manager or app virtualization. Sprinkle in a little Group Policy and we got ourselves a nice deployment, at least for older operating systems.

Not so much for Windows 10. We have lots of new things from Microsoft in the OS, but apparently few (if any) things concerned with the overall impact to the poor IT admin. It has been more than a year and a half since the initial release of Windows 10, and we are still just getting to understand what is needed to reliably remove all the non-enterprise crud (like Candy Crush). We rely on a few Microsoft employees taking pity on us by blogging (on their own time) about how the OS works, because it just isn't documented anywhere anymore. (Incidentally, we now know that the modern app crud comes in two forms. One is in the image from Microsoft and you remove during imaging, but then there is another form of crud that Microsoft delivers from the Microsoft Store and only appears after the user logs in. The latter can also be prevented via Group Policy, but it turns out you need to hack the policy settings directly into the image  instead of setting via GPO because otherwise you'll still get a random few apps.)

And don't get me started on AD versus AAD and Config Manager vs Intune, the seemingly endless ways to roam user stuff between OS's that don't work, and how the heck is anyone supposed to deploy Windows 10 to the masses from Azure.

With two releases a year, what we know and what we have to do changes every six months, and it takes at least three months after the release for anyone to have a clue what to worry about. There even was a case where Microsoft bundled a third-party security app with a known security flaw (with a 16-month old patch available). Windows as a Service is not making the enterprise more efficient yet—I believe it is having the opposite effect.

And while it would be unfair to blame Microsoft for Meltdown and Spectre, the chaos of the updating process that followed has to give everyone a reason to rethink the idea of “Windows as a Service.” Not relying on a single “third party” for our security needs is a fundamental tenet of good security practices.

I see many try to stay on one version as a “long-term” strategy. But that means 18 months of support from the initial day of release (now extended to 24 months temporarily). But it might take you from nine months to a year to roll that release out, leaving little time before it is unsupported. Yes, we don’t have to spend a lot of time looking at the app compatibility as the changes to the platform are small, but discovering all the undocumented and under-documented changes in the OS does not leave enough time for a supported rollout.

My solution

If I ran the world, I would be to split the company up into two independent parts. Yeah, this isn’t happening, but it is fun to dream about.

So how would I split up Microsoft? It's not so easy because Microsoft is so huge with lots of interdependent parts. There isn't a single A versus B that doesn't have a lot of overlap and things that don't fit in either category. But here are some potential strategies that you can take. I will describe these and give a shot at what might be included on each side of the split. The examples are not intended to be complete, but to highlight how I would see some of the parts fall out.

In each case, there are areas that fit on each side, as well areas that I call “in play.” By in-play, I mean that not only are there reasonable arguments for the area to be on one side or the other, we might also consider putting it in both sides and let them diverge the area as best matches their needs, or maybe spun off as a third thing.

Cloud versus on-premises

Initially, this makes the most sense, but only before you start digging into the details. But let’s try to get the big picture right and not let inconvenient smaller details get in the way! It might be easy to think of this split as the New Microsoft vs the Old Microsoft, but that would be very unfair, so instead I use “MicroCloud” and “MicroEnterprise.”

On the MicroCloud side, you have Azure, NanoServer, AzureAD, Office365, Dynamics, MDM/Intune, and OneDrive. (While there could be an argument for Office 365 to live on the MicroEnterprise side, the Office 365 story is the best example of Azure services, so let them run with that. If you are still running your own Exchange server on-prem, well, then you deserve to be lumped in with the folks still running Lotus Notes.)

On the MicroEnterprise side, you have Windows 10, Windows Server, Hyper-V, Active Directory, ConfigMan/MDT; Surface, Xbox, and other hardware; and things like roaming profiles, folder redirection, and UEV. (You might say OneDrive could belong with these last few items, but that clearly belongs on the cloud side.)

There are a few things in play. RDS could be on either side, but I lean towards this being on the MicroEnterprise side, since I place both the Desktop and Server OS's there. Argue amongst yourselves.

Developer tools and language could be on either side, but if I had to choose, again I would choose the MicroEnterprise side. Maybe this is the best candidate for a third company? If so, there would have to be some up-front agreements to ensure the third company is preferred by the others in return for their being able to leverage the tooling they require to build their stuff.

Server versus desktop

This is more of the traditional way that we viewed Microsoft in the past. It should be a little easier to understand, and much easier to implement than the cloud / on-prem model. On the “MicroServer” side you obviously have Windows Server, Azure, AzureStack, and Intune. On the “MicroDesktop” side, you have, well, Windows Desktop.

Everything else is in play, including Hyper-V, ConfigMan/MDT, Office, and Developer Tools and languages. Both sides need Hyper-V (even if only for containers). I'd probably want to see this treated as a joint venture or maybe open sourced (but then we'd know just how much of Xen is in there). I'm not sure either side would want ConfigMan/MDT, but we sure as hell need it. By default, it slides to the MicroDesktop side.

In this kind of split, maybe Office needs to be a third company? Splitting the Exchange or Cloud side separately from the client makes little sense right now. Developer Tools and Languages would also be better as third/fourth company in this kind of split. It never would belong solely on the MicroServer side, but could be solely on the MicroDesktop side.

Products vs services

We can also view it as a product versus services kind of split. This isn’t just cloud versus on-prem, it is perpetual license model versus subscription based. (And probably directly leads to the death of the perpetual licensing for things like Office.) It also probably flies in the face of where Microsoft is heading on licensing for the desktop and possibly servers, but maybe that is what you want?

On the “MicroServices” side, you have Azure, Intune, Office 365, Dynamics, and Developer Tools, and on the “MicroProducts” side, you have Windows Desktop and Windows Server.

Notes and conclusions

As part of any split, there are portions that could just be sold off out-right. But I am guessing this would probably happen just naturally as part of the breakup. Does Microsoft really need SharePoint? Probably not, and someone would probably want it if it became available.

Adjusting to technological change is difficult and we must always remember not to fear change, but to embrace it. Ultimately, we will be doing much of our corporate computing via cloud services, but those services have limitations in maturity, scope, completeness, and their ability to integrate with existing systems. Enterprises must both embrace the future, but make sure that they can be as productive and secure with what is available today. 

A split may not really be in the cards, but I believe that the enterprise could be better served by a Microsoft focused more on our needs right now.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.