Home > Blogs > VMware CloudOps > Tag Archives: automation

Tag Archives: automation

Service Catalog Is The New Face of IT

By Choong Keng Leong

Keng-Leong-Choong-cropMany organizations on their journey to delivering IT as a service have chosen to adopt and implement VMware vCloud® Automation Center™ to automate the delivery and management of IT infrastructure and services through a unified service catalog and self-service portal.  As this transformation requires a new IT operating model and change in mindset, a common challenge that IT organizations encounter is:

  • How do I define and package IT services to offer and publish on the service catalog?

This is analogous to a mobile operator putting together a new mobile voice and data plan that the market wants and pricing it attractively.

Here’s a possible approach to designing a service catalog for vCloud Automation Center implementation.

Service Model
Service catalog is the new face of IT. It is a communication platform and central source of information about the services offered by IT to the business. It is also empowering users through an intuitive self-service portal that allows them to choose, request, track, and manage their consumption and subscription to IT services.

The first step to developing the service catalog and identifying the services within it is to understand the business requirements as to how these demands are going to be fulfilled — that is to develop a service model. For example, you could start with a business function — Sales — and then pick a business process — client relationship management (CRM). CRM can be further broken down into three domains: operational CRM, collaborative CRM, and analytical CRM. Each of the CRM systems can be instantiated in different environments (product, test, and development). Each instance is technically implemented and delivered via a three-tier system architecture. What you would get is shown below in Figure 1, which is a service model for CRM.

ServiceCatalog

Figure 1. Service Model for CRM

Repeat the above steps for the other business functions. At the end of the exercise, you have defined service categories, catalog items, and service blueprints for implementation of a service catalog and self-service portal in vCloud Automation Center.

Service Catalog
Using the above business centric approach allows you to define a customer-friendly service catalog of business services. The service categories and catalog items are in business-familiar terms, and only relevant information is presented to the business user so as not overwhelm him/her with the complexities of the underlying technologies and technicalities.

The business services are provisioned using service blueprints, which are templates containing the complete service specifications, technical service levels (e.g., RTO, RPO, and IOPS), and infrastructure (e.g., ESXi cluster, block or file storage, and network).  The service blueprints allow IT to automate provisioning through vCloud Automation Center. To maximize business benefits and optimization of infrastructure resources, it is also important to establish a technical service catalog of technical capabilities and to pool infrastructure resources with similar capabilities. Then, vCloud Automation Center can provision a service via the service blueprint to the most cost-effective resource pool and providing optimal performance.

In summary, using a business-centric approach to designing your service catalog elevates IT to speaking in business terms and provides a whole new IT experience to your users.

——-
Choong Keng Leong is an operations architect with VMware Professional Services and is based in Singapore. You can connect with him on LinkedIn.

7 Key Steps to Migrate Your Provisioning Processes to the Cloud

By David Crane

dcrane-cropIn an earlier blog, my colleague Andy Troup shared an experience where his customer wanted to embark on a process automation project, which could have had disastrous (and consequently frustrating and costly) results, as the process itself was inherently unsuitable for automation.

Automating processes is one of the first projects that organizations embark on once a cloud infrastructure is in place, but why? The answer lies in legacy IT organizations structures that have typically operated in silos.

Many of the IT organizations that I work with have a number of groups such as service development, sales engineering, infrastructure engineering, and IT security that face similar challenges that can include (among many others):

  • Applications provisioned across multiple environments such as development, QA, UAT, sales demonstrations, and production
  • Managing deployments of application workloads in a safe and consistent manner
  • Balancing the speed and agility of deploying the services required to deliver and improve business results while meeting compliance, security, and resource constraints

With the agility that cloud computing offers, organizations look to the benefits that automating the provisioning processes may bring to overcome the above challenges such as:

  • Reduced cycle time and operating costs
  • Improved security, compliance, and risk management
  • Reduced capital and operating expenditures
  • Reduced need for management/human intervention
  • Improved deployment/provisioning time
  • Consistent quality in delivery of services

The IT organizations I work with are often sold these benefits without consideration of the operational transformation required to achieve them. Consequently, when the IT team kicks off a project to automate business processes, especially service provisioning, their focus is on the potential benefits that may be achieved. The result of this focus is that automation becomes a panacea, and not something that should underpin the IT organization’s overall operational transformation project.

As IT leaders, when considering migrating your provisioning processes to your cloud environment, you need to realize that automation alone will not necessarily provide the cure to problems that exist within a process.

