Back in the day, I would have killed for a tool like vCOps, an analytics tool that uses dynamic thresholds to make sense of the myriad activity metrics that exist in an IT environment. Without dynamic thresholds that identify normal behavior, admins like myself are forced to use static thresholds that never seemed to work quite right. Static thresholds tended either to be set too low, resulting in false positives, or too high, so that by the time they were tripped, the support desk had already started receiving calls from disgruntled users.

Tried, but Failed

• One approach I tried in order make sense of the cloud of data coming from multiple monitoring tools was to combine several metrics to get a more holistic view. Combined metrics also rely on static thresholds and are similarly plagued with false positives. But, they introduce the additional problem of having to try and figure out which of the underlying metrics actually caused the alarm to trip.

• Another approach I tried was using end-user experience monitoring, or end-to-end application monitoring. Instead of trying to estimate the performance of an application by looking at the sum of all of its components, I could instead look at the simulated response time for the typical user and transaction. Another end-to-end monitoring tactic was to employ passive application sniffers that would record the response time of transactions. But with both approaches, I was still dependent on static hard thresholds that were invariably exceeded on a regular basis. For example, it wouldn’t be unusual for an application to exceed its 2-second response time goal during regular periods of peak usage. So I had to know when it was normal to exceed the allowed threshold.  In other words, I had to know when to ignore the alarms.

• Static thresholds also impacted performance monitoring. Other admins would ask, “Did this just start?” or “Is the performance issue the result of a change in the environment?” The monitoring tools wouldn’t provide the needed data. So we would have to roll up our sleeves and try to figure out what happened. Meanwhile the system would be down or just struggling along. Many times the problem would go away after a certain amount of time or after a reboot, only to resurface another day.

In the end, except for a few cases, we just turned off the monitors and alarms.

A Better Approach

That is why I would have killed for vCOps. vCenter Operations Management Suite is built on an open and extensible platform that works with physical and virtual machines.  It is a single solution works with a variety of hypervisors and fits either on-premise or public cloud environments.

It collects and stores metrics over time and works behind the scenes to establish dynamic thresholds. It employs around 18 different algorithms that compete to best fit any one of the millions of metrics it can track. Some algorithms are based on time intervals and others on mathematical models.

With vCops I can now designate specific metrics as KPIs for additional granularity. For example, the tool would learn that it is normal for response times to be in the 2 to 4 second range on Monday mornings, but if it exceeds the normal range, above or below, I can now have a KPI Smart Alert generated.

Another thing that I can use is the Early Warning Smart Alert that detects change in the environment when too many anomalies occur, such as when too many metrics are outside their normal operating range. I can use the various dashboards and detail screens to view the metrics over time, so that instead of wondering whether the issue is the result of a capacity trend or something changing / breaking, I can look and quickly see, “Oh, there’s the problem. Something happened at 1:15 on system X that caused this service to really slow down.”

Now, after more than 20 years in IT, I can finally start to use the multitude of metrics that have been there just waiting to be leveraged.

To get the most out of monitoring tools consider using vCops range of capabilities, including:

• The ability to track KPIs within the infrastructure, such as Disk I/O or CPU Ready, or leverage the vSphere UI so that you know if your infrastructure has additional capacity or not.
• Various KPI Super Metrics within the application stack (e.g. cache hit rate or available memory) that alert you when things are outside of a normal range.
• The power to see exactly how an environment is performing on a given day, and the ability to isolate which component is the source of the issue.
• The means to track and report the relative health of not only your components, but your services as well, without having to view everything as up or down at the component level and guess if the application or service is OK.

And it’s all possible because we can now actually use the lowly metric.

For future updates, follow @VMwareCloudOps on Twitter and join the conversation using the #CloudOps and #SDDC hashtags.

There are plenty of candidates: provisioning; resource scaling; workload movement. And what about automating responses to event storms? Incidents? Performance issues? Disaster recovery?

To answer the question, though, you need to first establish what you’re looking to gain through automation. There are two basic strategic approaches to automation, each with specific value propositions:

• task automation – where the proposition is more, better, faster
• service automation – where you’re looking to standardize and scale

In my last post, I looked at how the automation strategy determines your HR needs.

In this post, I’ll highlight a simple economic model that can be used to cost justify task automation decisions. Next time, I’ll refine the math to help analyze decisions about what to automate when pursuing a service automation strategy.

The Cost Justification for Task Automation – the Tipping Point

