Home > Blogs > VMware Accelerate Advisory Services > Tag Archives: IT transformation

Tag Archives: IT transformation

eBook- Agents of Change: CIO Priorities for 2016

Today’s most successful enterprises are transforming themselves, upending business models, disrupting markets. What’s more, they’re turning on a dime – and the pace at which they’re doing so is only increasing. For these winners, that agility translates into increased customer satisfaction, better margins, and higher sales. For their IT functions – responsible for so much of this new flexibility and speed – transformation drives a new relationship with the business. IT is now a fundamental and ongoing contributor to accelerating business value.

As CIOs look to transform their own IT organizations in year ahead, their greatest challenge lies in delivering that change in an environment that is itself fast moving.

In 2016 and beyond, IT can only expect increased pressure to deploy continuous innovation to capture both business value and further efficiencies.

Our experts see this daily as they work with customers around the world, gaining insight into the challenges that companies face and the strategies that are working on the transformation front-lines.

This eBook explores three main trends that we believe CIOs need to be aware of as they consider embarking upon, or continuing, transformations of their own:

  • Companies are looking to scale DevOps beyond individual application pipelines and pilots.
  • IT needs to be able to work at multiple speeds. It’s all about being multi-modal.
  • Security offers a challenge, but a major opportunity, too.

Download the free eBook, written by our Advisory Services and Operations Transformation Services experts, to whether these innovations in the way we manage, deliver and secure IT should be a part of your strategy.

The new culture of IT echoes the industry’s earliest days.

In many ways, it’s back to the future – but we also need some things to change.

Reg Loby Reg Lo

IT cultureTo get a sense of what’s happening in IT today, it can help to have a long term perspective. Think back to the earliest days of computing, for example, and you can see that we’ve almost come full circle – a reality that underscores the major cultural shift that the business is undergoing right now.

When enterprise computers were first commercially available, companies used to buy their hardware from someone else but write their own software, simply because there wasn’t very much packaged software out there to buy.

Then by the ’90s or so, it became the norm to purchase configurable software for the business to use. That worked well for a while, as companies in many different industries deployed similar software, e.g. ERP, CRM, etc.

Today we expect software to do a lot more. Moreover, we expect software to differentiate a business from its competitors – and that’s returning IT to their roots as software developers. After all, the ability to create digital enterprise innovation requires software development skills. And so we’ve made a full arc from a software development perspective.

The Expanding Reach of IT

Now add another historic change that we’re seeing: IT departments used to just provide services for their business, their internal customer, but the advent of the fully digital enterprise is expanding who gets touched by IT. IT departments now need to reach all the way to the customer of the business, the consumer. When we talk about omnichannel marketing, for example, we’re expecting IT to help maintain connections with consumers over web, phone, chat, social media, and more. The same goes for the Internet of Things, where it’s not so much the consumer as a remote device or sensor out in the field somewhere that IT needs to be worried about.

Both broad trends have changed the scope of IT and both are making IT much more visible. More importantly, they mean that IT is now driving revenue directly. If it’s successful, IT makes the business highly successful. But if IT fails, it will directly impede the business revenue flow.

Becoming Agile Innovators

That brings me to my last point. Here’s what hasn’t changed from the past: for the last 30 years or so, the mantra in IT cultures has been “Bigger is Better.” Software Development and Release processes got increasingly bureaucratic and terribly slow (think of those epic waits for the next ERP release). The standard mind-set was to package multiple changes into a single release that they’d roll out every six months or so, if they were lucky.

But that culture is also something that we need to be moving away from, precisely because the relationship between IT and the business it serves has changed. Businesses used to perceive IT as just a cost center that should be squeezed for more and more savings. But when IT touches the end-customer experience directly, business needs IT to be both cheaper and faster – to support and enable the kinds of innovation that will keep the business one step ahead.

We now have the technologies (cloud computing, cloud-native applications) and methodologies (agile development, DevOps) to make smaller, much more frequent, incremental releases that are simpler, less likely to be faulty, and easy to roll back if anything goes wrong.

What we’re still lacking – which I still see when I’m out in the field – is the widespread cultural change required for it to happen. Most importantly, that means adopting what I could call a DevOps mindset across the entire IT organization. At its essence, this mindset views the entire work of IT through a software lens. It makes everything, including infrastructure, code.

