People, process, organization and governance for the software-defined data center

Tag Archives: cloud

One of the often-overlooked aspects of building an effective cloud organization lies in the training and development of team members. My customers often ask, “How do I accelerate my IT organization’s transition to cloud?” Well, there is much more to my answer than relates to deploying toolsets.

What the IT organization needs is accelerated learning—learning at organizational level as well as individual. All too often, that learning happens in part by accident. An enthusiastic project team installs the technology first, sometimes as a pilot. The technology works wonders and produces great initial results, e.g., IT services can be provisioned and managed with levels of speed and efficiency that were simply not possible before. Then sometimes, the overall project just stalls. Not because of a technical shortfall. The reason is that the organization has not completely figured out how to fully leverage that technology, and more importantly, how to fit it in with the rest of the IT organization. This is a shortfall of learning.

Faced with the challenge of learning to leverage the technology, many organizations fall back on the tried and tested approach known as “learning on the job.” After all, this is an approach that has worked for centuries! But in the fast-paced cloud era, you want to accelerate the learning process. Really, you want learning by design not just by trial and error. So, where do you start?

Here are some practical lessons that I have collected by supporting successful projects with customers and within VMware:

1. Design a plan for the organization.It stands to reason that the future organization will be different from the current, “pre-cloud” organization. However, the optimal structure will not be reached without planning. In practice we want to gradually flesh out your tenant operations and infrastructure operations teams, as describe in more details in the white paper: Organizing for the Cloud.

In turn, this means orchestrating the transition from the current roles into the target organization. Each transitioned role will require a skills development plan adapted to the individual.

2. Plan for formal skills development.The fist step to plan skills development is to carry out a gap analysis of each selected team member, against their future roles (e.g. , service owner, service architect, and so forth). Each role carries specific requirements in terms of technical skills—without delving in all the details, a blueprint manager will need deeper knowledge of VMware vRealize Automation than a customer relationship manager; however the customer relationship manager will need some awareness of the blueprints and how they can be leveraged to meet customer requirements effectively.

3. Reinforce learning with mentoring and coaching.Mentoring and coaching are effective ways to reinforce the individual’s own learning. Typically mentoring will focus on knowledge transfer based on personal experience. For example, encourage sharing of experience by pairing up the new service architect with an experienced service architect (either in another part of the organization—if existing—or from another organization).

Coaching will focus on individual skill development—either by learning directly from the coach, or from the coach supporting an individual’s own learning journey.

Although coaching/mentoring is by definition highly personalized (learner centric), it is a good idea to establish a formal structure around it. For example, assign coaches/mentors to all future cloud team members, with a mechanism to track activity and results.

4. Develop leaders with both business and technical skills.As when building any team, it is important to identify and nurture a cadre of leaders for the cloud organization. These leaders will be both the formal leadership roles (tenant operations leader, infrastructure operations leader), but also critical roles such as service owner and service architect.

Such leaders will hold a key role in representing the cloud organization within the broader business. Part of their development will include broadening their understanding of the business. For example, by assigning them mentors within the lines of business—this is another example where mentoring comes in handy.

However business acumen, whilst important, is not enough. These roles also need to develop broad technical skills to be able to articulate solutions across technical silos and understand the new capabilities introduced by cloud automation.

5. Reach out to the broader organization with a champions community.Champions, a.k.a change agents, are advocates within the rest of the organization (especially within the lines of business) who will spread the awareness and support for the cloud. These champions help bridge the silos with business users and win “hearts and minds.” Refer to my earlier blog where I explained how we leverage a change agent program within VMware and the lessons that can be inferred. Your change agents will make sure that the broader organization/business learns about the cloud project and ultimately adopts it.

Takeaways:

Plan the transition and learning curve both for your organization and the individuals.

Invest effort in developing at an early stage, the future leaders and champions for cloud adoption. Make sure that their planned learning spans across both technical and business knowledge.

==========Pierre Moncassin is an operations architect with the VMware Operations Transformation global practice and is currently on long-term assignment in Asia-Pacific. Follow @VMwareCloudOps on Twitter for future updates.