You should not consider the benefits of automation in isolation. For example, too much focus on cost reduction can frequently lead to compromise in other areas leading to objections and resistance from business stakeholders. You should consider other benefits that have non-tangible (or direct) metrics, such as improved staff satisfaction. Automation frees your technical staff from repetitive (and uninteresting) activities, which results in both improved staff retention and indirect cost benefit.

As you select processes to migrate from a physical (or virtual) environment to the cloud, the subsequent automation of those processes should not be an arbitrary decision. Frequently my clients choose processes as candidates for automation for reasons based on personal preferences, internal political pressures, or because some process owners shout louder than others!

Instead the desired business benefits the organization wishes to achieve should be considered in conjunction with the characteristics, attributes, and measurable metrics of a process characteristics and a formal assessment made of its suitability for automation.

Your automation project should also be implemented in conjunction with an organization structure assessment, which may require transformation and the introduction of new roles and responsibilities required to support the delivery of automated and self-optimizing processes.

Important Steps to Your Successful Process Assessment
Based on my experience assisting customers in this exercise, I recommend taking these steps before you embark on a process assessment:

  1. Understand automation and what it actually means and requires. Many organizations embark on automation without actually understanding what this means and the context of automated processes and their capabilities. Subsequent delivery then either leads to disappointment as automation does not meet expectations, or the process is not truly automated but instead has some automated features that do not deliver all the expected benefits.
  2. Identify and document the expected business benefits to be achieved through introduction of process automation. This is an important task. Without understanding the benefits automation is expected to achieve, you cannot identify which processes are the correct choices to help you do just that.
  3. Understand cloud infrastructure system management capabilities required to support process automation (e.g., ability to detect environmental changes, process throughput monitoring capability) and implement if required.
  4. Identify ALL processes required to support automated provisioning (e.g., instantiation, governance, approval) to create a process portfolio.
  5. Identify the common process automation characteristics that exist across the process portfolio (e.g., self configuration, self healing, self audit and metric analysis). Note that process characteristics are unique, high-level identifiers of automation across the portfolio.
  6. Identify the common attributes that the process characteristics share. These are more granular than process characteristics and thus may be common to more than one characteristic in the same process.
  7. Identify the metrics available for each process in the portfolio, and apply a maturity assessment based on their ability to be measured and utilized. Metric maturity is an essential part of the assessment process as it determines not just the suitability of the process for automation, but also its capability to perform self optimization.

Process Assessment Weighting and Scoring
When undertaking a process assessment program, an organization needs to understand what is important and prioritize accordingly. For example, if we consider the business benefits of automation, a managed service provider would probably prioritize business benefits differently to a motor trade retail customer.

Once you’ve prioritized your processes, they can be assessed more accurately and weighted based on each identified business benefit. Prioritization and weighting is essential, and you need to carefully consider the outcomes of this exercise in order for your process assessment to reflect accurately whether processes are suitable for automation or not.

And remember, as previously mentioned avoid considering each assessment criteria in isolation. Each process characteristic and associated attribute can have a direct impact on the desired business benefit, however if its metric maturity is insufficient to support it, then the business benefit will not be fully achieved.

For example, let’s say that you have identified that a business process you wish to automate has a self-healing characteristic. One of the attributes the characteristic possesses is the ability to perform dynamic adjustment based on real-time process metrics. The characteristic and attribute would lead you to expect the realize benefits such as reduced cycle time, reduced OpEx, consistent quality of service, and improved staff retention.

However, although you’ve identified the metrics required to meet the characteristic and attribute needs, they are neither measured or acted upon. Consequently, because the metric maturity level is low, then the expected business benefit realization capability is also lowered.

Figure 1 below shows a small sample of the assessment of a process in relation to a single process characteristic, common attributes, anticipated business benefits and their weighting and the impact that a poor metric maturity has on their capability to deliver the anticipated business benefit.

Figure 1. Assessment displaying impact of low metric maturity

Contrast this to Figure 2 below, which assesses a process with exactly the same characteristics, attributes, business benefits, but has supporting management capabilities and consequently much improved metric maturity:

Figure 2. Assessment displaying impact of high metric maturity

Based on this small data sample, the process in Figure 2 is a more likely candidate for process automation. The assessment process also then identifies, and allows the IT organization to focus on, areas of remediation needed to optimize processes to enable them to be suitable automation candidates.

The result is the IT organization is able to realize not just the business benefits that have been promised by automation more effectively, but they are also able to set realistic expectations with the business, which brings benefits all of its own.