From a cost perspective, it makes sense to automate IT tasks if:

• the execution of the automated task has a lower cost than the execution of a manual version of the task.
• the automated process can be run a large number of times to spread the cost of development, testing, and ongoing maintenance of the automation capability.

Brown and Hellersten at the IBM Thomas Watson Research Center expressed the idea in a simple model.[1] It compares the fixed and variable costs of manual process versus automated version of the same process. The cost calculation is based on the variable N, which represents the number of times the automated process will execute.

IT organizations typically automate existing manual processes. So we consider the fixed cost of developing the manual process as part of the automated process costs.

With these two equations, we can solve for an automation tipping point Nt. Nt, then, is the number of times a process is executed at which it becomes cost effective to automate the process.

Changing the task automation tipping point

Now, what actions could we take that would shift the tipping point? We might:

1. Reduce automation fixed costs. If we can drive down automation fixed costs, automation becomes economically attractive at lower number of process executions.

Automation fixed costs include purchasing and maintaining the automation platform, as well as standardizing process inputs, ensuring the process is repeatable, developing policies, coding automation workflow based on those policies, testing each automation workflow, documenting error and establishing exception handling procedures. We also need to add in ongoing maintenance and management of automation routines that may change as IT processes evolve. If any of this work can become highly standardized, Nt will be lower, which will in turn increase the scope of what can be further automated.

2. Minimize automation variable costs. Reducing automation variable costs also makes automation attractive at lower number of executions.

Variable costs include both the cost of each automation execution and the cost of managing exceptions that typically are triaged via manual resolution processes. With a very large number of process executions, the variable cost of each incremental automated process execution would essentially be zero except for costs related to handling exceptions such as errors and process failures. Standardizing infrastructure and components configurations, and thus management processes, reduces exceptions and lowers the tipping point.

3. Pick the right tasks.  Automating manual processes with high cost of execution is an obvious win. The slower and harder the manual task, the higher the cost of each execution, and the lower the tipping point for automating the process.

Benefits other than cost reduction

Automation offers benefits beyond cost reduction, of course. In the cloud era, demand for agility and service quality are also driving changes in the delivery and consumption of IT services.

Automation for agility 

Agility is key when it comes to quickly provisioning a development or a test environment, rolling it into production, avoiding the need for spec hardware, accelerating time to market and reducing non-development work. Typically, 10-15% of total development team effort is spent just configuring the development environment and its attendant resources. Automation can make big inroads here. Note, too, that agility and speed-to-market factors, which generally have a revenue-related value driver, typically aren’t included in task automation tipping point calculations.

Automation for service quality

Automation promises greater consistency of execution and reduced human error, quality-related benefits that also aren’t factored in the calculations above. Downtime has a cost, after all. Deploying people with different skills and variable (and often ad hoc) work procedures at different datacenter facilities, for example, directly impacts service quality. Automated work procedures reduce both human error and downtime.

Back to the math

Really, we should add the quality-related costs of error and inconsistency to our manual variable processes costs, since they mirror how automation error recovery costs are calculated.

To account for the manual process quality costs, the tipping point calculation could replace “Manual variable costs” with “(Manual variable costs + Manual quality costs)” in the denominator.

Doing that would further lower tipping point number that justifies automation.

Here’s how I sum up these concepts applied to task automation environment:

• If a manual task is easy, it is difficult to justify automating it because the tipping point number will be very high or never reached
• If a manual process is hard and error prone, it is easy to justify automation i.e. Nt is a low number
• If there are a lot of process exceptions that result in a large percentage of process executions that result in a manual intervention – it makes it harder to justify automation
• If automation routines are hard to program, or take a lot of time and effort to tweak and maintain over time due to ad hoc run book procedures – it makes it harder to justify automation

In the next post, I’ll explore the economic justifications for automation under a service automation strategy.

Follow @VMwareCloudOps for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags.

We kick-started #CloudOpsChat with the question, “Is increasing automation and virtualization good or bad for your career?”