A couple of years ago when I was working in Australia, one of my customers was starting to deliver cloud services to its external customers—mainly infrastructure as a service (IaaS). It was not a very mature market at that time though they knew what they had to do to promote those services: enable a marketing capability with a strong customer focus. As the IT organization was evolving its cloud service offering from a technology point of view, that marketing function was driving the change and ensuring customers recognized the value of their cloud.

One key takeaway from the recent Computerworld Forecast Study 2015 is that companies like yours are now investing (or are planning to invest) large portions of their IT budgets to enable a cloud service offering. In my previous blog entry, I briefly mentioned the key steps to define a process for marketing your cloud services within your organization in order to maximize ROI.

Now let´s take those steps to the next level of detail by considering the lessons learned and the critical success factors from those early adopters of cloud. Take a look at this brief: Top 5 Tips for Marketing Your Cloud Services. I think you’ll find some very useful tips for building a marketing capability for your cloud service offering.

=======Alberto Martinez is an operations architect with the VMware Operations Transformation global practice and is based in Spain.

In nearly every other discussion I have with customers about cloud adoption, I hear mention of their challenge with “mindset change.” That challenge is often faced on both sides of the consumer/provider equation, as users (IT consumers) and operators (internal providers) need to change their approaches in order to define, operate, and consume cloud services efficiently.

These same organizations are fully aware that tackling mindset change is essential. The question is: How to go about it with often (typically always) restricted resources and funds?

Changing mindsets for cloud adoption takes more than technical trainingOne option is to invest in a formal change management consultancy project. Whilst such programs certainly deliver value (and many first-tier consultancies offer such services), they also require a substantial investment both in terms of expenditure and bandwidth of your internal resources.

The next option (and often the default option) boils down to education—typically a mix of functional training for users, and technical training for operators. Without a doubt, training brings valuable knowledge; however it does not always lead to changes in behavior.

Here’s where I can provide you with some useful guidance with lessons from a “change agent” program I was involved with at VMware. This program was designed to build internal awareness and disseminate expertise within a fast-developing global practice. Each of these principles below can be generalized to your broader cloud adoption initiative:

Recruit early enthusiasts—preferably volunteers who want to be ahead of the curve.

Make it personal—recognize individual contributions who are making an impact. Encourage participants to share information, and network with their counterparts in other locations.

Make the most of social media—great for facilitating free-flowing communication across dispersed team members.

Work with existing structures and processes—no need to re-invent the wheel—our “change agents” are encouraged to use existing internal training programs—often they will be early adopters and provide valuable feedback on how to improve the training so others will benefit.

Train the trainer—or more accurately, train the evangelist. Each individual is encouraged in turn to evangelize within their own team.

Recruit across a diverse range of experience, seniority, and skills—the more diverse the participants, the broader the adoption and reach of the program across the user base. Also the varied experience brings valuable knowledge and feedback into the program.

ResultsWithin eight months, this unique program has helped VMware’s practice develop a community of more than 100 change agents in over 20 countries! Change agents have contributed to shape and refine the structured training programs in place, and continue to be actively involved in curriculum development.

Whether you are currently struggling with cloud adoption issues or anticipating them with future cloud initiative, I encourage you to try such a program as I’ve described above, and begin to apply these principles. I’d be interested in hearing about your experiences.

===Pierre Moncassin is an Operations Architect with the VMware Operations Transformation global practice and is currently on long-term assignment in Asia-Pacific. Follow @VMwareCloudOps on Twitter for future updates.

A recent Gartner survey[1] revealed that 85 percent of IT departments are pressured by their customers to deploy new or changed IT systems or services faster. As the speed of business continues to increase, IT is having a harder time keeping up. As a result, 41 percent of business leaders attribute faster service delivery time or time to market as the reason they use outside IT service providers[2]. IT must transform itself into an agile organization in order to become a strategic partner to the business.

In the last several years, there have been some key technology and IT management innovations to improve time to market. DevOps, Agile, and cloud computing are all attempts at increasing the speed of IT. However, IT needs to systematically design its services to exploit these innovations.

In this post I’ll explore how to change the way you design IT services so they are optimized for DevOps, Agile, cloud computing, and the service broker IT business model. I’ll also provides suggestions on how to start transforming IT into a nimble organization.

Service Design and DevOps