In summary, automation is not the “silver bullet” for broken or inefficient processes. IT leaders need to consider expected business benefits in conjunction with process characteristics, attributes, and metrics and in the context of what is important to the business. By assessing the suitability of a process for automation, you can save the cost of a failed project and disappointed stakeholders. Finally, you should not undertake any provisioning process project in isolation to other operations transformation projects, such as organization structure and implementation of cloud service management capabilities.

I will discuss the steps to success mentioned above in more detail in my next blog.

===

David Crane is an operations architect with the VMware Operations Transformation global practice and is based in the U.K.

 

5 Ways Cloud Automation Drives Greater Cost and Operational Transparency

By Kevin Lees

Kevin_cropThere has always been tension between IT teams and their end customers — not the good kind of tension, but rather the contentious kind that rarely ends well.

It breaks down like this: IT never believes it has enough time, resources, or money; and the line of business (LOB) really doesn’t understand what they want. On the other side, the LOB is rarely happy with IT because response times aren’t fast enough or IT is missing the mark with its capabilities.

This tension leads to inefficient use of resources, both equipment and people. Shadow IT happens when those outside of IT take matters into their own hands and shirk IT policies and procedures. This can mean inefficiencies in the allocation of capital because finance is challenged to track exactly what it costs for IT to deliver. This becomes especially difficult in a shared resource environment, and it will only get more challenging as we move to a fully virtualized stack as defined by the software-defined data center (SDDC).

This can lead to all sorts of problems, fostering mistrust, lost profits, and lost opportunities. You get the idea.

In this post, we’ll explore key ways that cloud automation is critical to fulfilling the promise of cloud and how automation provides opportunities to practice cost and operational transparency as a way to help drive business alignment.

The Promise of Cloud Management
Cloud holds great promise and great responsibility. It provides many advantages to both IT and its stakeholders, but without effective cloud management and automation, the true value will never be realized.

This is true regardless of the type of cloud, whether private enterprise cloud, an external cloud provider, or a hybrid cloud.

As the figure below shows, there are five areas to focus on that not only provide opportunities to drive business alignment, but also provide opportunities to practice the cost and/or operational transparency needed to gain the business stakeholder’s trust:

5 Ways Automation-Lees

  1. Service quality: The business has to know it can count on the service it’s consuming.
  2. Predictability: Of course, the service has to be predictable. Outages are unacceptable.
  3. Agility: The business needs to quickly react to changing business conditions or proactively get to market before the competition, so IT needs to keep up.
  4. Smart economics: It also has to be cost effective. If it’s not, shadow IT rears its ugly head, and any degree of governance as well as economy of scale efficiencies dissipate into the cloud, outside of IT’s control.
  5. Clear communication: Business stakeholders have to truly understand what they’re getting and how much flexibility of choice is available to them.

That said, IT cannot deploy and run an effective and successful cloud in a vacuum. A truly successful cloud, one that adds real business value, requires alignment among IT, LOB, and finance. It requires a lot of interaction, listening, discussing, and agreeing. Yes, there will be trial and error.

Fortunately, one of the big benefits of cloud when done right (namely agility) is the ability to fail fast, fail often, and try something else.

With alignment and the clear communication required to achieve it:

  • IT can provide solutions and services that add value to the business by meeting its needs, because business is involved in the service definition.
  • LOB stakeholders will have a much better idea of what they’re getting and know it will meet their needs.
  • Finance will understand service costs within a business context to make more informed decisions about how to maximize the budgets and ensure a degree of cost predictability.

If all goes well, the end result is trust and business alignment between the parties.

One final note for IT: you desperately need to take a course in Marketing 101. IT needs to get better at advertising its services and demonstrating its value add so everyone knows what an asset the group is. At VMware, this is something we address explicitly when we help IT customers set up their processes for defining, costing, and offering cloud-based services to their LOB market. Taking a technical service to LOB market is no different than the business taking a service to market. Would they do that without proactive marketing? I don’t think so.

If you found this post helpful, stay tuned for future posts on this topic. Next time, I’ll offer my thoughts on ways to turn IT’s “trust debt” into true business alignment through greater transparency, agility, and technical alignment.

===========
Kevin Lees is Global Principal Architect, Operations Transformation Practice. Follow @VMwareCloudOps on Twitter for future updates, and join the conversation by using the #CloudOps and #SDDC hashtags on Twitter.

Aligned Incentives – and Cool, Meaningful New Jobs! – In the Cloud Era