For IT long-timers, in many ways that’s simply returning software to the centrality it once enjoyed. But if it takes us back to the early days of computing, it also points us to what we must change if we’re to succeed in a future that’s entirely new.


Reg Lo is the Director of VMware Accelerate Advisory Services and is based in San Diego, CA.  You can connect with him on LinkedIn.

End User Computing Modernisation – Observations of Success

Charles BarrattBy Charles Barratt

As I come to the end of what has been a long customer engagement I find myself reflecting on what went well, not so well and REALLY well. I engaged with a client who was struggling with desktop iStock_000056305548_Large_modernization (300x200)transformation, having been shackled to Windows XP for too long, and had little direction to move in apart from the tried and tested approach of fat client refresh and System Center Configuration Manager (SCCM) application delivery; hardly transformative or strategic. Compared to what they were doing in the datacenter, the desktop environment was light-years behind, yet they had the capability of a modern datacenter to deliver a transformative digital workspace.

All too often, I witness organisations treating their desktop as second-class citizens to the datacenter, when in reality the datacenter is the servant to the endpoint. Those organisations that truly transform their end user computing (EUC) environments do so with three key principles in mind:


All too often, IT starts with technology rather than thinking about what impact modernisation will have on users, their productivity and the financial model associated with end user IT. Gone are the days when we simply issued users with devices and mobile phones and never spoke to them again until they had an issue. Our end users are far more technically savvy and operate their own networks at home, they want to be engaged, they want a say on the appropriate application of technology and they want workplace flexibility; happy workers tend to stay where they are.

Users deserve to be engaged and by engaging them early on EUC transformation you create advocates who are part of the process and want to see it succeed. Don’t underestimate this vital stage. Simply put, “Stop starting with technology.”


It is no longer appropriate to operate end user computing environments in isolation to the rest of the IT organisation. Virtualisation stopped that trend from happening when we saw a movement of the desktop into the datacenter. As organisations start to consume different application and security models your EUC environment needs to be close to the action for performance and operational gains.

To fully harness this change, we see organisations starting to build out a centre of excellence containing members that span the many moving parts of an EUC environment from endpoint, applications security, networks, datacenter and operations. In doing so you can be confident that there will not be overspending on technology, there will be appropriate capacity to support your requirements and the best experience will be delivered to your end users.


I recently saw the lightbulb moment in my client’s eyes when discussing the simplification of application delivery; we were introducing AppVolumes. Rather than dazzle them with science, we had a simple demonstration and a discussion around the time tested install process of “Next, Next, Next Finish” into an AppStack and made them realize that the world has moved on.

As organisations look to re-architect critical applications they need to think about simplifying the application lifecycle management (ALM) for legacy applications, a key capability of AppVolumes. IT brings the ability to shorten the ALM process significantly, from request fulfillment through patching and updates, to drive consistency and stability whilst minimizing the cost associated with lifecycle and change processes.

As with all technologies, you need to make sure the investment reduces the problem and the financial gain supports the change. The architecture and minimal impact on existing processes places AppVolumes in a very desirable place to solve application delivery challenges.

Opportunities to transform the end user computing environment don’t come along very often but their impact on end user computing is prolific. There has never been a more exciting yet complicated time to be associated in this space.

To use the words of the late Steve Jobs, “You have to start with the customer experience and work back towards the technology.”


Charles Barratt is an EUC Business Solutions Strategist for VMware’s Advisory Services team and based in the UK.

Technology is not a Magic Wand for DevOps

Theresa StoneBy Theresa Stone

All too often I walk into companies that want to implement DevOps as part of their software defined data center (SDDC) journey and hear conversations filled with frustration like:

We have implemented 8 new tools and our developers seem to be mostly happy with them; but we continue to have issues delivering anything on time!  Our operations staff are frustrated and internal customers won’t allow their applications in our virtualized environment.


 We bought all these new tools and implemented them, I even paid for my people to have formal training on them, but I don’t feel like we’re any better off than we were before!

Many organizations have bought into the falsehood that DevOps is just a technology play.   That could not be further from the truth, so don’t fall for that trap.   Successful DevOps organizations must focus on a lot more than just implementing technology to achieve success.

IT leaders should invest in cultural changes, people, skills gaps and collaboration issues above all other issues to achieve DevOps success. Organizations embarking on a DevOps initiative need to take a step back and evaluate if you are on track for success by approaching DevOps holistically.   These initiatives require a transformation strategy built around clearly defined goals and the development of a well-defined roadmap that incorporates people, process, technology and culture.