Our co-host @Andrea_Mauro was the first to answer, making the point that IT is always evolving and you can’t realistically stay static in knowledge and skills. @KurtMilne agreed with Andrea, adding that more standardization and automation will help to foster the Industrial IT era and move away from the “artisanal” IT era, which is good for IT careers. Co-host @NigelKersten emphasized that IT needs to automate or prepare to be in an evolutionary dead-end in ops roles, adding that the business demands of today are too great not to do so. @andrewsmhay echoed Nigel’s thoughts, saying that the increase in automation and virtualization is good, taking a “survival of the fittest” standpoint – IT needs to evolve or perish. @ckulchar added to both Kurt and Andrea’s points, noting that IT needs to shift the focus to enabling app teams to effectively use cloud and not just port existing apps. @jakerobinson also joined the conversation, saying that increasing automation and virtualization is necessary in order to balance IT cost with capability.

With the discussion in full swing, we took to our next question: “How exactly does increasing automation change your job?”

@NigelKersten stated that increasing automation changes many roles, not just IT operations. @KurtMilne chipped in as well, saying that an increase in automation frees up your time to work on things that really matter, providing more value to your business. @jakerobinson had a similar opinion, explaining that automation eliminates human error, which means less unplanned work that he would have to take care of at a later time. @randwacker added that automation also allows businesses to move faster and be more innovative, which is a key value of Infrastructure-as-a-Service and cloud. @lamw offered a great analogy in answering this question, saying that not automating your infrastructure is like ignoring the existence of the assembly line in manufacturing.

We then asked our audience, “Do you think abstraction and better tools decrease the need for deep expertise?”

@DuncanYB thought so, but also added that abstraction does not result in a decrease of deep expertise, as you still need to build a strong foundation. @randwacker agreed with Duncan, as long as the tools package expertise with it. @KurtMilne added that automation and abstraction will definitely reduce the need for everyone to read 2-inch thick manuals. He made a point to say that someone will still need to read the manual in order to set up the automation, but from there others will be able to use the automation without the reading. @wholmes noted that deep expertise is needed in the development lifecycle of a solution, regardless of abstraction or not. He added that abstractions lessen the need for deep expertise in the operational phase of a solution. Both @NigelKersten and @KurtMilne agreed with @wholmes, saying that automation pushes expertise earlier in the service lifecycle.

Next, we asked our participants, “Do you think today’s cloud administrators need programming skills?”

@randwacker answered yes – cloud admins do need programming skills, but that’s quickly getting packaged. @DuncanYB hoped that they would not need programming skills, as he thought scripting was already difficult enough as it is. @NigelKersten pointed out to Duncan that programming could be easier than scripting, as better tools and interfaces make it easier to use the work of others. @jakerobinson said that cloud admins definitely need software development skills – from consuming APIs, as well as understanding agile methods. @ckulchar agreed, and added if cloud admins don’t learn the fundamentals of development, developers will learn cloud admins’ skills, resulting in a need to differentiate themselves. @wholmes said he hoped that cloud admins wouldn’t be required to have programming skills, but it all depends on the cloud.

From there, we asked participants, “Is PowerCLI better than your average scripting language?”

Both @lamw and @wholmes had similar viewpoints, saying that it may or may not be better, but that it depends on the background, which our co-host @Andrea_Mauro agreed with. @lamw chipped in that you have to use the right tool for the right job, and that the key is: if there is an API, you can automate it using a variety of tools – an idea that both @virtualirfan and @jakerobinson supported.

Staying with tools we then asked: “What are the advantages of managing compute, storage and network resources from a single tool?” 

Our co-host @Andrea_Mauro answered that one of the main advantages would be having complete control of all the resources. @NigelKersten added that network/storage configuration being attached to services allows for easier workload migration. @KurtMilne asked if it is reasonable to expect a single admin to effectively manage compute, storage and network, to which @wholmes said yes, but only to provision. If it were end-to-end, it would not be reasonable. However, @kix1979 said that in the current IT environment, no single tool can manage compute, storage and network resources.

We concluded our discussion by asking, “What do you think is the one skill all IT admins should learn this quarter?”

@lamw offered a short and sweet answer: Automation. @maishsk said that IT admins should learn Puppet/Chef, or even both. Co-host @Andrea_Mauro echoed William’s sentiment by saying that they should learn automation with good framework, which @wholmes and @KurtMilne agreed with. Both @kix1979 and @jakerobinson believed it would be important for IT to learn the business value and costs of running IT/services.

Thanks again to everybody who listened or participated in our #CloudOpsChat, and stay tuned details around our next #CloudOpsChat! Feel free to tweet us at @VMwareCloudOps with any questions or feedback, and join the conversation by using the #CloudOps and #SDDC hashtags.