By: Paul Chapman, VMware Vice President Global Infrastructure and Cloud Operations

Transforming IT service delivery in the cloud era means getting all your technical ducks in a row. But those ducks won’t ever fly if your employees do not have aligned incentives.

Incentives to transform have to be aligned from top to bottom – including service delivery strategy, operating model, organizational construct, and individual job functions. Otherwise, you’ll have people in your organization wanting to work against changes that are vital for success, and in some cases almost willing for them to fail.

This can be a significant issue with what I call ‘human middleware.’ It’s that realm of work currently done by skilled employees that is both standard and repeatable at the same time: install a database; install an operating system; configure the database; upgrade the operating system; tune the operating system, etc..

These roles are prime for automation and/or digitization – allowing the same functions to be performed more efficiently, more predictably, game-changingly faster, and giving the IT organization the flexibility it needs to deliver IT as a Service.

Of course, automation also offers people in these roles the chance to move to more meaningful and interesting roles – but therein lies the aligned incentive problem. People who have built their expertise in a particular technology area over an extended period of time are less likely to be incentivized to give that up and transition to doing something ‘different.’

Shifting Roles – A VMware Example

Here’s one example from VMware IT – where building out a complete enterprise SDLC instance for a complex application environment once took 20 people 3-6 weeks.

We saw the opportunity to automate the build process in our private cloud and, indeed, with blueprints, scripting, and automation, what took 20 people 3-6 weeks, now takes 3 people less than 36 hours.

But shifting roles and aligning incentives was also very critical to making this happen.

Here was our perspective: the work of building these environments over and over again was not hugely engaging. Much of it involved coordinating efforts and requesting task work via ticketing systems, but people were also entrenched in their area of expertise and years of gained experience, so they were less inclined to automate their own role in the process. The irony was that in leveraging automation to significantly reduce the human effort and speed up service delivery, we could actually free people up to do more meaningful work – work that in turn would be much more challenging and rewarding for them.

In this case, employees went from doing standard repeatable tasks to high order blueprinting, scripting, and managing and tuning the automation process. In many cases, though, these new roles required new but extensible skills. So in order to help them be successful, we made a key decision: we would actively help (in a step-wise, non-threatening, change-management-focused way) the relevant employees grow their skills. And we’d free them up from their current roles to focus on the “future” skills that were going to be required.

Three New Roles

So there’s the bottom line incentive that can shift employees from undermining a transformation to supporting it: you can say, “yes, your role is changing, but we can help you grow into an even more meaningful role.”

And as automation frees people up and a number of formerly central tasks fall away, interesting new roles do emerge – here, for example, are three new jobs that we now have at VMware:

  •  Blueprint Designer – responsible for designing and architecting blueprints for building the next generation of automated or digitized services.
  •  Automation Engineer – responsible for engineering scripts that will automate or digitize business process and or IT services.
  •  Services Operations Manager – responsible for applications and tenant operation services in the new cloud-operating model.

The Cloud Era of Opportunity

The reality is that being an IT professional has always been highly dynamic. Of the dozen or so different IT positions that I’ve held in my career, the majority don’t exist anymore. Constant change is the steady state in IT.

Change can be uncomfortable, of course. But given its inevitability, we shouldn’t – and can’t – fight it. We should get in front of the change and engineer the transformation for success. And yet too frequently we don’t – often because we’re incented to want to keep things as they are. Indeed, misaligned incentives remain one the biggest impediments to accelerating change in IT.

We can, as IT leaders, shift those incentives, and with them an organization’s cultural comfort with regular change. And given the positives that transformation can bring both the organization and its employees, it’s clear that we should do all we can to make that shift happen.

Major Takeaways:

  • Aligning incentives is a key part of any ITaaS transformation
  • Automation will eliminate some roles, but also create more meaningful roles and opportunities for IT professionals
  • Support, coaching, and communication about new opportunities will help accelerate change
  • Defining a change-management strategy for employee freedom and support for their transition are critical for success

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

The Top 10 CloudOps Blogs of 2013

What a year it’s been for the CloudOps team! Since launching the CloudOps blog earlier this year, we’ve published 63 items and have seen a tremendous response from the larger IT and cloud operations community.

Looking back on 2013, we wanted to highlight some of the top performing content and topics from the CloudOps blog this past year:

1. “Workload Assessment for Cloud Migration Part 1: Identifying and Analyzing Your Workloads” by Andy Troup
2. “Automation – The Scripting, Orchestration, and Technology Love Triangle” by Andy Troup
3. “IT Automation Roles Depend on Service Delivery Strategy” by Kurt Milne
4. “Workload Assessment for Cloud Migration, Part 2: Service Portfolio Mapping” by Andy Troup
5. “Tips for Using KPIs to Filter Noise with vCenter Operations Manager” by Michael Steinberg and Pierre Moncassin
6. “Automated Deployment and Testing Big ‘Hairball’ Application Stacks” by Venkat Gopalakrishnan
7. “Rethinking IT for the Cloud, Pt. 1 – Calculating Your Cloud Service Costs” by Khalid Hakim
8. “The Illusion of Unlimited Capacity” by Andy Troup
9. “Transforming IT Services is More Effective with Org Changes” by Kevin Lees
10. “A VMware Perspective on IT as a Service, Part 1: The Journey” by Paul Chapman

As we look forward to 2014, we want to thank you, our readers, for taking the time to follow, share, comment, and react to all of our content. We’ve enjoyed reading your feedback and helping build the conversation around how today’s IT admins can take full advantage of cloud technologies.

From IT automation to patch management to IT-as-a-Service and beyond, we’re looking forward to bringing you even more insights from our VMware CloudOps pros in the New Year. Happy Holidays to all – we’ll see you in 2014!

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

Understanding Process Automation: Lean Manufacturing Lessons Applied to IT

by: Mike Szafranski

With task automation, it is pretty simple to calculate that it is worth taking 2 hours to automate a 10-minute task if you perform that task more than 12 times. Even considering the fixed and variable costs of the automation solution, the math is pretty straightforward.

But the justification for automating more complex processes composed of dozens of ‘10 minute tasks’ completed by different actors – including the inevitable scheduling and wait time between each task – is a bit more complex. Nonetheless, an approach exists.

You can find it laid out in Kim, Behr, and Spafford’s modern classic of business fiction, The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win [IT Revolution Press, 2013], in which the authors show how the principals of lean manufacturing are directly applicable to IT process automation.

So what lessons do we learn when building a case for process automation by applying lean manufacturing principles to IT Ops? Let’s take a look.

Simple Steps Build the Business Case

First, you need to break the process you’re interested in into its constituent parts.

Step 1 – Document Stages in the Process and Elapsed Time. Through interviews, identify major process stages and then document the clock time elapsed for each. Note, use hard data for elapsed time if possible. People involved in the process rarely have an accurate perception of how long things really take. Look at process artifacts such as emails, time stamps on saved documents, configuration files, provisioning, or testing tool log files to measure real elapsed time.

Step 2 – Document Tasks and Actors. Summarize what gets accomplished at each stage and, most importantly, detail all the tasks and record which teams perform them. If a task involves multiple actors working independently with a handoff, that task should be broken down into sub-tasks.

Step 3 – Document FTE Time. Record the work effort required for each task. We’ll call that the Full Time Equivalent (FTE). This is the time it takes to do the actual task work, assuming no interruptions, irregularities, or rework.

Step 4 – Document Wait Time. Understanding wait time is critical to building a case for process automation. If actors are busy, or if there are handoffs between actors, then elapsed time is often multiple times longer than FTE time. This is because at each handoff, the task must sit in queue until a resource is ready to process the task.

After taking these steps, you can summarize in a chart similar to this.

In Lean Manufacturing, the concept of wait time or queue time has a mathematical formula [see chapter 23 of The Phoenix Project]. The definition is:

The formula, of course, offers hard proof of what you already knew – that the busier you are, the longer it takes to get new work done. With multiple actors on a task, each can contribute to wait time, with the amount they contribute depending on how busy they are.

In the example below, there are five separate teams (security, network, dev, QA and VM) involved in the Validate Firewall step in the flow. Each team is also busy with other tasks. 

Figure 2. In a manually constructed environment, the network settings, firewall rules, and application ports need to be validated. More often than not, they need to be adjusted due to port conflicts or firewall rules. Wait times correlate strongly with % ultilization.

As you can see, the time spent by FTEs is 5.5 hours, which is only around 15% of the clock time. Clearly, with complex tasks, FTE is only a part of the story.

Step 5 – Account for Unplanned Work. Unplanned work occurs when errors are found, requiring a task from an earlier step in the process to be reworked or fixed.

In complex automation, unplanned work is another reality that complicates the process and increases FTE time. It also dramatically impacts clock time – in two ways. First, there’s the direct impact of additional time spent waiting for the handoff back upstream in the process. Second, and even more dramatic, is the opportunity cost. Planned work tasks need to stop while the process actor sets things aside and addresses the unplanned work. Unplanned work can thus have a multiplier effect, causing cascading delays up and down the process flow.