DevOps describes an approach for re-thinking the collaboration between App Dev, QA, and IT operations. Its purpose is to remove barriers between these teams and align them to the common goal of reducing time to market while maintaining service quality. This alignment sounds easy but is actually difficult because App Dev and IT Ops have traditionally had different objectives: the former strove for innovation and speed, while the later preferred stability.

DevOps focuses on more frequent deployments, lower failure rate, faster mean time to restore and automated processes. In order to design an IT service for DevOps, you not only need to design the system that underpins the service, but also design how the release process will be automated. Nirvana is the ability to perform continuous deployments.

One mechanism you can leverage is the service request catalog and the back-end automation and orchestration. Since App Dev is familiar with provisioning IT services from the catalog, you can also use the catalog as the interface for App Dev to request automated deployments of specific systems. The same automated orchestration capability used to provision IT services, can be used to automate the deployment process by taking the binary outputs from App Dev from the source control system and deploy them into specified environments, such as test, prod, and so forth.

When designing the support process for your new or changed IT service in a DevOps environment, consider a model that integrates both IT Ops and App Dev in the process. In the past, IT Ops shielded App Dev from 24×7 support. However, to reduce failure rate and improve mean time to restore, increasing the App Dev’s role in support creates accountability for App Dev to reduce the number of bugs and develop ways to restore service faster.

Service Design and Agile Software Development

The Agile methodology is characterized by multiple sprints leading to a release. In fact, with DevOps, a single sprint may result in a release. App Dev teams maintain a backlog of stories—a way of describing requirements. It is important to note that the Agile approach is particularly useful when the requirements are not fully known at the start of the project. The implications to service design is that you cannot expect the waterfall approach of having all the requirements upfront and then build the IT infrastructure to satisfy the supposedly stable requirements. The very nature of the Agile approach means that requirements will be discovered or evolve over time. You need to plan and design with the assumption that requirements will change.

This has interesting implications on how infrastructure or supporting services are designed. IT has generally focused on the initial provisioning process when establishing its private cloud services. However, if we know requirements change, we should also invest effort into “day 2” activities, for example, making it easy to expand compute, memory, storage, or change network and security controls sometime after the initial provisioning. Hence, your catalog should not just be an entry point for provisioning requests; it also needs to be the entry point for change requests, continuous deployment requests (as I discussed with regards to DevOps), and retirement requests.

Service Design and Cloud Computing

Cloud computing can be a model for how to deliver business-facing IT services, software as a service (SaaS), or a way to deliver infrastructure and supporting services or infrastructure as a service (IaaS), and platform as a service (PaaS). Cloud-based services have certain characteristics that distinguish them from traditional IT services:

Self-service: The customer can easily request the service through a portal.

On-demand: Instantly deliver the service when it is requested.

Elastic capacity: Dynamically provision more resources (and release those resources when they are no longer required) based on fluctuation in demand.

Highly available and resiliency: When the underlying infrastructure components suffer an outage, the service is architected in such a way that it is still available to the customer.

Pay as you go: The cost of the service is linked to the amount of the service that is consumed. This allows the business to make return on investment (ROI) decisions on how much of the service to consume. Contrast this to a cost allocation model for IT, where the business has no incentive to self-manage their demand of IT.

When designing an IT service, whether it is an IaaS, PaaS, or a business-facing service that sits on top of IaaS or PaaS, you should address these cloud characteristics.

Another aspect of service design is “Where is the service going to be hosted?” —in the private cloud, the hybrid cloud, or the public cloud? The answer may not be straightforward. You may want to pilot the service in the public cloud and then when it grows, bring it back into the private cloud in order to manage costs. Or you may have a service hosted in the private cloud but have the ability to burst into the hybrid cloud to handle peaks in demand. These design decisions impact how App Dev might build the application. For example, if an application starts in the public cloud but may be migrated into the private cloud in the future, App Dev cannot use the public cloud provider’s proprietary technologies, such as an AWS NoSQL database, that isn’t available internally.

Service Design and Becoming a Service Broker

If your internal customers or lines of business are using shadow IT—external IT service providers—in order to meet their time to market requirements, instead of taking an adversarial position against using those external cloud services, your IT department should embrace these vendors and leverage the value that they can provide. IT must become a service broker, helping your IT service consumers select the most appropriate platform for the service they require, whether it is private, hybrid, or public.

