We’re back with another edition of the Modern Service Management for Office 365 blog series! In this article, we review the function of IT with Office 365 and evolution of IT Pro roles for the cloud. 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

 

———-

 

In this installment of the blog series, we will dive into the “Business Consumption and Productivity” topic.  The whole point of the “Business Consumption and Productivity” category is to focus on the higher-order business projects for whatever business you are in.  If you are in the cookie-making business, then the focus should be on making cookies.  The opportunity is to use Office 365 to drive productivity for your cookie-making users, to increase market share of your cookie business, or to reduce costs of producing or selling your cookies.  This category is about the business rather than about IT.  We all want to evolve IT to be more about driving those business-improvement projects.  However, in order for IT to help drive those programs with (and for) the business, we need to make sure that the IT Pros and the IT organization are optimized (and are excited) to drive the business improvements. We all need to look at the opportunities to do new things by using the features and the data provided by the Office 365 service to drive business value rather than looking at what we will no longer do or what we will do differently.  I always say that none of us got into IT so we could manually patch servers on the weekends, and none of us dreamed about sitting on outage bridges in the middle of the night.  On the contrary, most of us got into IT so we could drive cool innovation and cool outcomes with innovative use of technology.  I like the idea of using Office 365 as a conduit to get back to our dreams of changing the business/world for the better using technology.

 

 

For IT Pros

If you are an IT Pro in an organization who is moving to Office 365 (or to the cloud, or to a devops approach), I would encourage you to figure out where you want to focus.  In my discussions with many customers, I encounter IT Pros who are concerned about what the cloud and devops will mean to their careers.  My response is always one of excitement.  There is opportunity!  The following bullets outline just a few of the opportunities that are in front of us all:

 

• Business-Value Programs.  If I were a member of the project team for Office 365 at one of our customers, I would not be able to contain my excitement for driving change in the business.  I would focus on one or more scenarios; for example, driving down employee travel costs by using Skype for Business.  Such a project would save the company money, but it would also positively impact people’s lives by letting them spend more time at home and less time in hotels for work, so such a scenario would be very fulfilling.  I would focus on one or more departments or business units who really want to drive change.  Perhaps it would be the sales department because they have the highest travel budget and the highest rate of employee turnover due to burnout in this imaginary example.  I would use data provided by the Office 365 user reports and combine it with existing business data on Travel Cost/user/month.  I would make a direct impact on the bottom line with my project.  I would be able to prove that as Skype for Business use in the Sales Department went up, Travel Costs/user/month went down.  That would be real, measurable value, and that would be fun!  There are countless scenarios to focus on.  By driving the scenarios, I would prove significant business impact, and I would create a new niche for myself.  What a wonderful change that would be for many IT Pros from installing servers and getting paged in the middle of the night to driving measurable business impact and improving people’s lives.
• Evolution of Operations.  In most organizations, the move to cloud (whether public or private), the move towards a devops culture, the move towards application modernization, and the growth of shadow-IT will continue to drive new requirements for how Operations provides services to the business and to the application development and engineering teams.  As an operations guy, that is very exciting to me.  Having the opportunity to define (or at least contribute to) how we will create or evolve our operational services is very appealing.  In fact, that is a transformation that I got to help lead at Microsoft in the Office 365 Product Group over the years, and it was very fulfilling.  For example, how can the operations team evolve from viewing monitoring as a collection of tools to viewing monitoring as a service that is provided to business and appdev teams?  That is a very exciting prospect, and it is an area that will be more and more important to every enterprise over the next N years.  The changes are inevitable, so we may as well be excited and drive the changes.  We must skate to where the [hockey] puck is going to be rather than where it is right now.  See this blog series and this webinar for more on the monitoring-as-a-service example.
• Operations Engineering.  In support of the evolution of operations topic covered in the previous bullet, there will be numerous projects, services and opportunities where technical prowess is required.  In fact, the technical prowess required to deliver on such requirements likely are beyond what we see in most existing operations organizations.  Historically, operations is operations and engineering is engineering and the two do not intertwine.  In the modern world, operations must be a series of engineering services, so ops really becomes an engineering discussion.  Using our monitoring-as-a-service example, there will be a need to have someone architect, design, deploy, and run the new service monitoring service as described in this blog series. 
• Operations Programs. In further support of the evolution of operations†topic, there will be the need for program management.  That’s great news because there will be some IT Pros who do not want to go down the deep bits and bytes route.  For example, who is program managing the creation and implementation of the new service monitoring service described  this blog series?  Who is interfacing with the various business units who have brought in SaaS solutions outside of IT’s purview (shadow IT) to convince them that it is the business best interest to onboard onto IT’s service monitoring service?  Who is doing that same interaction with the application development teams who are moving to a devops approach?  Who is managing those groups expectations and satisfaction once they onboard to the service monitoring service?  Answer: Operations Program Manager(s) need to step up to do that.
• Modern Service Desk.  Historically, Service Desks have been about “taking lots of calls†and resolving them quickly.  The modern service desk must be about enabling users to be more productive.  That means that we need to work with engineering teams to be about eliminating calls altogether and when we cannot eliminate an issue, push the resolution to the end-user instead of taking the call at the service desk.  The goals should be to help the users be more productive.  And that means that we also need to assign the modern service desk the goal of “go seek users to help them be more productive.  As discussed in the Monitoring: Audit and Bad-Guy-Detection blog post, wouldn’t it be great if the service desk used the data provided by the service to find users who are having the most authentication failures so they could proactively go train the users?  That is just one example, but such a service would delight the user.  Such a service would help the business because the user would be more productive.  And such a change of pace from reactive to proactive would be a welcome change for most of us working on the service desk.  One of my peers, John Clark, just published a two-part series on the topic of Modern Service Desk: Part 1 and Part 2.
• Status Quo.  Some people do not want to evolve at all, and that should be ok.  If you think about it, most enterprises have thousands of applications in their IT Portfolios.  Email is just one example.  So, if the enterprise moves Email to the cloud, that leaves thousands of other applications that have not yet moved.  Also, in most enterprises, there are new on-premise components (e.g. Directory Synchronization) introduced as the cloud comes into the picture; someone has to manage those new components.  And, of course, there are often hybrid components (e.g. hybrid smtp mailflow) in the end-to-end delivery chain at least during migrations.  And if all else fails, there are other enterprises who are not evolving with cloud and devops as quickly.  There are always options.

 