One aim of automation, of course, is to reduce unplanned work – and that reduction that can also be calculated, further adding to the business case for process automation. Indeed, studies have shown that, currently, unplanned work consumes 17% of a typical IT budget.

Process Automation Can Offer More Than Cost Reduction

But there’s potentially even more to the story than a complete picture of IT work and detailed accounting of reduced work effort and timesavings. The full impact of process automation can include:

  • Improved throughput
  • Enabling rapid prototyping
  • Higher quality
  • Improved ability to respond to business needs

The cumulative impact of these can be substantial. Indeed, it can easily exceed the total impact of direct cost reductions.

Step 6 – Estimate total benefit to business functions. If calculating the value of reducing FTE, wait times, and unplanned work is relatively straight forward, figuring the full business impact of reducing overall calendar time for a critical processes (from 4 weeks to 36 hours, say) requires more than a direct cost reduction calculation. It’s worth doing, though, because the value derived from better quality, shorter development times, etc., can substantially exceed the value of FTE hours saved through automation (see figure 3). 

Figure 3. The secondary impacts of automating processes and increasing agility and consistency can be much larger than the value of the FTE hours saved.

You do it by asking IT customers to detail the benefits they see when processes are improved. There are many IT KPIs that can help here, such as the number of help desk tickets received in a specific period, or the number and length of Severity 1 IT issues.

We used this method at VMware when we automated dev/test provisioning and improved the efficiency of 600 developers by 20%. We achieved a direct cost reduction related to time and effort saved. But we found an even bigger impact, even if it was harder to quantify, in improved throughput, in always being able to say, “Yes” to business requests, and in enabling rapid prototyping.

Lessons Learned

With these steps, you can capture major process stages, tasks, actors, calendar time, work effort, and points of unplanned work, quantifying the business value of automating a process end-to-end – and making your case for end-to-end process automation all the stronger.

Key takeaways:

  • It’s possible to make a business case for automating end-to-end IT processes;
  • You can do this by applying concepts from lean manufacturing;
  • The concepts of wait time and unplanned work are central;
  • Efficiency driven cost reduction is only part of the equation, however;
  • To quantify the full value of agility, work with IT customers to gauge improvements in KPIs that reflect improved business outcomes.

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

Task Automation Vs. Process Automation – Highlights from #CloudOpsChat

After a successful automation-themed #CloudOpsChat in September, we decided to take a deeper dive into automation for this month’s edition, discussing “Task Automation Vs. Process Automation.” Thanks to everyone who participated, and thank you especially to Rich Pleasants (@CloudOpsVoice), Business Solutions Architect and Operations Lead for Accelerate Advisory Services at VMware, for co-hosting!

To begin the chat, we asked: “What IT tasks or processes has your company successfully automated?”

@Andrea_Mauro jumped right in, asking how automation compares to tasks? @kurtmilne offered VMware’s take, saying “VMware IT has fully automated provisioning of complex workloads on private cloud,” and clarified that the most complex workloads were “Oracle ERP with web portals, and over 80 blueprints.” @venkatgvm also elaborated on VMware’s automation story: “VMware instance provisioning had over 20 major steps, each of them were executed by siloed teams.”

Co-host @CloudOpsVoice took the question further, asking, “Are people automating day to day maintenance activities or actual steps in the process?”

@vHamburger gave his advice on where to begin with automation, saying “[day-to-day automation] is a good starting point. Nominate your top 10 time-consuming tasks for automation.” @Andrea_Mauro replied, suggesting that “task automation is more for repeatable operations and day by day [tasks].” He followed up by offering a definition of process automation: “Process automation could be more related to organization level and blueprint usage.” @kurtmilne also chimed in with business-related definitions of task and process automation: “Task automation math includes cost/time of single task vs. developing automation capability…Process automation math includes business benefit of overall improved agility, service quality – as well as cost.” @CloudOpsVoice broke his definition of automation into three parts: “day-to-day, build and run.”

@CloudOpsVoice next asked, “What technique do you use primarily for automation? Policy, orchestration or scripting? How do App blueprints impact it?”

