Modern IT Management Defined: DevOps, ITIL, Cloud, Agile, or All of the Above?

What if I told you that you had to take your management platforms and start over, but this time you needed to plan for the next generation of how you'd work with your teams.  What if I told you that you needed to re-address how you dealt with your operational lifecycle, development, and release management.  This is what my team and I did over the last several months.  We decided that we'd look at what the management landscape will look like years from now and apply those concepts to the tools being released by Microsoft for the cloud-centric world. 

You might say, "well, I've seen this all before in framework XYZ".  What I propose is that historical frameworks are all part of the same story, just different angles told at different times in the maturity.  The frameworks don’t always agree tactically, but they always settle on the macro-goal of delivering superior services to the business.  A framework is written at a particular time for a particular group of people and as technology capabilities evolve, the way we solve problems will evolve along with it, although the concepts may be similar.  Instead of using these historical terms you'll hear me talking about new ones like "Modern Management", "Modern IT", "Modern Development", as ways of abstracting from the way we've done things before but not forgetting it.  This will allow us to discuss the ideas with a new language, which will then let us return to our original language with a newly informed perspective.  

First, let me present the core tenants of Modern Management:

• Defined.  The concept of "service management" is still important.  We still need to define what we deliver to the business, why it is valuable, and what it costs, regardless of who deployed it or decided it was a good idea.  The idea of service management still is necessary to dictate how we execute on delivering IT functions to help a business be successful.  This also means that the role of business analysts in managing the requirements capture process important.

• Value.  The applications we build or buy require a value-driven approach to managing the application lifecycle.  In many cases this has included the transition to "agile" but regardless of the methodology requires a more direct value stream to the business and giving the CIO the ability to manage to that value stream.

• Code.  The transition that is occurring is that almost everything is "code" or more-so a digital asset, whether it is infrastructure, configuration, or the application itself.  The assets of the organization are less the physical assets and more often are information and work product.  This makes it version controlled, stored, validated, and secured.  This transition will be intuitive for developers, but less-so for infrastructure, who is used to having retained knowledge and work plans vs. defined configurations.  The successful operational groups will be those that adapt to “infrastructure as code” because they start to address what they build with the new technology landscape’s language. 

• Cloud.  The assumption for modern management is that we are managing in a "cloud", which could be a public cloud, or our own on-premise cloud.  This is defined as having control around the perimeter of the management "space", meaning you can talk to the container of all the configuration items, vs. having to "scan" for them.  In programming terms, think of a cloud as an "object" with "classes" of configuration items.  A cloud may have servers, network devices, gateways, websites, etc. but they can always be "queried" from the cloud container.  This also includes SaaS based applications, which more and more can be "queried" vs. just tracked and managed.

• Policies.  The Modern IT ecosystem will be one that continues to have policies, but those policies will declaratively implement a configuration state.  The Modern Management tooling is built to leverage a policy to implement a control necessary to protect the environment.  The idea that "you need to validate something is backed up" become irrelevant, because you defined a policy that tells the container that it needs to be backed up. 

• Declarative.  The biggest infrastructure difference in Modern Management environment is that the configuration is declarative and idempotent.  A declarative configuration is one where you define as code an intended configuration and the configuration is then deployed to a target environment.  The state of indempotence is when that configuration is maintained and redeployed, regardless of manual changes made on the target system.  The idea behind idempotence is it increases level of confidence that the deployed infrastructure matches the intended infrastructure. 

• Continuous.  The most successful modern management is one that facilitates continuous deployment, meaning that the value is delivered to customers as soon as it is created.  Enabling continuous deployment requires automation, declarative configuration, and continuous testing.  The automation of process activities, such as release management, allows for human activity to be removed from a process, allowing for a process to be streamlined.  This doesn't mean that humans "go away", but does mean they move up the value chain of what is being delivered.  The closer an organization gets to successful continuous deployment, the less errors exist within a process and the faster value can be provided.

• Visible.  The management of cloud-scale applications means that the way we "monitor" applications change.  The days of "sending alerts" to manually resolve errors are replaced with idempotent infrastructure, and continuous deployment.  These applications produce bugs and errors that need to be resolved and in order to understand them at cloud scale we need visibility in the same way that a business understands its loan portfolio, an human body, or stocks.  Visibility lets us understand our system and build one which is self-maintaining in as "simple" of a manner as possible.  In a way, applications under modern management become less "intelligent" and more repeatable.

• Feedback.  The loop of error into our IT management space is as important as ever, but instead of more complicated we're going to make it more direct, faster, and more human-centric.  Modern IT is NOT automated IVRs, know-nothing help desks, and 6 month long requirements gathering sessions.  Feedback should be captured in appropriate channels, whether it is an incident or bug, and sent to the appropriate expert through as direct a channel as possible.  This doesn't mean that everyone goes to "Tier 3" immediately, but it does mean that we enable a "human" experience that is aided by all the qualities we've discussed above.  For instance, if we have a bug identified from our public website and it is logged into our customer case management system, why do we require a separate IT service tool to get it to another separate bug tracking list?  What if we could get it to the bug list faster, so the value-stream can run faster?  That speed to execution is what Modern Management is all about, whether it is bugs, features, or incidents. 

• Requestable.  The management of an effective IT services makes it simple to understand and request to the stakeholder who is interested in it.  This has traditionally been provided through an IT service catalog, which continues to serve its purpose.  However, IT cannot assume it will always own the consumption layer and instead needs to build the necessary management into the operational process of each tool by gathering state vs. always controlling provisioning.   For instance, a public cloud environment likely will not be controlled by an on-premise service catalog and instead is gathered after provisioning and controls are built around the container and the control plain.  The point is that IT services need to be both requestable and managed at the same time.

The tenants of the Modern Management ecosystem help us to understand how we build a modern ecosystem for any IT environment.  To explain the framework we're going to use an ALM term-style and show where ITIL service functions factor in.  We'll also show how this framework can be either tooling agnostic, or Microsoft-centric. 

The following is a common ALM framework used in DevOps conversations, focused on the big four phases of operating any IT service.  I'm starting from the framework of ALM because it represents the change occurring within IT to become more value driven for the business and faster at delivering.  This is sometimes called "Lean IT", where Lean principles are applied to IT functions. 

The stages of the ALM lifecycle are:

• Plan
• Build
• Release
• Operate

You'll see in the following where the ITIL framework factors into the ALM lifecycle and how both frameworks do match up, although many ITIL processes will see a reduction in manual effort and prominence as activities are automated.  You'll see how the service management frameworks exist within ALM:

• Service Strategy
• Service Design
• Service Build (not ITIL term)
• Service Transition
• Service Operations

I covered these relationships in detail in the Microsoft Virtual Academy series "DevOps to ITIL". 

How does tooling fit in?  If we look at this from a Microsoft ecosystem, we'll see two principal tooling options, but one which is essentially cloud-centric.  In the following we break out the tools between an on-premise scenario and a cloud scenario.  The scenarios are:

On-Premise:

• Team Foundation Server
• System Center

Cloud:

• Visual Studio Team Services
• Operations Management Suite
  (with potential System Center integration)
• ServiceNow or Dynamics CRM with ITSM

I'm finding more and more companies interested in moving completely to the cloud for their management services, meaning the latter is going to be very exciting indeed.  To learn more about cloud-based modern management, watch our video here.

In the next coming months you'll see us blogging more about Modern Management, its implications, and approaches.  This will include talks about ALM, OMS, ServiceNow / Dynamics, and System Center.  The opportunity is whether on-premise, or in the cloud, you have an opportunity to transform how you deliver and the tools you use to do it.

Cheers!

Nathan Lasnoski