The bullet list above is not exhaustive for Office 365.  The bullets are here as examples only.  My hope is that the bullets provide food for thought and excitement. The list expands rapidly as we start to discuss Infrastructure-as-a-Service and Platform-as-a-Service.  There is vast opportunity for all of us to truly follow our passions and to chase our dreams.  When automobiles were invented, of course some horse and buggy drivers were not excited.  I have to assume, however, that some horse enthusiasts were very excited for the automobiles too.  For those who were excited to change and evolve, there was opportunity for them with automobiles.  For those who wanted to stay with the status quo and keep driving horse-drawn-buggies, they found a way to do that.  Even today in 2017, there are horse-drawn-carriage rides in Central Park in New York City (and in many other cities).  So, there is always opportunity.

 

For IT Management

In the ~13 years that I have focused on cloud services at Microsoft since our very first customer for what is now called Office 365 the question that I have been asked the most is “how do I monitor it?  The second most frequent question comes from senior IT managers: How do I need to change my IT organization to support Office 365?  And a close third most frequent question is from IT Pros and front-line IT managers: How will my role change as we move to Office 365? 

 

Simplicity is a requirement.  As you continue on this journey with us in this blog series, I encourage you to push yourself to keep it simple from the service management perspective.  Change as little as possible.  For example, if you can monitor and integrate with your existing monitoring toolset, do so.  We will continue to simplify the scenarios for you to ease that integration.  From a process perspective, there is no need to invent something new.  For example, you already have a great Major Incident process you have a business and your business is running, so that implies that you are able to handle Major Incidents already.  For Office 365, you will want to quantify and plan for the specific Major Incident scenarios that you may encounter.  You will want to integrate those scenarios into your existing workflows with joined data from your monitoring streams and the information from the Office 365 APIs.  We have covered those examples already in the blog series, so the simplistic approach should be more evident at this point. 

 

From an IT Pro Role and Accountability perspective, it is important to be intentional and specific about how each role will evolve and how the specific accountabilities will evolve in support of Office 365.  For example, how should the “Monitoring role change for Email?  And how will you measure the role to ensure that the desired behaviors and outcomes are achieved?

 

What about the IT Organization?

Most of the time, when I get the IT organization question, customers are asking about whether they should reorganize.  My answer is always the following:  there are three keys to maximizing your outcomes with this cloud paradigm shift:

 

1. Assign granular accountabilities…make people accountable, not teams.  For example, if we miss an outage with monitoring, senior management should have a single individual who is accountable for that service or feature being adequately covered with monitoring.
2. Ensure metrics for each accountability…#1 will not do any good if you cannot measure the accountability, so you need metrics.  Most of the time, the metrics that you need for this topic can easily be gathered during your existing internal Major Problem Review process.
3. Hold [at least] monthly Rhythm of the Business meetings with senior management to review the metrics.  At Microsoft, we call these meetings Monthly Service Reviews (MSRs).  In these meetings, the accountable individuals should represent their achievement (or lack of achievement) of their targets so that senior management can a) make decisions and b) remove blockers.  The goal is to enable the decisions to be made at the senior levels without micro-management.

 