Delivering a set of standardized infrastructure services is a critical dependency as IT becomes more service oriented. Getting application owners who are used to custom infrastructure to agree to only use standard service configurations may be the defining problem of the cloud era.

The lifecycle of defining new service elements, adding them to the service portfolio, then formally releasing them for use by adding to service catalog is the very heart of the problem when getting multiple developers and application owners to agree to use standard services.

The process is critical.  And the process must be streamlined and oriented to the needs of users and funders of the service, and not the internal machinations of the IT organization.

However, traditional ITSM Service Portfolio Management is a cumbersome process geared to the needs of the IT organization.  IT includes numerous points of IT management sign-off, and the process is not optimized for actually developing and releasing new services into use.  The traditional approach tends to be heavy on oversight, and light on actually doing work. This approach reduces agility and wastes scarce resources. Not good in an era where increased agility and reduced operating costs are key measures of success.

Things are different within a virtual cloud ecosystem like VMware’s vCloud Automation Center (vCAC). With vCloud Automation Center, authorized users can access standardized services through a secure self-service portal, as vCAC acts as a service governor to help enforce business and IT policies throughout the service lifecycle. In this environment, a radically simplified design lets IT service managers focus their energy on the needs of users and funders and helps them get their work done with minimal internal IT process overhead and friction.

vCAC simplifies portfolio management in two main ways:

• Policy-based service definition – Through vCloud Automation Center, users can request and manage their compute resources within established operational policies – cutting IT service delivery times. Users can build specifications into vCAC that contain the automation policies that specify the inputs needed and actions required to maintain your portfolio.
• Improved service transition – Moving a new service out of the portfolio and into the catalog where it can be used requires keeping the portfolio and catalog elements up-to-date and aligned with each other. With vCAC, release and ongoing management functions are built into the tool set, and thus both automated and massively simplified.

One way to think of what’s changed here is in terms of oversight versus enablement. Traditional ITSM can be geared as much as 80% towards oversight, with just a 20% focus on the people who actually go and do the work. The vCAC approach flips that around.

Oversight is still essential, and it’s built in to the new model.  Prior to vCAC, traditional ITSM involved significant initial investment, top heavy input requirements, with repetitive multiple touch points to senior management., vCAC presents fewer, better-designed gates to your workflow, so you can work both safely and fast while gaining the agility that comes with a true cloud environment.

It’s About Standardization

The key to giving cloud consumers the services they want as quickly as possible, while still keeping the necessary corporate controls in place, is standardization.

Under vCAC’s blueprint model, service elements (e.g. backup, capacity, and provisioning requirements, security and other policies etc.) are preapproved to sit in the catalog and are thus ready to be deployed in new ways whenever they’re needed. In other words, if an item is in the catalog, and you have authority to access it, then you can provision at will – without having to go up the chain of command every time you want to respond to customer demand.

The result:

• Fast efficiency processes focused on quickly and efficiently delivering new services to users, so that users don’t feed the internal IT machine.
• Simplified processes with policy-based service definition capability and improved service transition, business agility and time to market.
• Automated interfaces between the service portfolio and service catalog, with minimal resources and overhead required.

And you do it with higher quality, and at scale. With a set of preapproved blueprints and policies, it’s much easier to address increases in either the volume or variety of demand that you want to meet, and do it in a way that is more deterministic and improves service quality over time.

What’s more, you’ve done all that while reducing your company’s overhead and the resources you need to draw on.

With the help of vCAC, your portfolio management is simpler, more agile, more efficient and faster-to-market, too.

This is the first in a series of posts we’ll be writing about service portfolio management in a vCloud ecosystem. Next up, we’ll go deeper in to the simplified, three-step process of vCloud portfolio management.

Be sure to follow @VMwareCloudOps for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags.

The quantity and variety of topics suggests there isn’t yet consensus on how the concept of standardization should be applied. But some of the submitted topics suggest that standardization of service definitions and infrastructure configurations is what makes innovation possible at the business process level – where it counts.

Related reading topics:

Monitoring Strategies in the Cloud by Michael Kavis
Michael Kavis takes a look at best practices when dealing with cloud, including standardizing as much as possible in cloud based systems so that a high level of automation can be put in place.

What Goes Around Comes Around Part 2: Is Standardization Still a Valid Strategy? By Theo Priestley
Standardizing business processes reduces innovation. Note – VMware paper submissions suggest that standardizing IT services and infrastructure enable greater business process innovation.