A service broker is more than just the ability to show VMware vCloud Air, AWS, or Azure services in your catalog. In fact, showing all the offerings and options from these vendors could become confusing to your customer. Instead, the catalog should ask questions about the requirements, such as:

Is the environment for dev, test, or prod?

Will the environment store any confidential information, such as PII (personal identifying information), HIPAA, and similar?

Does the environment need to adhere to certain levels of compliance such as SOX, PCI?

What service levels do you need?

And the based on the answers, automatically provision the environment into the right cloud—private, hybrid, or public—through the automatic enforcement of policies, as shown below.

Figure 1: Service broker—providing the service regardless of where it resides

Becoming a service broker raises some interesting questions:

Does supplier management need to be matured in order to manage the cloud providers better and ensure they are meeting their service-level obligations?

How does IT provide a seamless user experience regardless of the underlying cloud provider? How do you make the user perceive the private, hybrid, and public cloud as “one cloud”?

What is the support model—for example, are there hand-off points between IT and the cloud vendor? How do you get visibility into the full incident lifecycle as it moves from IT to the cloud vendor?

Where Do You Start?

I’ve introduced how service design needs to change in order to take advantage of DevOps, Agile, cloud, and the service broker model. The next question to answer is: “How do I transform IT so that our services are designed differently?” Here are some suggestions:

Build momentum and support—First, you need to educate stakeholders on what the vision of success will look like, the problems that this “new IT” will solve, and the value that this “new IT” will deliver. This article is a good starting point but you will need to give presentations, conduct workshops, and continue to provide information to stakeholders on where the IT industry is going.

Establish new roles—As part of the transformation, you will need to establish new roles such as service architect, service developer, automation engineer, and so forth. And it’s not sufficient just to define their responsibilities. You also need to give the people in these new roles the training and enablement to be successful.

Pilot the new service design model—It may be easier starting with industry-recognized services to demonstrate how the new operating model will work end to end, such as establish IaaS or PaaS an exemplar of the new way of delivering services.

Think “service lifecycle”—Traditional IT is project-based. Infrastructure is built in response to specific application projects. In a service lifecycle approach, the infrastructure services are designed and built outside the context of a specific application project. Once the infrastructure service is available, application projects then request the infrastructure service as needed. This challenges the way you fund the infrastructure, as the initial creation of the infrastructure service is not tied to the business justification of the application project.
ITIL presents a service lifecycle, but it does not going into depth regarding the specific activities in each stage of the lifecycle (instead, it focuses on the service management processes in each stage). Your organization will need to develop a methodology that defines the specific activities within the service lifecycle.

Next, you will need to tie together the new roles and the new activities from the service lifecycle. Again, a high-level example is provided below.

Figure 2: Service lifecycle example

Conclusion

I’ve described how service design needs to change to take advantage of the innovations brought about through DevOps, Agile, and cloud, along with tips on how to become a service broker. And, I’ve given pointers on where to start your transformation journey. Ultimately, this transformation will help your IT organization deliver at the speed of business, resulting in exploiting business revenue opportunities earlier or realizing business cost savings sooner.

====Reginald Lo is Director of Service Management Transformation with VMware Accelerate Advisory Services and is based in California.

Successful cloud providers invest in marketing their services: promoting them, showing the value to customers, implementing strong pricing campaigns—and they understand how to rapidly adapt to changing market demands. But what prevents your internal IT organization from defining an effective marketing strategy to be more competitive and foster your cloud investments? And more importantly, how should you approach this effort to ensure success?

When moving to a cloud environment, most of the IT organizations that I work with focus on defining processes such as provisioning, support, or capacity, but forget about how to market the services they will be delivering and communicate their value to their customers. The same IT organizations end up with a private cloud infrastructure without clear target customers or, even worse, their cloud services are not used by the lines of business, resulting in a poor return on investment (ROI).

To realize the full ROI that enterprises are looking for from their cloud investments, the IT organization needs to drive the uptake of those services and persuade the lines of business away from using external service providers (shadow IT) or alternative legacy internal service provision options.