I tell customers that if they get those three things right, the organizational chart becomes about organizing their talent (the accountable people) into the right groups.  If one gets those three bullets right, the org chart does not matter as much.  However, no matter how one changes the IT Organizational chart, if one gets those three bullets wrong, the outcomes will not be as optimized as we want them to be.  So, my guidance is to always to start with these three bullets rather than the org chart.  The combination of these three bullets will drive the right outcomes.  The right outcomes sometimes drive an organizational chart adjustment, but in most cases, organizational shifts are not required. 

 

Think of it this way, if you move a handful of workloads to the cloud, the majority of your IT portfolio will still be managed as business-as-usual, so a major organizational shift just for the cloud likely will not make sense.  If I have 100 apps in my IT portfolio and I move 3 apps to the cloud, then would I re-organize around the 3 apps?  Or would I keep my organization intact for the 97 apps and adapt only where I must adapt for the 3 cloud apps?

 

The IT Organization is about the sum of the IT Pros

From a people perspective, the importance of being intentional and communicative cannot be overstated.  Senior management should quantify the vision for the IT organization and articulate how Office 365 fits into that vision.  It is important to remember that IT Pros are real people with real families and lives outside of work.  Many IT Pros worry that the cloud means that they do not have a job in the future.  That, of course, is not true.  Just as the centralization of the electrical grid did not eliminate the need for electricians, the centralization of the business productivity grid into the cloud does not eliminate the need for the IT Pro.  But just as the role of an electrician evolved as the generation of power moved from the on-premise-water-wheel to the utility grid, the role of IT Pro will evolve as business productivity services move to the cloud.  The electrician’s role evolved to be more focused on the business-use of the electrical grid.  So too will the IT Pro’s role evolve to support the business value realization of the business productivity services.  We intend to help with that journey in future blog posts focused on the Consumption and Productivity category. 

 

As senior management plans through the cloud, we recommend that they dig into at least the following role groupings to plan how each will evolve with respect to Office 365 workloads:

 

1. Engineering / Tier 3 / Workload or Service Owners…will we still support servers, or will we focus on tenant management and business improvement projects?
2. Service Desk Tiers and Service Desk Managers…will we support end-users in the same way?  With the same documentation?  Will our metrics stay the same, or should they evolve?
3. Major Incident Managers…will we still run bridges for the Office 365 workloads?  How will those bridges be initiated?  Will our team’s metrics evolve?  Given that many of the MSR metrics come from our Major Problem Reviews, is our team’s importance increasing?
4. Monitoring Engineers and Monitoring Managers…will we accountable for whether we miss something with monitoring for Office 365 workloads?  Or perhaps do we support the monitoring service with the Tier 3 engineers being accountable for the rule sets?  Should we focus on building a Service Monitoring Service?
5. Change and Release Managers…how are we going to absorb the evergreen changes and the pace-of-change from Microsoft and still achieve the required outcomes of our Change and Release Management processes?

 

As you spend time in the Monitoring and Major Incident Management content in this blog series, I encourage you to think through how implementation of the content may change things for the IT Pros using that example.  If you implement the monitoring recommendations, will it be simply business-as-usual for your monitoring team?  What about the Tier 3 workload team?  Or, perhaps is it a shift in how things are done?  Perhaps for your on-premise world, the monitoring team owns the monitoring tool and the installed Exchange monitoring management packs.  Perhaps in practice, when there is an outage on-premise, the Service Desk recognizes the outage based on call patterns, and then they initiate an incident bridge.  Perhaps once the bridge is underway, someone then opens the monitoring tool to look for a possible root cause of the outage.  Will that same approach continue in the cloud for Exchange Online, or should we look to evolve that?  Perhaps in the cloud we should have the Tier 3 workload team be accountable for missed by monitoring for any end-to-end impact for Exchange regardless of where root cause lies.  Perhaps we should have the monitoring team be accountable for the monitoring service with metrics like we describe here.   And perhaps we should review both the Exchange monitoring metrics and the Monitoring Service metrics (and any metric-misses) every month in a Monthly Service Review (MSR) with the IT executive team as covered in #3 above.  What I describe here is usually a pretty big, yet desirable, culture shift for most IT teams.

 

Some customers want hands-on assistance

As I mentioned, I get these questions often.  Some customers want Microsoft to help guide them on the IT Pro and organizational front.  In response to customer requests, my peers and I have created a 3-day, on-site course for IT Executives and IT Management to help them plan for the people side of the change.  The workshop focuses on the scenarios, personas and metrics for the evolution discussed in this blog post.  The workshop also helps develop employee communications and resistance management plans.  The workshop is part of the Adoption and Change Management Services from Microsoft.  Ask your Technical Account Manager about the “Managing Change for IT Pros: Office 365†workshop, or find me onTwitter @carrollm_itsm. 

 

Looking ahead

My goal with this blog post is to get everyone thinking.  I hope that the commentary was helpful.  We’ll jump back into the scenarios in the next post which will focus on Evergreen Management.