We're back with another edition of the Modern Service Management for Office 365 blog series! In this article, we review the evergreen cloud paradigm and considerations for an agile IT organization. These insights and best practices are brought to you by Carroll Moon, Senior Architect for Modern Service Management.
We have covered a lot of ground so far in this series from monitoring to sample code to the evolution of IT Pros and the IT Organization. Now, it is time to tackle "Evergreen Management."
What is Evergreen Management?
In our industry, we have the bad habit of using the same terms for different things. For example, what is a domain? The answer depends on the context of the question. Are we talking about DNS, Active Directory, or something else? "Change Management" is an example of a term that means different things to different people.
Let's simplify the discussion by adding specificity. For the purpose of this blog post, we are going to avoid any confusion and discuss "Evergreen Management" instead of "Change Management." We are defining "Evergreen Management" as the act of managing continuous evolution of features and functionality in the cloud to achieve business benefit while avoiding any adverse side effects. By the way, most people that I speak to are focused only on the "avoiding adverse side effects" side of the equation rather than on the "achieve business benefit" discussion. But as we covered in this blog post, the exciting future for IT Pros revolves around the business benefits. So, my goal is to help you spend most of your time on the business benefits while wrapping a lightweight process around the adverse-avoidance discussion.
The Release Continuum
In Office 365, there are many change classes and change types that we manage internally. With the customer lens, however, I prefer to simplify the discussion into four categories:
Now that we've dealt with both extremes, we are left with two, middle-of-the-road scenarios:
NOTE: One issue is that not enough customers are truly consuming the Message Center content, so even though there should be minimal impact with #3, often, there is broader impact because impacted customers did not consume the information. My hope with this blog post is that we fix that. I ask that everyone who reads this blog post will triage all Message Center posts (more about that topic below).
NOTE: Of course, if a change causes downtime or behavior contrary to the design, we treat it as an incident. The incident discussion is covered in this blog post.
Some Thoughts About First Release
In the early days of Office 365, we did not have the concept of First Release. Later, we delivered the ability to turn on First Release at the tenant level. Tenant Level first release is ok for testing, but the problem is that none of us users really "kick the tires" on our test accounts like we do our production accounts. Because users do not use test accounts in the same way, tenant-level First Release did not adequately address scenario #3 above.
Later, we added First Release Specific-User to aim at scenario #3. I much prefer this option. Unfortunately though, many customers do not use First Release Specific-User for whatever reason. And for those customers who do use it, most use it only for IT Pros. Here's the problem, if we re-look at scenario #3, the scenario is about your specific business applications and processes - something unique to you. Those processes are in your business groups (i.e. likely not in IT, but rather in marketing or some other business group). So, what I recommend is that every single Office 365 customer put a subset of their real, production, business-group users into First Release Specific User.
Here's the great news: most customers have super-users in each department and in each location already. For on-premise Exchange, for example, there are super-users who are "in-the-know" for what is coming. Those super users test new features in the on-premise service. Those super-users give great feedback to IT. We just need to tap into the existing super-user relationships for the cloud. Put those people into First Release Specific-User.
NOTE: Even if you do not put any users into First Release with your production tenant, you should still enable First Release for Specific Users and leave the list null. That way, your production tenant will get the First Release communications via Message Center.
Lightweight Business Process
Ok, so now you have First Release for Specific-Users enabled, and you have real business users in the list. That is great. Thank you! You are way ahead of the game now for scenario #3 above. What's next? I would recommend that you implement a lightweight cadence with those first-release-business-users as in the following example:
1. Establish a monthly cadence with the first-release-business-users
2. In the monthly meeting, triage the following data sources with your first-release-business-users
3. For each item triaged, discuss the following:
4. Ensure an out-of-band meeting plan is in place. If Microsoft notifies you of a new capability that will deploy prior to your next scheduled meeting, there should be a pre-agreed plan to have an ad-hoc meeting with the same agenda of "B" and "C."
5. Ensure that an easy-button is in place for the first-release-business-users to escalate directly to the right people in IT whenever they see something that may be a problem. Encourage those super-users to escalate early and quickly so that IT can get in front of any issues. Also, such seamless escalations will allow IT to escalate to Microsoft as needed.
Remember: you can consume the information in many ways, and ideally, as an enterprise, you will simply pull these communications into your existing monitoring tools and/or service management tools as covered this blog post.
My hope is that every one of you will take action to a) consume the information from Office 365 blogs, roadmap, and Message Center b) review the communications for business benefit and adversity-avoidance with your business users and c) to drive and measure business benefits of each new feature because success begets success like nothing else.
Next up: Service Desk and Normal Incident Management.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.