Resilience Engineering Part 1 and Part 2 By John Allspaw
Great insights on how resiliency, automation, and standardization are all tightly linked.

Follow us on Twitter at @VMwareCloudOps for future updates, and join the conversation using the #CloudOps and #SDDC hashtags.

There are two primary automation strategies. Shift your thinking to service automation in order realize the full potential of SDDC and hybrid cloud solutions.

Automating IT Services Is Not As Hard As You Think by Edward Newman
Your 1^st automated service provisioning effort should be a complete service that has big impact. Not automated provisioning of multiple VMs with manual storage and network deployment.

The Importance of Automation in Cloud Computing by James Bond
Good step by step summary of what happens during automated provisioning. Great advice to ask your cloud service provider for a detailed flow diagram or process description of what their automated workflow system is doing.

Making Change Management Your Cloud Computing and DevOps On-Ramp by Hank Marquis
Use your standard change process as automation on-ramp. This article includes a great list of specific measures that gauge maturity of your standard changes.

5 Benefits of Cloud Management by Tony Lucas
Automation can help IT organizations turn traditional hardware into a cloud platform, streamlining deployment while managing and scaling resources appropriately. Use management platform metering capabilities to better understand service costing.

Follow us on Twitter at @VMwareCloudOps for future updates, and join the conversation using the #CloudOps and #SDDC hashtags.

But those benefits don’t come (forgive the pun) automatically. Automation is an approach to achieve a goal. And your reasons for deploying automation greatly influence both the tactics you follow, and their  impact the people, their roles, and skills required to function in a more automated environment.

Strategy Impact on the Automation Manager

I recently spoke with the IT Director of a large multinational bank. As a leader in the IT Operations organization, he is creating a new ‘Automation Manager’ function.

Until last year, he’d been working to get key bank ITIL processes to level 3 or in some cases level 4 maturity, and he’d achieved a state of advanced operations which benchmarked well against peers. As part of that effort, he’d been deploying a group of ITSM process owners in a matrix organization structure with central process owners working part-time placed in various business units. That approach worked well.

Now, though, his focus has shifted from process maturity to process automation. Yes, the department had a foundation of mature and consistent process, created by expert staff. But to get to next level of efficiency, he told me, they needed to increase automation. To help with that, the director created a new role: the Automation Manager.

This wasn’t the first time that I’d heard about such a job. This particular conversation, however, highlighted various questions shaping the new role:

1. What type of automation? There are different types of automation: powershell script, cron job, workflow tool, policy based orchestration, configuration automation. There are the different activities that can be automated: provisioning, maintenance, scaling resources, proactive incident response. And there are different degrees of automation: automating just a few actions, partical workflows, or going end-to-end.
2. What is the job scope? Automation has a lifecycle: intake, classification, resources, version control, tracking benefits. What part of it does an Automation Manger own?
3. Where does the role fit in the organization?  An Automation champion ideally owns overall program, but is it also someone to whom others can turn for technical automation advice? The IT Director’s idea is to create a central role. But where does it fit? The ITSM process group? The technology team?

All of these questions had me stepping back and thinking at a higher level. The answers depend more on the strategic goals, and less on the tactics.. Given that, I think two primary automation strategies  frame decisions about the Automation Manager role.

1. Task Automation. Here, automation helps staff do existing work more, faster, better. With this strategy, the same people continue doing pretty much the same admin jobs they did before. The new automation manager becomes an overlay function that helps each admin use new tools to turbo boost their existing work.
2. Service Automation. Moving from a technology or infrastructure focus to a service orientation requires more standardization and automation. This strategy is about automating new processes that didn’t exist before. In many cases, automation enables workflow that wasn’t even possible in a manual process approach. The automation capabilities support admin roles that may be largely new, or may be a combination of previously separate roles.

The Value Proposition Tradeoff

One way to think about these options is by revisiting the basic tradeoff between speed and efficiency, versus customization.

Consider the analogy of the clothing business. If your customers want affordable clothes now, you can offer “off the rack”  in standard sizes. If they don’t mind paying more and waiting, you can offer  something custom-made. They’re simply different value propositions.

In the clothing business, there are uses for automation that help tailors deliver custom work faster, with fewer errors. But automation can also be deployed as part of a strategy to create goods in standard sizes on a massive scale. They are two different automation strategies.  The role of the automation manager is either help tailors improve custom work, or build a factory to mass produce standard sizes.