@kurtmilne noted the value of blueprints and scripting: “Blueprints and scripting allow app provisioning automation – not just VM provisioning.” @thinkingvirtual also offered sound advice on how to select what to automate at your company: “Always make sure your automation efforts provide real value. Don’t automate for automation’s sake.” Elaborating on this, @kurtmilne discussed the value of automation, stating that automation’s “real value” is “ideally measured in business outcomes, and not IT efficiency.” @vHamburger also warned against bottlenecks preventing automation: “every enhancement after your bottleneck is not efficient – know your bottlenecks!”

@vHamburger went on to mention task workflow: “Clean task workflow with documented steps is always preferred over scripts,” he suggested, because it’s “easier and repeatable for new admins.” @Andrea_Mauro countered by saying that sometimes a “‘quick and dirty’ solution could be good enough,” to which @vHamburger replied, “In my experience ‘quick and dirty’ always leads to fire fighting ;).” @kurtmilne then vouched for “leaning out” a process: “‘Leaning out’ an IT process is good. But sometimes it’s better to use automation to eliminate tasks vs. automate tasks,” he wrote. @thinkingvirtual also noted how important communication is to successful automation: “Often forgotten: keep your business in the loop. Show back the value continuously to broaden the relationship.”

@AngeloLuciani kept things moving by asking, “Do you pick a tool to fit the process or a process to fit the tool?”

@JonathanFrappier enthusiastically went with the latter: “Process to fit the tool! Processes can change, tools have to live on until more budget is approved!” @kurtmilne added, “Tool/process construct doesn’t make sense with full automation. You can do things with automation you can’t do with manual tasks: For example, you don’t figure out manual horizontal scaling process in cloud – then look for tool to automate.”

#CloudOpsChat ended with one last great tip (and a nod to VMworld!) from @thinkingvirtual: “Automation skills are a huge career opportunity. Don’t avoid automation, defy convention.”

Thanks again to everybody who participated in this latest #CloudOpsChat, and stay tuned for details of our next meet up. If you have suggestions for future #CloudOpsChat topics, let us know in the comments.

For more resources on automation, check out the following CloudOps blog posts below:

In the meantime, feel free to tweet us at @VMwareCloudOps with questions or feedback, and join the conversation by using the #CloudOps and #SDDC hashtags. For more from Rich Pleasants, head over to the VMware Accelerate blog.

The Critical Element of Service Delivery in the Cloud Era: Join our Webcast 11/14

As more companies aim to build the software-defined datacenter (SDDC), the importance of service definition continues to grow. Running a successful SDDC strategy means understanding service offerings, for sure. But it’s also about standardizing those offerings to achieve agility and efficiency. So where do you start? How do you know what services your company can best provide?

Join Product Manager Jason Holmberg and Business Solutions Architect Rohan Kalra on Thursday, November 14th  at 10am PT for their BrightTalk webcast: The Critical Element of Service Delivery in the Cloud Era. The webcast will take you through the four fundamental Service Catalog building blocks:

  • Automation
  • Governance & Policies
  • Provisioning and orchestration
  • Lifecycle management

Both Jason and Rohan have years of experience building and implementing service catalogs. In addition to defining these building blocks, Jason and Rohan will dive into the requirements for each component, making it easier for you to implement a service catalog and making sure that you’re delivering the best services to your users through your catalog. Don’t miss this webcast to learn how service definition will be the key to your SDDC.

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

Task Automation vs. Process Automation: Join Us For #CloudOpsChat 11/13!

Here at VMware, we’re always talking about automation: Venkat Gopalikrishan detailed his success after automating the provisioning of business-critical application stacks, and Paul Chapman introduced VMware’s IT transformation story by highlighting the importance of automation and change management.

We saw some fantastic insight on automation from many of you during our last #CloudOpsChat and wanted continue the conversation. For this month’s #CloudOpsChat, we’re specifically focusing on next steps in automation by asking the following questions: What has your company successfully automated? Do you focus on task automation, process automation, or both?

Join us on Wednesday, November 13th at 11am PT to discuss task vs. process automation with your CloudOps peers. Hosting the chat is CloudOps expert Rich Pleasants, Business Solutions Architect and Operations Lead for Accelerate Advisory Services at VMware.

During the chat, we’ll discuss:

  • What business tasks or processes has your company successfully automated?
  • When discussing automation, how do you determine whether you should automate a task vs. a process?
  • Do you have people in your company whose primary role is automation?
  • What technique do you use primarily for automation? Policy, orchestration or scripting?
  • How does the blueprint concept impact your automation workflow (scripting, orchestration)?

