IT Agility to Realize Full Cloud Value - Evergreen Management

[Brian Levenson]

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.

Part 1: Introducing Modern Service Management for Office 365

Part 2: Monitoring and Major Incident Management

Part 3: Audit and Bad-Guy-Detection

Part 4: Leveraging the Office 365 Service Communications API

Part 5: Evolving IT for Cloud Productivity Services

Part 6: IT Agility to Realize Full Cloud Value - Evergreen 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. 

• Most of us think about change approvals and change advisory boards
• Some of us think about the physical act of applying changes to servers
• Others think about landing change on the humans and their desire to change their behaviors (like what we discussed in this blog post for IT Pros and what we will discuss in a forthcoming post for end-users)
• At least a few of us think about change through the lens of "management of change within my cloud tenant"
• Many of us think about "absorbing change from the cloud"
• And I'm sure you have even more...

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:

1. There is a class of change where we are confident that there will be NO impact to admins or end users.  For example, we may move a mailbox for load balancing purposes.  For this class of change, there is no need to communicate since there will be no impact to users or admins.  Any directed communications to IT Pros or end-users would just be noise that would distract from important communications.

2. There is a class of change where we are confident that there WILL be impact to admins and/or end users.  For example, if we change the behavior of a user's inbox with a capability like Clutter.  For this class of change, we communicate directly to IT Pros with directed communication to your tenant via Message Center (and via the Office 365 Service Communications API, Office 365 Mobile Admin, and SCOM Management Pack for Office 365).  For the full story on IT Pro Communications scenarios for Office 365, see this blog post.

Now that we've dealt with both extremes, we are left with two, middle-of-the-road scenarios:

3. There is a class of change where impact is underestimated, and Microsoft gains additional insight through the feedback gathered during First Release deployment.  For example, a minor UI change may not require downtime or obvious impact to a business, but it could generate more help desk calls than intended.  Once we are aware of impact for some customers, we learn from the experience and communicate to other customers through Message Center.  Minimization of customer impact is one of the beautiful things about deployment rings and first release. Microsoft learns and adapts in real time.

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).

And finally:

4. There is a class of change where your unique situation will result in impact for you, but nobody else (or very few others) are in the same situation, so we are not able to predict it.  For example, perhaps your order processing system has a firm dependency on the "free/busy" capability in Exchange Online and due to the way your application is written, perhaps there is a unique scenario where you see impact in your app when we deploy a new feature.  This class is an extremely small subset, but as all of us who have been in IT very long know, Murphy and his law are always lurking.  Even though this scenario is the anomaly, we should deal with it; let's discuss how to address the scenario with lightweight business process. 

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

1. Message Center posts (tenant specific IT pro communications)
2. Roadmap.office.com (general awareness of what's in development)
3. Blogs.office.com (news and announcements)

 3. For each item triaged, discuss the following:

1. How can the super-user and the super-user's department get great business value out of the new or changed feature?  (and how will you measure the value?)  Remember, our discussion about the future of IT this blog post
2. What issues could arise when the new or updated feature is introduced?  What could break?  Could it cause help desk calls?

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.