In order to mitigate those situations and increase their integration with the business, I advise my clients to define a consistent approach—as outlined below—to market their (internal or external) cloud services.

Defining Your Cloud Services Marketing StrategyThe approach to defining a cloud service marketing strategy must be innovative and not follow the traditional approaches. You need to apply a special focus on your customers in order to build a stronger relationship between your IT organization and the lines of business. That innovative approach has to contain similar characteristics as those of your cloud environment —simple and agile while powerful and impactful.

Below are four steps your IT organization can follow when defining a cloud services marketing strategy:

Define a service marketing strategy. As an essential initial activity, the key elements of the marketing strategy have to be defined with your CIO and leverage the expertise of your CMO and his/her marketing organization (experience, models, tools, and so forth). Those elements include market research, branding, pricing, differentiation, and competition.

Create a communications plan. As my colleague Alex Salicrup wrote recently in this blog, communication is the key pillar to a successful IT provider. Define an effective communications plan for your cloud that will communicate its unique value to your customers and why they have to believe that differentiation is real (“reason to believe”). Your plan must define at a minimum what information will be communicated, how it will be communicated, as well as when it will be distributed and to which audience. Always keep in mind to exclude any technical information from the marketing materials.

Develop marketing campaigns. One mechanism to create new favorable consumer perceptions of your cloud services is the marketing campaign. When developing tailored campaigns, you must identify what you are expecting from the campaign, what your customers can expect, what the impact will be on the audience, and how you will measure success. Measuring the success of your marketing campaigns is key to knowing the impact they had on your targeted audience.

Measure. Benchmark your cloud environment against your competition, and set achievable actions to improve the value to business (always provide the best to your customers!).

Bridging the Gap Between the Cloud and Marketing Organizations

Establishing an IT services marketing capability is not just about defining the above steps—it’s also about your people in your organization and how they will execute upon those activities. To be successful, you need a strong integration between your IT organization and the marketing organization at two levels:

Executive level: While defining the marketing strategy for your cloud environment, both your CIO and CMO have to work in tandem to ensure consistency with the business strategy. This will lead to the cloud services vision or value proposition, its unique value including differentiating factors, and the four steps previously described.

Departmental lead/individual contributor level: Once you have defined your strategy, your IT organization—through cloud tenant operations—will have to work together with at a minimum two teams: 1) the marketing communications team to execute your cloud services communications plan, and 2) with the field marketing team to develop the marketing campaigns and success measurements.

Bridging the gap between the IT and marketing organizations will encourage an open environment of collaboration. I recommend to assign champions to integrate both areas, whose responsibility will be to support the promotion of the cloud services whilst leveraging the IT organization´s functions and expertise.

In summary, an effective cloud services marketing strategy promotes the value of your services and drives the adoption of those services within the lines of business. Start your effort early and with a consistent approach, so you can compete effectively against other cloud providers and achieve the ROI the business is looking for from its cloud investments.

—-Alberto Martinez is an operations architect with the VMware Operations Transformation global practice and is based in Spain.

I recently updated the white paper I wrote a couple of years ago — “Organizing for the Cloud“ — which has been quite popular with our customers. The good news:

It’s shorter – condensed to really focus in on the areas that our customers have told us are the greatest help

The core concepts and models remain intact and have survived the test of time, and our customers continue to benefit from our best practice recommendations

From my perspective, there is no bad news; at least any I could come up with. IT leaders continue to validate with me that a new organizational approach as well as their people—and their roles and responsibilities—are more important than ever.

While I wrote that the core concepts and models have survived the test of time, that’s not to say this is just a condensed version. I’ve updated a few sections based on new technical capabilities enabled by the SDDC and my experience working directly with customers including:

The organizational impacts of the software-defined data center (SDDC) as the cloud infrastructure – including a couple of new roles

How to get started

An expanded section on key cross-team collaboration

Just to name a few.

Organizational change continues to be top of mind as IT executives implement SDDC as the infrastructure of choice for cloud as well as double down on their use of cloud as the future of IT. No matter what the intended topic of conversation when discussing the operational implications of SDDC and cloud, 9 out of 10 conversations I have with customers quickly turn to organizational implications.