Here’s how to participate in #CloudOpsChat:

  • Follow the #CloudOpsChat hashtag (via Twubs.com, Tchat.io, TweetDeck, or another Twitter client) and watch the real-time stream.
  • On Wednesday, November 13th at 11am PST, @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, RSVP to the event and feel free to tweet at us at @VMwareCloudOps with any questions you may have! For even more on automation, check out Rich Pleasants’ latest blog post for VMware Accelerate where he discusses “Intelligent Automation.”

We look forward to seeing you in the stream!

To Automate or Not to Automate? – Highlights from #CloudOpsChat

Last week, we held another successful #CloudOpsChat, this time asking: “To Automate or Not to Automate?” Thank you to everyone who participated in the lively conversation, and especially to our two co-hosts, Cloud Operations Architects Andy Troup (@HarrowAndy) and David Crane (@DaveJCrane)!

To start things off, we asked, “How do you define automation?”

Our co-hosts jumped in first, with @HarrowAndy stating, “automation = stop doing repeatable tasks,” and @DaveJCrane remarking on how he asked the same question during a group discussion at VMworld and received 50 different answers from 50 different people in the room! In addition, the notion that automation implies the removal of manual work was a prominent theme, with @Seemaj, @AngeloLuciani, @tcrawford and @KongYang agreeing that automation means less, or no, human intervention (see Pierre Moncassin’s take on that here).

Next, the conversation moved on to the importance of defining automation within the context of your business.

@DaveJCrane began by adding a layer to the definition, suggesting that it is “important to consider the definition of automation in context of the business environment, not just process focus.” @tcrawford agreed with David, specifying a difference between the what/why of automation, as well as the how/when. @HarrowAndy built upon @tcrawford’s response, adding that there must always be a benefit to what you’re automating, and that there is “no point automating something you only do infrequently.”

@Seemaj then brought up the cost of automation, agreeing with @tcrawford that: “There is a cost to automation, and the business drives those decisions.”

@AngeloLuciani stated that “automation drives business value,” and @tcrawford stirred the pot, replying “sometimes it can, not always.” @HarrowAndy then brought up the importance of weighing automation’s benefits with its costs, with @KongYang, @AngeloLuciani and @Seemaj adding that two of the biggest benefits to automation are limiting human mistakes and delivering services faster. @Gnowell1 emphasized automation’s goal of promoting reliable service delivery, saying “time consuming, complex tasks should also be considered for automation.”

After that, @KalraRohan asked, “What’s driving everyone to move towards automation?”

@VmwDavidH immediately offered VMware’s use case for automation: “For us, we have cut our dev environment provisioning time down from weeks to hours.” @Seemaj noted business agility as her main reason, with @AngeloLuciani saying that automation is a “building block” towards the software-defined datacenter (SDDC). @DaveJCrane agreed, adding that “[automation] is always good to implement as part of a larger ops transformation.”

@KalraRohan then asked, “What are the operational impacts of automation? What are best practices?”

@HarrowAndy, @VmwDavidH and @AngeloLuciani all agreed that a set of orchestration tools was essential in driving the success of automation. @GNowell1 suggested a key benefit that automation provides to a business: “SDDC automation promotes Ops standards. Administrators spend more time on higher level responsibilities.” And @DaveJCrane elaborated further on automation’s ability to shift ops’ focus: “Automating allows you to put more emphasis on the workflow/approval process.”

To close out this #CloudOpsChat, @HarrowAndy asked: “So what have you all automated? Is it just provisioning activities, or are there other things?”

@AngeloLuciani and @Gnowell1 had both started with provisioning and said they were looking for the next step in automation. @CloudOpsVoice stated that provisioning was a great start and great use-case for the ‘run’ side of automation, with @tcrawford adding “iterative automation is all about value.” He continued by saying that knowing what to automate next comes with “experience, and asking questions.” @Seemaj agreed, and emphasized that automation touches all aspects of a company: “Automation is not just about provisioning/tools/scripts…and it does not always have measurable outcomes. Sometimes benefits are soft benefits, e.g. improved user experience.”

Our #CloudOpsChat wrapped up with a positive outlook on the future of automation, with @AngeloLuciani tweeting “automation will be a major skill for next gen IT staff.” As automation progresses, companies will experience “less firefighting in operations and more time spent on working with the business,” suggested co-host @HarrowAndy.

Thanks again to everybody who participated in this latest #CloudOpsChat, and stay tuned for details of our next #CloudOpsChat!

In the meantime, feel free to tweet us at @VMwareCloudOps with questions or feedback, and join the conversation by using the #CloudOps and #SDDC hashtags.