Core Pillars of DevOps Transformation

Here are some activities that are often incorporated in a transformation roadmap for DevOps broken down across the core pillars required for success – note one is not like the others:

DevOps PillarsPEOPLE Transformation

  • Governance frameworks are put in place to support and enable value realization from DevOps
  • Organization and operating models are modified to facilitate holistic changes to culture
  • People are invested in with necessary training and skills enhancements

PROCESS Transformation

  • Operations and development engineers participate together in the entire service life-cycle from design through to production support
  • An incident command system is in place where the development team is involved in incident resolution
  • Processes are re-engineered to be more efficient, lean and repeatable

TECHNOLOGY Transformation

  • DevOps technology improvements place reliance on build, test and release automation along with orchestration across technologies and integrated tool chains using continuous delivery capabilities
  • Infrastructure is treated as code
  • The DevOps team delivers small chunks of value to the customer more often
  • Recovery oriented computing – fail forward

CULTURE Transformation

  • High trust, team culture demonstrating effective, seamless cross-functional collaboration, open communications, performance orientation and learning culture (generative organization)
  • Demonstrated Servant Leadership – enable and serve from the top down
  • Established collective ownership
  • Creativity is encouraged

(All of these culture items must be focused on and incorporated into the attributes and activities above.)

Why is Technology the Pillar Most Organizations Focus on First?

Even though new technology is important and usually required, most organizations focus only on tools and do not achieve desired outcomes.   Why does this happen over and over again?   I believe it is due to a couple of factors:

  1. IT leaders gravitate toward what comes easiest and what seems most important to them – i.e. implementing new technology
  2. Leaders in general have a hard time comprehending the importance of people, process and cultural changes and what that actually looks like; therefore, investments in seeking outside assistance from experts are not made where they may be needed the most

In today’s fast-paced, ever-changing landscape, filled with disruptive technology, successful companies must be strategic and operate efficiently to remain on top.  DevOps is not easy and it does not happen overnight; however, it can produce the desired results if you take a holistic approach.  There are many success stories of those that embraced the changes and transformation needed across people, process, technology and culture to be the new or rising leaders in their industry.    Are you next?


Theresa Stone is a Transformation Process Architect with VMware and is located in Virginia.

Organizational Change: Perfecting the Process

By Richard Hawkins and Greg Link

Organizational change. Re-org. Shaking things up.

These words strike fear into the hearts of those that hear them. They should also strike fear in those that speak them. But sometimes organizational change is needed for some very good reasons. One that comes to mind is structuring IT to deliver end-to-end services and not just applications.

To reduce the pain often associated with Organizational Change, it’s important to have a clear plan in place that addresses each stage of process.  In this blog we’ll take a look at the stages Organizational Change from beginning to end as a primer on what things need to be considered and when.

Everything has a process and Organizational Change is no exception. The diagram below is a high-level overview of each of the 5 stages of Organizational Change.

Organizational Change Process

Step 1:  Gather and Validate Data

In this phase we look at every level of the organization from the top down along with the skills of each role including that of leadership. Fact is, in many organizations poor performance is more a reflection on leadership than the departmental staff.

Step 2: Perform Organizational Assessment

To assess your organization’s readiness for change, there are a number of questions you need to ask yourself. When did the last re-org take place? What changes were made? How was it received? Is a short survey in order? How formal is your organization? Are there roadblocks that can be removed to allow staff to do their job more effectively? How strict are your policies? Obtaining a cultural baseline is not easy, but well worth the effort.

Step 3: Develop Transition Plan

As you start the planning effort, it’s important to justify the change.  Having a good case for why the organization is undertaking this effort will go a long way toward acceptance.  It’s also important to identify ahead of time what cultural barriers you could face blocking a successful change.

Throughout this stage, you should remember that this effort will affect everyone, so consistent communication is key, and involving many layers of the organization, from directors and managers down to “rank and file” in the planning process will go a long way toward ensuring everyone is on the same page.

Step 4: Implement the Plan

This is another busy stage and, of course, the most important. Proper execution of a well developed plan is the key to success in any endeavor.

Leadership roles should lead by example and be fully committed to the change, and that commitment to the goal must continue throughout every level of the organization.  The success of this effort relies on all parties playing their part.