Organizational change is a critical step to success in the new era of cloud. I hope you find this revision as useful as our customers found the original.

=====Kevin Lees is principal architect for VMware’s global Operations Transformation Practice and is based in Colorado.

Shadow IT is becoming more prevalent because the business demands faster time-to-market and the latest innovations—and business stakeholders believe their internal IT department is behind the times or hard to deal with (or both!). The new IT requires new ways of designing and quickly deploying services that will meet and exceed customer requirements.

Check out my recent webcast to learn how to design IT services that:
• Take advantage of a DevOps approach
• Embody an Agile methodology to improve time-to-market
• Leverage cloud capabilities, such as elastic capacity and resiliency
• Remove the desire of the business to use shadow IT

===Reg Lo is the Director of the Service Management practice for VMware Accelerate Advisory Services and is based in California.

In this post, I want to share with you some “rule of thumb” estimates on how many full-time equivalent (FTE) positions an IT organization may need to operate a cloud platform. Note: this is not an exact science, so I wanted to give you the practitioner’s approach. What are the general guidelines? What do I need to take into account?

Readers can learn more specific details around the different roles in the cloud management team in the VMware white paper “Organizing for the Cloud” as a starter. Here I use a generic term of “administrator” or “operator” to broadly describe the technicians/analysts/operators who manage and configure the tools on a daily basis. Here’s my list of factors to consider when estimating IT staff ratios:

Number of lines of business. It stands to reason that the higher the number of distinct business units (lines of business) that are using the cloud, the higher the number and complexities of workflows to support, the more user profiles to manages, reports to produce, and so forth.

Number of data centers. If the toolsets must manage multiple data centers, there will be added complexity in order to manage multiple environments, which often are in different locations.

Level staff skill/experience. The higher the experience of the operators, the larger and more complex the infrastructure they can manage. In other words, IT should require fewer FTEs to manage the same level of complexity in a cloud infrastructure. (This is a topic that deserves a separate article: “How the IT Organization Learns to Use Cloud Management Tools — and Over Time.”)

Number of services. By this I mean cloud-type services, as in IT-as-a-service or applications. As a starter, determine how many services will be offered in the cloud service catalog.

Workflow complexity. Factor in the internal complexity of the automated workflows. For example, on a scale of 1-5 (5 being most complex), a workflow with multiple approval points might score as 5, whereas a basic workflow as 1.

Internal process complexity. Within IT, the organization with a higher number of mandatory internal process steps (which might all be in place for good reason) will likely need more staff (or it will take their staff longer) to carry out the same tasks as the organization with fewer internal process steps. A higher degree of complexity often develops in highly regulated environments, be it defense or civil administrations, or where an outsourcing provider requires rigid contractual relationships with inflexible approvals. Process and workflow complexity are related but separate considerations (all processes are not automated into workflows).

Number of third-party integrations. The more integrations that need to be built into the automation workflows, the higher the workload for the operators.

Rate of change. Change may be due to business change (mergers, acquisitions, new products, new applications), but also technological change (such as internal transformation programs). These may impact FTE requirements.

Number of virtual machines under management. It may help to group into broad ranges: less than 100, 100 to 1,000, 1,000 to 10,000, and above 10,000. That range will impact FTE requirements.

Number of user dashboards/reports to maintain. This can range from a couple basic reports to dozens of dashboards and complex reports. If the reporting is not sufficiently automated, the “unfortunate” administrators may need to spend a substantial part of their time producing custom reports for various user groups.

For those readers keen on modeling, each factor I’ve provided can be quite easily prorated on a 1-to-5 scale and turned into a formula. Others can be satisfied with applying as a simple rule of thumb.

My approach can be extended to VMware vRealize Automation or vRealize Operations management products, as well as other management tools. Stay tuned for a future article, as I am also at work to break down the roles far more accurately than “administrators.”

This infographic distills data behind what’s driving the demand for IT professionals with cloud-related skills and why the hunt is on for top talent. Scroll through the entire image for a final section of lucrative careers and top companies hiring.

Post navigation

About this Blog

This blog is for busy people who do things. And for people who make decisions about how to do things. It offers applied insights and lessons learned for IT infrastructure and operations professions responsible for building, managing and optimizing IT Operations in the cloud era.