Similarly IT can deploy automation to help execute existing work faster, better, and with less effort. Or IT can use automation to deliver highly standardized services at scale. Either way, if you’re clear about the strategy, the details about the Automation Manager role will come into focus.

For one, helping existing staff do more, better, faster, requires a role largely focused on implementing tools, training users, and offering support. For the other, building an IT factory that delivers standard “off the rack” services at scale, requires a role that is a process and systems engineer who builds and maintains factory robots that do the work.

Clearly, the IT Director I spoke of has a more, faster, better automation strategy.  What strategy do you have?

What can IT admins do to better position themselves for their new responsibilities in the cloud era? Find out by joining a live Twitter #CloudOpsChat, on “The Changing Role of the IT Admin” – Thursday, April 25^th at 11am PT.

We’ll address questions such as:

1. How does increasing automation change the IT admin job? #CloudOpsChat
2. Is increasing automation and virtualization good or bad for your career? #CloudOpsChat
3. Do abstraction and better tools decrease the need for deep expertise? #CloudOpsChat
4. Does a cloud admin need programming skills? #CloudOpsChat
5. What skills are needed for scripting vs. automation and orchestration? #CloudOpsChat
6. What specific automation skills do IT admins need today in order to meet the demand for virtualization and cloud technologies? #CloudOpsChat

Follow us on Twitter at @VMwareCloudOps for future updates, and join the conversation using the #CloudOps and #SDDC hashtags.

Users and business managers can now easily work around IT to procure a wide range of services from vendors on-demand, and get billed based on usage. So what can, or should, IT organizations do?

Here’s a quick summary of the key points from the discussion. Kurt and Kevin provide recommendations and solutions to avoid shadow IT activity, and to make cloud era IT operations as effective as possible.

Problem #1: Your business wants fast AND easy.

As IT evolves, users increasingly want immediate access to central IT resources and services. They’re adding agility requirements to the cost, performance, and service quality requirements that have traditionally driven IT strategy. How do you respond?

Solution: IT needs to shift away from building custom resource configurations for each application and take a more standardized approach – building a factory that can deliver self-service, on-demand access to a portfolio of “off-the-rack” services. Users will get the control and speed they want if they’ll agree to standard service configurations. They can get fast and reliable, but not custom.

Problem #2: Transparent Service Deployment

Increasing deployment options (physical, virtual, private and public cloud) are pressuring IT to offer solutions that are, as Kurt puts it, “fit for purpose,” in terms of duration, cost, quality, performance and business context. This suggests a need to  shift from a custom systems view, to a standardized portfolio view of both workloads and compute environments.

Solution: Deploy systems to an environment that is a best fit for a range of criteria. Collect attribute data during service requests, then use a policy-based system to make workload placement decisions. Enable automated provisioning that can cross boundaries and work with physical, virtual, and multiple cloud environments. Your business really cares about the cost, risk and quality of service. But if IT is responsible and accountable for performance, service quality, support, as well as security and compliance, it also needs to stay in control of workload placement and provisioning decisions.

Problem #3: “Run Time” Complexity

Modern application topologies and compute stacks are more complicated, and often more dynamic, than ever. As a result, many IT organizations are re-evaluating resiliency strategies from the ground up. In the past, we improved service quality by carefully controlling changes to a static environment. What do we do today?

Solution: In the cloud era, it’s better to assume that change will happen, and build systems to monitor and automatically respond to likely conditions, in order to deliver high quality of service. We need to shift from reactive incident response to proactive detection and preservation of services before outages occur. This sounds like a utopian vision. But it’s backed up by real solutions that let you start making powerful changes now – by leveraging a single platform for work across environments and across pre-production and production lifecycle phases.

Tip 1) Focus on performance, capacity, monitoring and analytics. Leverage intelligent analytics to identify conditions that predict pending disruption. Use the same capabilities to accelerate root cause analysis, determine the source of the pending disruption, then fix it before services are impacted.

Tip 2) Don’t forget to plan for new roles and skillsets needed in a policy driven and automated environment.  (Attend April 25^th Twitter chat on Changing IT Admin Roles hosted by Puppet Labs CTO Nigel Kersten and VMUG IT founder Andrea Mauro)

Problem #4: Workflow Variability

Ad hoc operations is a weak foundation for automation. Highly variable procedures for building or maintaining complex systems are neither repeatable nor deterministic. Exceptions drive up the manual response costs. And exceptions also reduce service quality.

