Comparing Office 365 releases to the measured pace of on-premises software

The concept of a minimally viable product (MVP) is understood differently. Some hold that it's the version of a product that includes sufficient functionality to prove its worth. The code is functional and demonstrates what it's designed to do. It can be used to get work done. And then there's the view that an MVP is just enough to show what might come in the future, if all goes well. Sometimes I don't know what view is held by the Office 365 team. Applications and features appear and I wonder "how did that get through testing" and then improvements occur rapidly until the code that you use a couple of months later has little resemblance to the starting point. It's all very strange when you come from the on-premises world.

Experienced administrators at companies that decide to move some workload from on-premises to the cloud are confronted by many challenges. I’ve covered some of those in recent posts, such as the lack of advanced training and figuring out how to cope with service outages.

Understanding how Microsoft releases software into Office 365 also causes brows to crease. It’s not just a question of losing control about when updates are applied, a factor that tends to be commented upon from time to time. By now, everyone accepts that when you sign up for a cloud service, the software running in the service will be updated and you have to accept that this is the modus operandi. Rather, the issue seems to be understanding the words Microsoft uses to describe software availability. Let’s try and put this into words that the on-premises community understand.

Ever since Microsoft started along the journey to produce enterprise software with Windows NT, they have operated beta programs to have some customers test new software before final release. Some product groups are better at running these programs than others. The Exchange team, for instance, has long had a well-organized Technology Adoption Program (TAP) designed to have hundreds of thousands of on-premises mailboxes run new versions of Exchange in production before the software is released.

Over those years we have become accustomed to see major new versions of products released every three years or so. The exact date when a product like Exchange, SharePoint, or SQL is “released to manufacturing” (RTM) is not strictly determined by the maturity or stability of the software. Certain quality goals have to be reached, but often the release date is set for marketing purposes, such as the collective announcement of a “wave” of Office servers.

Of course, RTM is an archaic concept today. Where “gold” copies of software were once taken to manufacturing facilities to be turned into copies on floppy disks (installing products like Word for Windows from multiple floppies was such a joy), CDs, or DVDs, current releases are more likely downloaded from a Microsoft web server. Even so, RTM remains an important event in the product lifecycle that customers build plans around.

A year or so after a product reaches RTM, Microsoft usually releases the first service pack (SP1). Collective wisdom says that SP1 is the time when the software is safe to deploy into production. Early bugs have been fixed, People have been trained. Third party vendors have updated their software. Everyone has a warm feeling of comfort. And life is good.

The classic beta-RTM-SP1 cycle doesn’t exist in the cloud. Compared to the often slow progress made in deploying new software into on-premises environment, the cloud operates at frenetic speed. User interfaces change, new applications appear, features disappear or morph, and generally you have to keep your eyes open all the time to track what’s going on. Or at least, to try to.

The Office 365 cycle begins with preview, when select tenants are exposed to new software. This is like the on-premises beta phase because it has the same intention: locate bugs and make sure that functionality is stable. Some software (like Delve) stays in preview for months while some seems to hurry through in a matter of weeks.

The next step is First Release, which means that a tenant signs up some or all of its users to be exposed to software earlier than the norm. First Release allows Microsoft to expose software to more users while allowing tenants to access new functionality some weeks before it becomes generally available. Many changes can be made to an application like the task management Office 365 Planner before it is released to all.

A further complication is the way that Microsoft publishes announcements about new functionality around the time that code enters First Release. The way the text reads, you’d assume that a new feature will appear imminently. The truth of the matter is that you might have to wait for months before the software is usable. No amount of pretty screenshots can disguise this fact.  The recent announcement of the new Office 365 Admin Center is a case in point. Anyone who has attempted to use the new interface will tell you that it’s slow, breaks, and is missing functionality. But it’s been announced and that’s nice.

Eventually, the folks responsible for features consider code to be ready and the software joins the Standard Release of Office 365, at which time it is “Generally Available”. In on-premises terms, you could consider First Release to be equivalent to RTM and Standard Release to be SP1 because the tenants who enable First Release do the job of testing software to make sure it’s safe and works well before the vast majority take the plunge.

Which brings me to “flighting”, the term used to describe the deployment of software updates within Office 365. Different teams “flight” software at different times and to different tenants. It’s a side effect of operating a massive multi-tenant environment that is organized on a regional basis. The net effect is that your tenant might use different software than that used by another tenant in another Office 365 region, even if you both seemingly have the same version.

Although an analogy can be created between the on-premises beta-RTM-SP1 routine and the cloud’s cycle of Preview-First Release-General Availability, you can’t compare the way that software is rushed into Office 365 when it seems to be incomplete with the measured pace of on-premises releases. Office 365 Groups are a great example. A fantastic concept with great functionality was spoilt in the early days because it was released with lots of holes. Some, like support in Outlook 2016, have been filled since while others, like a soft-delete capability, remain missing. It seems that quality has lost out to urgency in the cloud. Today, it's all about staying one step ahead of the competition.

Understanding release cycles and the different terminology used in Office 365 is probably not one of the most pressing concerns of administrators facing the need to migrate workload from on-premises. However, like many things in life, mastering detail is a good way of ensuring that you’re less likely to be blindsided. Knowing what words mean and when software will turn up falls into that category.

Follow Tony @12Knocksinna

Discuss this Blog Entry 3

on Mar 29, 2016

I always though First Release was more Beta and Standard Release more RTM, but I can also see it now as RTM/SP1. What's in a name anymore, I guess. Maybe it's somewhere in between.

My question relates to Office 2016 for Office 365. A strange bifurcation has happened that MS seems to be ignoring. The streamed version of 2016 is getting new features on a regular basis. However, the MSI (traditional) version is not getting these features, just the usual monthly fixes.

When will the MSI version get these features? At SP1? Never (i.e. only with 2019)? I can't find MS ever commenting on this, though they do have copious documentation on the update scheduling for the streamed version. I can understand these features not coming in regularly, but never?!

This is a very strange situation, since they're BOTH Office 2016, just distributed in different ways. But they're now two different 2016s and diverging more every month.

on Mar 29, 2016

I guess the response might be something like "we are upgrading stuff in the back end so we have to keep the clients upgraded too, hence the changes to the streamed version. On the other hand, the MSI release is mostly used by folks with on-premises servers and there isn't quite the need to upgrade them so often - and besides, a lot of the changes we make to the streamed edition take advantage of cloud-only features."

on Mar 29, 2016

Yes, they may say that, though I would point out that some of the features that they're adding (like improvements to Power Query in Excel, or an additional color scheme) have nothing to do with the cloud. Also, Office 2016 MSI is definitely meant to work with the very same cloud (and does), so that argument might fall a little short. As you say, maybe most people using it aren't using it against 365, but MS didn't leave out the capability.

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.

Contributors

Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro. His latest books are Office 365 for Exchange Professionals (eBook, May 2015) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×