Seek out areas that may encounter resistance and work tirelessly to resolve them with empathy and understanding. Ownership of a problem in this area may not be an individual mater. It may require senior leadership intervention.

This is another phase where communication, through every means possible, is extremely important. The organization should know how things are going and how issues are being resolved in a timely manner.

Step 5: Validate Plan Success

We’ve done a good job at planning and execution so we’re done right? The new structure is in place and no one has quit or expressed any serious dissatisfaction. But are we really done? A truly good manager says “no” and will look back and make sure the plan and implementation achieved the desired outcome.

Make an initial assessment on how well the organization is working after the changes have settled in. A well timed Town Hall will go a long way in gathering the information needed to validate the efficacy and results of the re-org. If as mass gathering is not an option, departmental meeting should be in order.

In our next blog, we’ll explore 10 of the key actions you need to take along each step of this process to ensure success.


Richard Hawkins is a Transformation Strategist based in Seattle, WA.

Greg Link is a Transformation Senior Consultant based in Las Vegas, NV.

ROI Best Practices Series — Part 1: Introduction and Goal of an ROI Analysis

Lisa SmithBy Lisa Smith

When we are considering any large investment either in our personal or work life, it is natural to question how fiscally sound that investment decision is to make.  Whether a company is considering the impact of rolling out a new product to market, acquire a company to gain market share or opening a new factory, using a Return on Investment (ROI) analysis will help define in hard numbers just how much that investment will return to us and over what period will we see our investment paid back.

What constitutes “good” ROI analysis?

Many companies have been using ROI analysis in their demand management programs to evaluative which proposed projects should funded and those which are not.  In a manner, projects are competing for both the company’s focus (labor) and limited capital dollars.

What is ROI?But a good ROI analysis does not tell the whole story a demand management program needs to determine the merit of each project proposal.  Demand management teams are also requesting project teams to include a business case to accompany an ROI analysis.  A company is not just investing their capital dollars in these projects, they are also investing their people time and focus.  We need to ensure that the project focus and execution is supportive of corporate and or business unit’s strategy – we need to have all of our oars pushing the boat in the same direction.

ROI Analysis

As Gartner espouses in their “Total Value of an Opportunity” (TVO) framework, a good business case needs to include analysis of how an investment has strategic alignment and the overall business impact of the project.  Those projects which are ultimately funded should be best aligned to the strategic goals of the company.  While a project many be financially a great decision, if the project’s goals are not in line with where the company is headed, the financial gains should be disqualified.

The goal of the ROI analysis should be to cleanly portray the financial state of “as-is” and the “to-be” future state after making the investment.  Those financial states should include all elements which are going to vary between the optional states.  When considering what metrics should be included in the analysis, it can be confusing where to draw the line – what to include and what to exclude.  What makes a “good” ROI analysis is not that we analyzing every possible cost metric but only those relevant costs which make a material impact in the savings.  The other key element to consider when building your ROI master piece is how consumable is the analysis by your project’s key stake holders.  If your ROI analysis reminds people of something out of the movie “A Beautiful Mind”, you need to step back and re-evaluate your approach.  A clean view of your assumptions, inputs, formulas and a simple side by side financial comparison of “as-is” vs “to-be” is the best to socialize your ROI study and results.

Socializing Your ROI Study

Buy in and blessing of your ROI study is the final hurdle which you need to have a truly successful ROI analysis.  Set up one on one time with various project stakeholders, walk them through your business case and ROI analysis.  A clean set of eyes is a valuable exercise to see where how your analysis holds water, what elements of your Business case needs to be fleshed out and you will immediately see how “consumable” your analysis is by another person.  If everyone asks the same question, perhaps you should that address that question in your presentation?  Let’s face it, with all the time you have been spending on building out your business case, you probably have a lot of key assumptions in your head which might not be obvious to your audience.  Lastly, during those 1:1 sessions with your stakeholders, it is a great time to feel out their support of your project and your quest for funding.

In summary, when building a business case presentation for your project consider the following factors:

  • Explain “How does this project support my corporation’s strategic direction?”
  • Outline “How will the business be impacted by my project’s success?”
  • Summarize results of ROI Analysis including side by side comparison of “as-is” and “to-be” costs.
  • Cover key assumptions, inputs and formals supporting your ROI calculation.
  • Perform key stakeholder reviews to build internal support of your work

What’s next?