Solution: Standardization and policy based automation is key for enabling a shift  away from variable and unpredictable “Artisanal IT” to predictable and reliable “Industrial IT”. Adopt a policy-based control strategy to guide workflow and automation. Start by setting basic policies, then look for process and run book procedures that require exceptions. Then eliminate the cause of those exceptions and standardize activities to fit policy.

Problem #5: Alternative providers have clearly marked prices

IT does not clearly price services, for both historical and structural reasons. It is certainly easier to fund IT based on project or flat rate business unit allocation. But 3^rd party cloud service providers offer service- and usage-based pricing, which is changing the expectations of users and IT funders. IT won’t be the preferred service provider for a business if its services are not priced for comparison. It’s time to act.

Solution: IT needs to enhance IT financial management. It needs to put systems in place that provide a service-based view of costs. It needs to fund operations at least in part based on services delivered. And it needs to offer pricing information at the point where services are ordered to enable cost comparison.

The good news is that IT has an insider view of business objectives and the unique needs of users. With improved transparency, and a portfolio of services that meet the needs of your business, IT has unfair advantage over 3^rd party service providers.

Round Up: By acknowledging and addressing these problems your business can offer effective IT operations in a hybrid world, and will possess the advantages needed to be the preferred service provider for your users and business managers..

For solutions that enable the approach that Kurt and Kevin were talking about, check out:

vCloud Director Learn more
vCloud Automation Center Learn more
vCenter Operations Management Suite Learn more
vFabric Application Director Learn more
vCenter Chargeback Manager Learn more
IT Business Management Suite Learn more

Want to learn more? Check out the webinar replay and follow us on Twitter at @VMwareCloudOps for future updates! Join the conversation using the #CloudOps and #SDDC hashtags.

Here are some interesting Friday reads related to standardization and the service definition process.

Putting The Service Back In “as-a-Service” by CloudTweaks
Pete Chadwick offers advice on how to uilize a service-oriented approach to ensure the business can easily access and rapidly deploy what it needs.

Preventing Epidemics in Cloud Architectures by Gordon Haff
Gordon digs into a recent presentation by Netflix’s ubiquitous Adrian Cockroft. Understand the tension between the benefits of standardized services, and the inherent weakness of a homogenous environment.

ITSM Goodness: How To Up Your IT Service Management Game In 7 Steps by Barclay Rae
To achieve ITSMGoodness – start by listening to customers, and structure services based on business outcomes. Services trump SLAs.  Good perspective from visionary Barclay Rae!

Service Initiation: Understanding the People and Process Behind the Portal by David Crane and Kurt Milne
In VMware’s CloudOps operating model, Service Definition is one part of the multi-part service initiation process.  Listen to this webcast to understand how these four processes fit together.

In some of our recent blog posts we’ve discussed whether new technologies are good for careers in infrastructure and Ops, as well as the variety of ways IT can transform itself to optimize results.

What can IT admins do to better position themselves for the new responsibilities in the cloud era?   Find out by joining a live  twitter chat #CloudOpsChat on “The Changing Role of the IT Admin” – Thursday, April 25^th at 11am PT.

The event will be co-hosted by two very knowledgeable experts on this topic:

• Nigel Kersten (@NigelKersten), CTO at Puppet Labs
• Andrea Mauro (@Andrea_Mauro), Co-Founder of VMUG IT,

We’ll answer questions:

• Is increasing automation and virtualization good or bad for your career?
• Does abstraction and better tools decrease the need for deep expertise?
• Does a cloud admin need programming skills?
• Do you think a cloud admin is a generalist with a little expertise about compute, storage, and networking?
• Or is a cloud admin an expert in cloud architectures?
• What are your thoughts on scripting vs. automation and orchestration?

…and more.

Here’s how to participate in #CloudOpsChat:

• Follow the #CloudOpsChat hashtag (via TweetChat, TweetGrid, TweetDeck, or another Twitter client) and watch the real-time stream.
• On Thursday, April 25^th at 11am, @VMwareCloudOps will pose a few questions using the #CloudOpsChat hashtag to get the conversation rolling.
• Tag your tweets with the #CloudOpsChat hashtag. @reply other participants and react to their questions, comments, thoughts via #CloudOpsChat. Engage with each other!
• #CloudOpsChat should last about an hour.

In the meantime, feel free to tweet to or at us (@VMwareCloudOps) with any questions you may have. We look forward to seeing you in the stream!