This is the first blog in a series that will explore end to end ROI best practices.  Stay tuned for blogs on:

  1. Introduction and Goal of ROI Analysis
  2. Scope of ROI Analysis
  3. Structure of ROI Framework
  4. Different type of Value
  5. Infrastructure Analysis
  6. Process Analysis – Labor
  7. Process Analysis – Time to Market
  8. Process Analysis – Service Impact
  9. Risk Mitigation
  10. Tying it all to together – telling the story
  11. Benefits Realization

Lisa Smith is a Business Value Consultant in the VMware Accelerate Advisory Services team and is based in New York, NY.

From CIO to CEO: How to run an IT as a Service Provider

Jason StevensonBy Jason Stevenson

A service involves two parties: 1) a customer and 2) a service provider.

A service fulfills a customer’s need. Though there may be many components to a service, those technology, process, and people components are combined to form a single service. The customer should not need to understand all the subcomponents of the service to benefit from the service. Nor should any service-specific knowledge be required for the customer to solicit the service. In other words, the service should be expressed in cohesive layman’s terms.

Water Service Example

  • Customer Needs:  Water services fulfill multiple needs: life/thirst, personal/environmental sanitation, etc. If you put in a well, you have your own water and there’s no need for water service. However, if you do not have a well, you will need to engage the county water service provider.
  • Service Provider:  To engage water services, you expect simple contract language and simple commodity pricing. The customer should not need to be a plumber or hydro-engineer to engage the service.
  • Customer Expectations:  Once engaged, the customer doesn’t care how the water gets to them, what must be maintained, or who maintains it. After procuring the water service, they never want to talk to the water service provider again unless their needs change. If water service is interrupted, it’s the service provider’s problem. Customers don’t care what service provider people, tools, or expenses are needed to fix the problem, they just expect it to be rapidly resolved by any means.

How does this example relate to IT services?

First, let’s lay out the key players:

  • CEO, CFO, and stakeholders = Mom and Dad paying for the water service
  • IT Users = the family drinking the water and bathing in it
  • IT department = water service provider
  • IT services = water
  • Data, applications, networks, servers, storage = water treatment plants, water towers, mainlines, pipes, trucks, wrenches
  • IT staff = plumbers and hydro-engineers

Every time a customer experiences interruptions and contacts a water service center, the support call is not considered a “service” but is ancillary to the water service they are already payed for. The customer would rather not engage the service center at all. This is the same with an IT service desk.

Though a water plant monitors water flow and quality, it is not a service. The customer assumes the water is available with adequate water pressure when they purchase the service. This is the same with an IT operations center.

Though hydro-engineers and plumbers may be needed, for example in a large mall complex, they’re assistance would not be a service, rather a project to support the delivery of water services to the tenants and patrons of the mall. This is the same with IT engineers, developers, and project teams.

We assume the water is safe, maintained, and appropriate precautions are taken to ensure ongoing water quality and availability. This is the same with IT security, IT service management, and disaster recovery.

How do CIOs apply this to running as an IT as a Service Provider?

Think of what a water provider service catalog website looks like. It’s pretty simple… Water. Everything needed to supply the water is moot. You may be thinking “Sure this is true of a water commodity but IT is not a commodity.” No it is not… not yet.

So let’s take it up a notch and talk about utilities like telephone and energy services. Their service catalog websites contain utility services. Telephone companies for example list things like local and long-distance, Internet, call waiting, caller ID, conferencing, etc. on their service catalog website. They may also segregate their services by enterprise, small business, and individual customers.

Cable companies are even more similar to IT in some respects. They list things like VoIP communications, Internet, television/entertainment packages, etc. You can draw a parallel between each station offered by a cable company to each application offered by IT.

Regardless of commodities or utilities, service providers of water, power, telephone, cable, etc. have very simple service catalogs considering their extremely complex infrastructure and organizations. This is because the service provider has matured their services to focus on the customer/users and highly refined their services to meet specific customer/user needs, to remain relevant, competitive, and accessible.

To become a true service-provider, IT must take a similar approach to interaction with customers and users. To be successful, CIOs become CEOs by defining a usable service catalog with:

  • A clear business-focus addressing specific needs
  • Inclusive pricing and options
  • Seamless delivery
  • Transparent fulfillment

Jason Stevenson is a Transformation Consultant based in Michigan.

What Is DevOps, and Why Should I Care? — The IT Leadership Perspective

kai_holthausBy Kai Holthaus

One of the newest buzz words in IT organizations is “DevOps.” The principles of DevOps are contrary to how IT has traditionally managed software development and deployment. So, why are more and more organizations looking to DevOps to help them deliver IT services to customers better, cheaper and faster?

But…what exactly is DevOps anyway? It is not a job or a tool or a market segment; it’s best defined as a methodology, or an approach. It has ideological elements that are in common with techniques like Sigma Six and Lean. More on this later.

Software Development and Deployment Today

DevOps todayIn today’s world, there’s a “wall” between the teams that develop software and the teams that deploy software. Developers work in the “Dev” environment, which is like a sandbox where they can code, try, test, stand up servers and tear them down, as the coding work requires. Teams working in the “Ops” environment deploy the software into a production environment, where they also ensure the software is operational. Often, the developed software is literally ‘thrown over the wall’ to operations teams with little cooperation during the deployment.

Why Was It Set Up That Way?

This “wall” is an unintended consequence of the desire to allow developers to perform their tasks, and operational teams to do theirs. Developers are all about change; their job is to change the existing (and functional) code base to produce additional functionality. Operations teams, on the other hand, desire stability. Once the environment is stable, they would like to keep it that way, so that customers and users can do their work.

For that reason, developers usually do not even have access to the production environment. Their work—by nature—is considered too disruptive to the stability of the production environment.

The Problems with Today’s Development and Deployment

Because of the separation between developers and operations, deployment is often cumbersome and error-prone. While developers are usually asked to develop deployment techniques and scripts, these techniques first have to be adapted to the production environment. Then they have to be tested. And since the deployment teams don’t usually understand the new code (or its requirements) as well as the developers, the risk to introduce errors rises. Worst case, it will lead to incidents, which are all too common.

Additionally, in today’s datacenters that are not yet software-defined, new infrastructure—such as compute, storage or network resources—is hard to set up and integrate into the environment. This further slows down deployments and raises the possibility of disruptions to the environment.

DevOps to the Rescue

At its core, DevOps is a new way of developing and maintaining software that stresses collaboration, integration and automation. It attempts to break down the “wall” between development and operations that exists today by removing the functional separation between the teams. It uses agile development and testing methodologies, such as Scrum, and relies on virtualization and automation to migrate entire environments instead of migrating just the codebase between environments.

The main goal of implementing a DevOps approach is to improve deployment frequency—up to “continuous deployment”—of small, incremental improvements to the functionality of software. Essentially, “dot releases,” and with software updates evolving from manufactured media to online streaming, this makes complete sense.


Why DevOps? Why Now?

With the increased availability and utilization of software to provision, manage and decommission resources—such as compute, storage and network in datacenters and IT environments—the DevOps approach is becoming more and more common. IT organizations are now able to create new resources, integrate them quickly into environments, and even move them between environments with the click of a button. This allows developers to develop their code in a particular technology stack, and then easily migrate the entire stack to the production environment, without disrupting the existing environment.

Sounds Great, How Do I Start?

The three main aspects that need to be addressed to implement a DevOps approach for the development and operations of software come down to the familiar elements of project management:

  • People
  • Process
  • Technology

On the people side, teams have to be established that have accountability over the software across its entire lifecycle. The same teams that develop the software will also assure the quality of the software and deploy the software into the production environment.

From a process perspective, an agile development methodology, such as Scrum, must be implemented to increase the frequency at which deployable packages of software are being created. Reducing the amount of change at each deployment cycle will also increase the success rate of the deployments, and reduce the number of incidents being created.

On the technology side, DevOps relies heavily on the Software-defined Datacenter (SDDC), including high levels of automation for the provisioning, management and decommissioning of datacenter resources.

VMware Is Here to Help

VMware has been the leader in providing the software to enable the SDDC. VMware also has the knowledge and technology to enable you to use DevOps principles to improve your software-based service delivery. VMware vRealize Code Stream enables continuous deployment of your software. And if you like to be on the leading edge of technology, check out VMware Photon for a technology preview of software that allows you to deploy new apps into your environments in seconds.

Kai Holthaus is a delivery manager with VMware Operations Transformation Services and is based in Oregon.

4 Key Elements of IT Capability Transformation

worthingtonp-crop-150x150By John Worthington

As with any operational transformation, an IT organization should start with a roadmap that lays out each step required to gain the capabilities needed to achieve their desired IT and business outcomes. A common roadblock to success is that organizations can overlook one or more of the following key elements of IT capability transformation:


Technical capabilities describe what a technology does. The rate of technological change can drive frantic cycles of change in technical capabilities, but often, it is critical to examine other transformation elements to realize the value of technical capabilities.


A people-oriented view of a capability focuses on an organization’s workforce, including indicators of an organization’s readiness for performing critical business activities, the likely results from these activities, and the benefit from investments in process improvement, technology and training.

Transitioning people requires understanding what roles, organizational structure and knowledge will be needed at each step along the transformation path.


A process sharpens the view of an organizational capability. Formally calibrating process capabilities and maturity requires processes be defined in terms of purpose/objectives, inputs/outputs and process interfaces. One advantage of a process view is that it combines other transformation elements, including people (roles) and technology (support for the process).

Transitioning processes is more about adaptation – assuming the organization has defined processes to adapt. While new working methods associated with cloud computing—such as agile development and continual deployment—are driving ‘adaptive’ process techniques, an organization’s process capability will remain a fundamental and primary driver of organizational maturity.


A service consciously abstracts the internal operations of a capability; its focus is on the overall value proposition. A service view of a capability is directly tied to value, since services—by definition, according to ITIL—are a “means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.”

As you assess your organization’s readiness for transformation, and create a roadmap specific to your organization, it’s essential that these transformation elements are understood and addressed.

John Worthington is a VMware transformation consultant and is based in New Jersey. Follow @jMarcusWorthy and@VMwareCloudOps on Twitter.

What is the Difference Between Being Project-Oriented vs. Service-Oriented?

Reg LoBy Reg Lo

Today, IT is project-oriented. IT uses “projects” as the construct for managing work. These projects frequently begin their lifecycle as an endeavor chartered to implement new applications or complete major enhancement or upgrades to an existing application. Application projects trigger work in the infrastructure/engineering teams, e.g., provision new environments include compute, storage, network and security, with each project having its own discrete set of infrastructure provisioning activities.

Project-Oriented vs. Service Oriented

Project-Oriented vs. Service Oriented

This project-oriented approach results in many challenges:

  • There is a tendency to custom-build each environment for that specific application. The lack of standardization across the infrastructure for each application results in higher operational and support costs.
  • Project teams will over-provision infrastructure because they believe they have “one shot” at provisioning. Contrast this to a cloud computing mindset where capacity is elastic, i.e., you procure just enough capacity for your immediate needs and can easily add more capacity as the application grows.
  • The provisioned infrastructure is tied to the project or application. Virtualization allows IT to free-up unused capacity and utilize it for other purposes, reducing the overall IT cost for the organization. However, the project or application team may feel like they “own” their infrastructure since it was funded by their project or for their application, so they are reluctant to “give up” the unused capacity. They do not have faith in the elasticity of the cloud, i.e., they do not believe that when they need more capacity, they can instantly get it; so they hoard capacity.
  • A project orientation makes an organization susceptible to understating the operations cost in the project business case.
  • It makes it difficult to compare internal costs with public or hybrid cloud alternatives – the latter being service-oriented costs.

When IT adopts a service-oriented mindset, they define, design and implement the service outside the construct of a specific application project. The service has its own lifecycle, separate to the application project lifecycles. Projects consume the standardized pre-packaged service. While the service might have options, IT moves away from each application environment since the solutions are custom-built. IT needs to define their Service Lifecycle, just like they have defined their Project Lifecycle. You can use VMware’s Service Lifecycle, illustrated below, as a starting point.

The Service Life-cycle

The Service-Oriented Mindset

This service-oriented mindset not only needs to be adopted by the infrastructure/operations team, but also by the application teams. In a service-oriented world, application teams no longer “own” the specific infrastructure for their application, e.g., this specific set of virtual machines with a given number of CPUs, RAM, storage, etc. Instead, they consume a service at a given service level, i.e., at a given level of availability, with a given level of performance, etc. With this mindset, IT can provide elastic capacity, (add capacity and repurpose unused capacity) without causing friction with the application teams.

The transformation from a project-orientation to a service-orientation is a critical part of becoming a cloud-enabled strategic service provider to the business.  When IT provides end-to-end services to the business, the way the business and IT engage is simplified, services are provisioned faster and the overall cost of IT is reduced.

Reg Lo is the Director of VMware Accelerate Advisory Services and is based in San Diego, CA.  You can connect with him on LinkedIn.