Home > Blogs > VMware Accelerate Advisory Services

Business IT is Coming Out of the Shadows

Harris_SeanShadow ITBy Sean Harris

For a number of years the perception among businesses that internal IT is unable or incapable of delivering to their needs (particularly for new and emerging requirements) has led them to bypass internal IT and source their solutions directly from external vendors. This is commonly referred to as Shadow IT.

According to most analysts (see references below), the shadow is now bigger than original object that cast the shadow, which only happens during the final hours of sunset (an interesting analogy) and has brought about the joke that the title CIO stands for “Career is Over”. Synonymous with this is the rise of the Chief Digital Officer (CDO), Chief Technology Officer (CTO) and application development teams, who are becoming more embedded in the lines of business.

How and why has this happened and what can Enterprise IT and the CIO do to reverse this trend?  Or is it too late?

Why is Shadow IT So Prevalent?

Ten to fifteen years ago, for the vast majority of businesses, IT and technology ran the business. By this I mean they ran the business systems, such as HR, CRM, inventory management, financial systems and logistics. There were a few notable exceptions such as mobile operators, media companies, investment banking and the likes of Thomson Reuters, for whom IT and technology was/is the business. In those cases, the revenue generating services that they provided were dependent on IT and technology.

This is even more true today. There are few, if any, businesses that do not rely on technology and IT of some sort to deliver business services to their customers, partners and channels or use IT to provide technology or IT services to enhance the customer experience. This is part of what is often referred to as the Digital Revolution. So why haven’t internal IT departments benefited from the increasing dependence of the business on IT and technology

There are a number of reasons for this. In no particular order these include:

  • A focus on the stability and reliability of IT systems, and the processes and procedures that support them, at the expense of agility has led to a perception that in-house IT is unable to react at the speed of business. This is despite the fact that technology has moved considerably in the direction of delivering agility combined with reliability and availability.
  • Organisational silos in IT make the organisation rigid and unable to react to the changing needs of the business.
  • A one size fits all approach to IT operations. The push for standardisation and shared services to improve IT operational efficiency has led to a one size fits all approach to IT operations, governance, security and application development/delivery.
  • A focus on IT operational efficiency rather than focusing on end to end business benefits and linking IT investment to business gain (market share, margin and revenue). This is often at the expense of user experience and business outcomes.
  • A lack of clear understanding of the IT and technology needs of the business and the clear articulation of this to all in IT. Without this, it’s impossible to articulate to the business of the value that internal IT delivers.

This has led to the lines of business looking elsewhere to fulfill their technology and IT needs. Most CIO’s and IT departments that I speak to complain of ever increasing pressure to reduce spending on IT and cut costs.  However, many analysts point to an increasing spend on technology and IT (see references below). So where is the money going?

The answer is what we call Shadow IT, but so we can hardly call it “Shadow” any more.  Most analysts point out that Shadow IT spend is now greater than the CIO’s IT spend. It is well and truly mainstream.

5 Steps To Reverse This Trend

Step 1

It may sound blindingly obvious, but the first step is to get a clear understanding of the needs and KPIs of the business and how IT maps into that. From this it is possible to start mapping IT spend into business benefits and making the case for IT investments.

Step 2

The next step is to understand that not all applications are equal. Simon Wardley does an excellent job of explaining what I mean in his blog.  Organisations need to take a good look at their application portfolio, what categories they drop into, what their natural lifecycle is and where they are in that lifecycle. This will help to build a multi-modal IT strategy based on the needs of the business and the applications that support the business services.

Step 3

Next we need to switch to a user experience and business outcomes approach to defining and developing IT services rather than features and functions and a sole focus on IT operational efficiency.

Step 4

Next recognise that in-house is not always the best answer. Sometimes the best solution is a third party service and so you need to build an architecture to support a service broker function. In this way IT can ensure that the business gets the best solution for its needs while ensuring that corporate governance, security, audit and compliance requirements are all meet, something that is often compromised by Shadow IT.

Step 5

The final step is to build an organisation and multiple sets of operational procedures and processes (reflecting multi modal operational requirements) to support all of the above. A key part of this transformation is a clear focus on a service-driven organisation designed around the need to support business services and needs of the business.

To be clear this is not a case of tweaking minor parts of the IT organisation of a typical enterprise.  This is a major transformation, but this is your only hope to stop the increasing marginalisation of internal IT and the role of the CIO.

If the IT organisation is able to make this transformation it will lead to a massive increase in investment in the IT organization, redirecting the business IT spend away from third party vendors and back to the IT organisation.  This leads to a massive change in perception of the contribution of the IT organisation to the business.

If you need help applying these principles to your orgnaisation, VMware’s Advisory Services can help you build a strategy and roadmap to undertake the transformation needed to move to a business focused IT delivery organization, maximising the value (and perceived value) of the internal IT organisation within the business.

References:

=======

Sean Harris is a Business Solutions Strategist in EMEA based out of the United Kingdom.

CIO Imperative: Master Customer Experience to Remain Relevant

Begin a New Life as an Innovation Services Team and Deliver the Experience Your Customers Feel Entitled To

Heman Smithcustomer experienceBy Heman Smith

What is meant by customer experience – for those whom IT serves?

Today’s customers are used to immediate access to an app, typically via a mobile device, immediate ability to execute a task, and immediate results.  This delivers satisfaction and a positive customer experience.  Every industry is experiencing this, with nearly any transaction type you can imagine: banking, healthcare, retail, hospitality, travel and more. Surprisingly, this perceived expectation of immediacy is also spreading rapidly to sectors commonly considered slow to change and respond to change: public sector, utilities, military, etc.

Perception is reality – because people make decisions based on what they perceive to be true. Customers (internal and external) will now often choose the path to easiest results and lowest cost, with less loyalty and commitment than ever before.

What must be done for IT to regain its “preferred provider” status?

Whether we like it or not, IT is not always seen as the business’ preferred provider.  In-house IT is no longer seen as a “must-have”.  Alternatives not only exist, but are expanding and becoming equivalently mature and capable (SaaS, cloud-native apps in the public cloud, etc.). What must IT do now to develop and provide new value to replace its old role and charter?

Optimize Core Services

Immediately and aggressively optimize the core services IT offers that support easy application development, deployment, access and consumption:

  • IaaS, PaaS, Environment as a service, etc.
  • Open and flexible application access
  • Support any app/any device/anytime/anywhere (ie: EUC via solutions such as VMware’s Workspace ONE)
  • Application-focused security based on modern, multi/hybrid cloud-data center network models (VMware’s Airwatch, NSX, etc.)
  • IT-as-a-Business practices: show-back, charge-back, etc.

Embrace the Innovation Services Brand and Mindset

Move away from the legacy name and identity of IT (Information Technology), and adopt a new stance or brand as “Innovation Services”, leading the charge to provide capabilities-as-services needed by the business, using a best resource model as appropriate (developed, or brokered). Much of this change is leadership and culture driven, with process re-design and technology choices supporting the decisions made.

This approach requires the practice of teams counseling together to create an ideal process for delivering more ideal outcomes; both (1) internal to the teams themselves, making their lives easier, and (2) external to the end customer, making their lives easier.  This delivers better customer experience to each party!

Because of this shift in stance, the choice of technologies made by the team(s) is determined by the needed outcome, and how well a technology can rapidly, easily and cost effectively enable that outcome.

Will that cause a lot of technology loyalty shift? Yes.

Must vendors respond by being on-point to support that speed and adaptability in order for their IT customers to deliver better experience and outcomes? Absolutely!

The applications people use, coupled with ubiquitous mobility – are driving the pace of business and IT. DevOps is a response to that opportunity and pressure.

Develop Your DevOps Model… Now

IT must leap into supporting and accelerating the successful adoption of an appropriate-fit DevOps model in order to be of real value to the business. If Infrastructure Services teams don’t clearly understand this mandate, and rapidly take the stance of championing DevOps, then the application development side of the house will find other resources. This change is not optional; it is already underway, and will occur rapidly in the near future whether or not traditional IT teams want it.

If IT doesn’t rapidly respond to this need and change, its chance to be the business’ preferred provider will disappear because some new, successful, out-sourced or internally-stood-up alternative will be entrenched, and change will be seen as too difficult, or unnecessary.

What does this mean for me as an IT leader, and what can I do today?

Delivering exceptional customer experience must be the new mantra and reality for any effective IT leader, and thus for their IT organization. Becoming an “Innovation Services” team, instead of old-fashioned technology maintenance team is the key.

Focus on reducing friction in how any “consumer” (internal / external) accesses and consumes the new services (EUC, IaaS, PaaS, DevOps, etc.). The very mindset of IT staff must shift from habitually operating from a “keep it up and running” mentality – operations first, and adopt a new framework.

Innovation Services now focuses on:

  • How can we make “this” (whatever service “this” may refer to) easier to do, access, support, etc.?
  • How can we make consumption more appealing, more cost effective, more transparent?
  • How can we make us and our services as invisible as possible?
  • And, as I often hear during consulting conversations with frustrated IT leaders: “How can we function more like, so we can compete with, Amazon?”
  1. Mindset is a critical first step: Words have power. So take a stand, make a commitment, and step up to a different future. Craft a vision of opportunity, and invite each member of IT to step into becoming part of the new Innovation Services organization.
  2. Thinking through, and adopting a proven model for change as an Innovation Services provider is the second step. VMware has leading practices and services that assist with this.
  3. Re-organize based on service delivery function, not technology silos.
  4. Stick with it through the challenges of change. Partner with those who know and can coach you to success.

=======

Heman Smith is a Strategist with VMware Accelerate Advisory Services and is based in Utah.

If They Come – Are You Ready?

Part 1:  Optimizing demand management to deliver “Just in Time” cloud service provisioning.

Bill IrvineBy Bill Irvine

Demand ManagementA common phrase overheard during the creation of new cloud based innovation environments for modernized applications is “build it and they will come”.

The surprise for many IT organizations is that they do come and the challenge becomes dealing with that success and the on-going management of their new environments. Many organizations do not operationalize their capabilities or establish the governance processes they need to be successful as a cloud service provider by the time the technology goes live.

Common Complaints about Cloud Services

In my work with customers designing solutions to address the needs of their business via cloud-based innovation, we hear a consistent list of concerns.

“We are always blindsided by requests that we don’t have the capacity to fulfill – it came out of nowhere”

“We never get enough specific information from the business on what they want until it’s too late”

“They always want to over-provision the environments – we’re always in negotiation mode on resource requirements”

“There’s never enough capacity to meet the business and operational demand”

“Nobody ever gives back resources – even when we know they’re not being used”

“There’s never enough budget to buy capacity when we need it”

“We are always getting escalations about the speed of provisioning and spend most of our time reacting to delayed and unfulfilled requests”

“We have to wait for approvals for every piece of the PaaS puzzle”

 “Everything we do is custom which makes it impossible to automate”

These and a host of similar issues relate to a common theme – the need for effective demand, capacity and request management to ensure a standardized, streamlined, consistent and automated approach to service provisioning.

In this blog series, we will cover each of the key processes in the lifecycle and their importance in creating an IT service brokerage model that can always support the dynamic business demand. The expectations on IT have never been greater.

Communication is Key to Demand Management

The primary goal of demand management is to understand the pipeline of service requirements from the business and to interpret these needs into a predictable forecast of consumption. This forecast becomes a vital part of ensuring that IT always has the capacity to fulfill the evolving requirements and requests.

Sounds easy enough, but the challenge in predicting demand for most organizations is the difference in language between the Line of Business (LOB), the development teams supporting them and the infrastructure providers charged with hosting the services.

IT capacity planners want technical specifications and details of the individual resource components (CPU, Memory, Storage etc.) required in order to ensure the appropriate configuration of resources in the correct “landing zones”.

The business representatives however, typically present their needs in terms of market growth, marketing initiatives that may drive increases in transactions or potential decreases in business volume based on the seasonality of the service supported. These needs are rarely static by nature and evolve over time from conception to reality.

The conversion of business and service needs into technical resource requirements is often more art than science and relies on effective communication and collaboration between a broad group of stakeholders to continuously interpret, structure and mature demand data into knowledge that can be acted upon.

IT needs to interact proactively with the stakeholders to identify demand as early as possible at its source. This source data should be documented in a system of record so that it can be tracked, aligned by service and updated as more detailed information becomes available.  Demand data is progressed through a maturity funnel where requirements are codified, refined, validated, prioritized and compared against historical patterns & trends. This enables the initial business data to be transformed into technical resource requirements and actionable plans.

Demand Maturity Concepts

In order to create a comprehensive and contextual picture of current and future business and service demand, requirements should be subjected to a series of analytical steps to refine the demand.

demand management maturity
Fig 1. Demand Maturity Funnel

  • Capture data from all available sources. Different sources will have differing levels of specificity from business concept to actual service performance data.
  • Understand the sources (e.g. LOB, Service data, etc.) to enable comparisons and correlation with past requirements. Grouping requirements by service should become the overall organizing principle to help make sense of the overall demand.
  • Develop, configure and size a logical grouping of resources into a service offering (e.g. Infrastructure or Platform as a Service) to simplify the calculation of future needs and enable IT to better standardize and automate the provisioning processes. Pre-defined service offerings also provide the opportunity to steer the customer towards preferred solutions that are more efficient and cost effective.
  • Identify patterns of business activity (PBA) for each service and develop educated assumptions as to future needs through the analysis of past requirements, requests and configurations. It’s OK to make assumptions, the business is often guessing at the early stages. Even placeholder information can be valuable especially early in the funnel. Assumptions can be validated and adjusted over the life of the requirement.
  • Develop LOB user profiles and analyze their service usage patterns to further refine the understanding of the needs and requests.
  • Understand existing patterns of business activity, prior demand and the technical profile of related platforms consumed by the specific business unit, the applications supporting the service and the volume of transactions to form an evolutionary pipeline or funnel.

Demand requirements managed through these activities will provide IT the confidence to commit to more aggressive service levels and guarantees regarding capacity and associated cloud resource provisioning.

Key Demand Management Roles

As mentioned, there are many parties and stakeholders involved in managing demand effectively. The most obvious and often overlooked stakeholders are the lines of business themselves. IT’s continuous interaction with the business is key to their improved understanding of the customer needs and to break the cycle of being reactive and unresponsive.

Two of the key roles to ensure this ongoing relationship and demand based dialog are the Business Relationship Manager (BRM) and the Service Owner. These roles are critical to understanding the patterns of business and service activity and ensuring appropriate capacity and capability on a service-by-service basis.

The BRM has a primary responsibility to represent all of elements of IT and the associated service provision and performance to the business function. They are responsible for orchestrating the capture of demand from the business and assisting in the conversion of these needs into the technical capacity that meets the expectations. BRM activities in support of demand prediction include:

  • Identification of customer needs
  • Capture of planned projects and initiatives
  • Communicating changes in service profiles or volumes
  • “Selling” the improvements in service capabilities and helping to influence customer behavior and optimize the business usage of the services provided.

The Service Owner ensures that there is an understanding and awareness of the service as a whole, who utilizes the service, how it supports the business functions, the service capabilities and the current service performance. The Service Owner will be responsible for:

  • Quantification and codification of the overall service needs, resource proportions, configuration and operational dynamics to optimize the performance of the production service
  • Key input into decisions regarding resource capacity and configuration changes required
  • Creation of the environment profiles and service offerings used in the downstream environments (e.g. Dev, Test, QA) as required by the development and operational functions

Demand Management Benefits

Implemented successfully, demand management will enable improvements across all aspects of service provisioning but especially in the areas of capacity and request fulfillment.

Some of the key benefits include:

  • Increased customer satisfaction with services and requests being provisioned without the delays inherent in a reactive environment
  • Improved and faster understanding of service and business requirements with demand being objectively quantified
  • Capacity based risk is identified and addressed throughout the course of the above activities
  • Accurate demand and capacity trending will reduce “over-provisioning” and provide more accurate budgetary planning data to optimize resource / infrastructure costs
  • Basis for JIT (Just In Time) purchasing and release of capacity using confidence-driven forecasts
  • Improved alignment with business goals giving an accurate “picture” of demand activities required to enable business goal attainment
  • Increased confidence in allocation of IT resources and their readiness for service provision

Next Steps

So how do you get started with improving demand management? Some proven initial steps developed with our customers include:

  • Start talking to the business customers and associated development teams to open the dialog and establish the process
  • Enhance standard requirements capture with each line of business defining their requirements by service
  • Capture future needs and updates earlier in the lifecycle to feed the forecasting process
  • Update the guidelines for all requirements capture to be consistent regardless of type (e.g. innovation, run, grow etc.) in a common format for input into demand planning
  • Establish improved methods for collecting trend based run and growth requirements by service.
  • Develop Patterns of Business Activity for each service and monitor key performance and consumption metrics to model current and future operational needs.
  • Analyze and redefine the real-time metrics you collect to better track and report against ongoing capacity use, headroom requirements and growth

In my next post in the series, I will discuss the capacity management stage of lifecycle, focusing on the conversion of demand into capacity requirements and optimization of the overall capacity plan.

=======

Bill Irvine is a Principal Strategist with VMware Accelerate Advisory Services and is based in Colorado.

IT’s Payback Time – Part 2: Avoiding the risks that prevent ROI realization on IT innovation

Les ViszlaiBy Les Viszlai

ROI In part 1 of this two-part series we discussed how economists use many formal models to calculate ROI (Return on Investment), TCO (Total Cost of Ownership), as well as some of the methods for determining IT Business Value and payback periods.  In this post we’ll dig into the areas that can delay or prevent you and your organization from realizing the projected benefits from this ROI activity.

It’s critical that your ROI initiative has a communication plan that clearly communicates the status, timing and risks to the ROI initiative on a regular basis.  It’s not unusual for IT organizations to spend a lot of upfront effort to get business approval to proceed with an initiative, disappear and later back pedal on why the ROI initiative failed.

Potential Risks to ROI

There are a number of risk areas that can potentially impact the realization and value of an ROI initiative.

Financial

Changes in the business may cancel/delay the ROI initiative.  The initial ROI may be based on spending money that has a longer payback period then the business is now willing to take on in the current budget reporting cycle.  

Human Resources

Describes the people component of ROI initiatives.  A lack of training or not having the right people to execute and manage the project results in project timelines that are delayed.  Additional unplanned staff costs can be incurred in order to rework or complete the initiative.  Consider adding the cost of using Professional Services firms that have the expertise to accelerate the project as part of the initial ROI calculations to avoid these often costly unplanned costs.

Legal/Governance

Requirements change due to unforeseen circumstances or new industry related compliance requirements that present themselves after project kick off, and additional resources (Technology/People/Funding) are required to complete the ROI initiative.  This additional resource requirement may wipe out any of the original ROI benefits due to unplanned delays or costs.  

Management

Priorities can simply change and management’s commitment to support and funding can be delayed or cancelled. Having a solid communication plan in place keeps the initiative on managements radar and reduces the chances that their interest will wane.

Market

Market changes and competitive pressures or new customer demand may cause management to delay or cancel the project.  Resources (people/funding) can get diverted from IT to other areas of the business.

Organization

Political infighting or parent company relationships may limit ROI benefits. There can be a dependency on the business unit to use technology/services that benefit the parent company, increasing costs at the subsidiary level and reducing the ROI benefit. For example, if the parent company institutes an accounting package that enables simplified reporting across all of its subsidiaries, the costs increase to maintain and implement this system and impacts any resource savings.

Dependencies

Reliance by the current ROI initiative on a different project or initiative is a common risk.  Key resources (people/time/money) can be tied up which can impact the projected ROI of our current initiative.

Technology

Implementation related ROI activities can be affected by chosen technology that is not compatible with an existing system (not uncommon).  Or the new technology could have limited scalability and can’t handle the current or projected system demand.  A simple example is the case of existing switches that can’t handle the new call center phone system volume, or a new cloud services provider can’t handle the volume the business is generating.

Users

ROI benefits may be based on when and how users will utilize the new capabilities.  Anything that prevents them from doing so will be a risk.  The ROI initiative should have a strong end user communication component that describes why/how/when the transition will happen, and don’t forget the end user training if its needed.

Vendors

When you engage vendors to provide critical services/technology, sometimes they won’t execute as promised or go out of business before the initiative is completed.

Keep Your Guard Up

ROI RisksBe aware of the potential risks that may impact your ROI initiative during the initial analysis phase and factor that contingency into your planning.  A strong predefined communication plan will go a long way in preventing and/or minimizing the impact of many of the potential risk areas described in this blog. I personally like the traditional high level red/yellow/green dashboards that give a snap shot of risk over time, but use whatever works best for your organization to keep these risks top of mind.

=======

Les Viszlai is a principal strategist with VMware Advisory Services based in Atlanta, GA.

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.

A Foundation for DevOps: Establishing Continuous Delivery

Peg EatonBy Peg Eaton

As Practice Director for VMware’s DevOps & Cloud Native Apps Professional Services team, I lead a a specialized team of developers with decades of experience helping customers reach their DevOps goals.

In our experience, many organizations have accepted that they need to apply DevOps best practices to accelerate application delivery, and they are in the early stages of developing their strategy for moving forward.

They’ve heard terms like continuous integration and continuous delivery, but have difficulty mapping out what their optimal DevOps tool chain would be, faced with a large, and growing number of technology options, a lack of standardization, and very often, widely differing opinions within the organization on what’s right for them.

In this short video, I walk through our own best-practice example of a Continuous Delivery Pipeline, discuss the software stacks that comprise the tool chain, and pass on DevOps best practice advice along the way.

The Continuous Delivery Pipeline

The Continuous Delivery Pipeline contains inter-related software stacks which support the pipeline stages and activities; enabling repeatable and reliable software delivery by application teams.

You will notice notice as we go through the stacks….you have options. You might choose VMware solutions for some of these areas.  Or you might have made other investments. That’s ok. We believe in our products, but we’re committed to helping you create a seamless integration between all these moving pieces, regardless of which software solutions you choose.

Let’s start with the Planning Stack. This software stack supports agile development throughout the delivery pipeline — planning and tracking software releases; creation of user stories; sprint planning, backlog management, and issue tracking. Typical tools used in planning are JIRA, Redmine, Trello, GitHub Pages, and MS TFS

Next in the toolchain is the Coding Stack. The software in this stack is used for the coding effort against the user stories. We have integrated development environments, editors, debugging tools, and unit-test tools. Geany, Atom, Eclipse, MS-TFS, and vRealize Orchestrator are commonly used tools. Other software in this stack used to support application development: pre-configured developer-workstations, and the environments for application unit-tests (essentially a set of VM blueprints).

The Commit Stack supports version control and many best practices including: daily check-ins, committing assets early and often, automated style-checking, and code reviews. Typical tools include Git, GitHub, MS TFS, and Gerrit.

Developers need fast useful feedback once code is committed; continuous integration tools support automated software builds and automated smoke tests. The Continuous Integration Stack, uses tools like Jenkins, Gerrit Triggers, and vRealize Automation.

The Testing Stack is used in managing testing throughout the software development lifecycle. The key to high productivity and quality code is developer-driven testing in production-like environments for each phase of the lifecycle — it is more effective to expose and remediate issues earlier in the lifecycle. For this stack, you can use tools such as Selenium, REST-assured, soapUI, SonarQube, and vRealize Automation.

The Artifact Management Stack supports the management of application artifacts including binaries; and provides package version control and dependency management of the artifacts. Tools for artifact management include JFrog Artifactory, and vRealize CodeStream.

The next stack focuses on Continuous Deployment and provides support for consistent deployments to every environment – UAT, Staging, and Production. You can use tools like Jenkins, Ansible, vRealize Automation, and vRealize Orchestrator, and vRealize CodeStream.

Next in the tool chain is the Configuration Management Stack, which supports application and environment configuration and is often tightly integrated with the deployment stack. Typical tools in this stack are Ansible, Chef, Puppet, and Chocolatey.

The Control Stack comes next, and is used for application and infrastructure behavior monitoring — alerting, dashboards, logging, capacity management throughout the release process and into production. You can use the vRealize Suite at this stage, including vRealize Operations and vRealize Log Insight, as well as Nagios.

Last but not least is the Feedback Stack, which provides automated feedback to the right people at the right-time during all phases — alerts, auditing, test results, build results, deployment — touching all areas of the pipeline. Github Issues and Slack can be effective tools in this stage.

There are a LOT of moving pieces – it is COMPLEX – and I am sure you are concerned about how in the world to make them all play nicely together! Our capability is in getting all of these moving pieces to work together for a continuous, well monitored flow.

Shift Left

So how does this tool chain help your Dev and Ops team to accelerate application delivery?
Well, application development teams today have moved into the traditional infrastructure and operations space in order to accelerate application delivery.

Application teams require fast-feedback and optimal execution flow during the development life-cycle, and for this they need consistent, production-like environments everywhere and on-demand, continuous integration and deployment, and automated testing throughout the application release lifecycle.

As a result, the dev teams are deploying and managing tools, and automating tasks throughout the life-cycle to support these requirements.

Infrastructure & Operations teams that are concerned with governance and stability can participate in this “shift-left” by working in a high-trust culture where Dev & Ops collaborate to build the optimal execution flow.

Treating infrastructure like code benefits both Dev and Operations, enabling you to version infrastructure definitions with code and use consistent, production-like environments everywhere

A shift-left takes the burden of tool-chain management off the development teams and provides the infrastructure & operations team the visibility, governance, and control to support the business.

VMware DevOps Foundation Solution

The VMware DevOps Foundation Solution (currently available in North America only) enables our customers to implement and operate a Continuous Delivery tool chain with prescriptive stacks of best of breed tools based on common industry patterns and your own environment’s requirements, whether your apps are developed using C#, Java, Python, Go or other programming languages.

The fact that our stacks are pre-integrated means they are ready to use much more quickly, thereby providing a faster time-to value in delivering your applications.

Worried that you are already using a certain tool that you didn’t see in this presentation – don’t worry, these stacks are flexible and we have worked with almost every tool on the landscape.

Creating the DevOps tool chain that will work for you can be complicated, but we’re here to help.

To get started, contact your VMware rep to set up a 1-hour meeting with my team to discuss your goals for Continuous Development. We will then schedule a half-day workshop on continuous delivery and DevOps best practices with your development and operations leaders to kick the project off on the right foot.

We look forward to working with you to make your dreams for accelerated application delivery a reality!

=======

Peg Eaton is a practice director for VMware’s DevOps and Cloud Native Apps Services Organization and is based in Massachusetts. 

Join us at EMC World for an IT Transformation Quick Chat

EMC WorldAre you attending EMC World next week in Las Vegas?  Join us on Monday, May 2 at 2:00 pm or on Tuesday, May 3rd at 10:00am for a Quick Chat in the Veronesse 2401B conference room.

The State of IT Transformation
with Bill Irvine, Principal Strategist at VMware

Gain strategic insights from our overview of “The State of IT Transformation” report, which was recently published by EMC and VMware after an analysis of data provided by more than 660 global firms.

Speaker
Bill Irvine is a Principal Strategist within the VMware Accelerate Advisory services team. As a pragmatic strategic consultant and an ITIL® certified Service Manager, Bill has worked with some of the top Fortune 1000 companies to identify and grow business value by developing practical and “right-sized” solution strategies with actionable roadmaps.

Successful Transformations Require Clarity in Strategy and Execution

Heman Smithby Heman Smith

blog_graphic_CIO_clarityThe recent “The State of IT Transformation” report by VMware and EMC is an up-to-the-minute overview of how companies across multiple industries are faring in their efforts to transform their IT organizations.

The report offers valuable insights into the pace and success of IT transformation over the last few years and outlines where companies feel they have the most to do. But two specific data points in the report – highlighting gaps between companies’ ambitions and their actual achievements – struck me in particular. Here they are:

  • 90% of companies surveyed felt it important to have a documented IT transformation strategy and road map, with executive and line of business support. Yet over 55% have nothing documented.
  • 95% of the same organizations thought it critical that an IT organization has no silos and works together to deliver business focused services at the lowest cost. And yet less than 4% percent of organizations report that they currently operate like this.

Both of these are very revealing, I think, and worth digging into a little deeper.

Taking the second point first, my immediate reaction here is: Could IT actually operate with no silos? Is that ever achievable?

To answer, you have to define what “silo” means. A silo can be a technology assignment (storage, networking, compute, etc..) and that’s usually what’s meant within IT by the word.  Sometimes, though, it represents a team assignment, whether by expertise or a focus on delivering a particular service, that is in its own way a type of silo.

So when companies say they wish they could operate with no silos and be able to work together, I wonder if that’s really an expression of frustration with poor collaboration and poor execution? My guess is that what they’re really saying is: “we don’t know how to get our teams, our people, to collaborate effectively and execute well.”

If I’m right, what can they do about it? How can companies improve IT team collaboration, coordination, and execution?

Being clear about clarity

The answer takes us back to the first data point, that 90% of companies feel it’s important to have a documented IT transformation strategy and road map with executive and line of business support, yet over 55% have nothing documented. A majority of companies, in other words, lack strategic clarity.

Without strategic clarity, it’s very difficult for teams to operate and execute toward an outcome that is intentional and desired. Instead they focus on the daily whirlwind that surrounds them, doing whatever the squeakiest wheels dictate. I’m reminded of what Ann Latham, president of Uncommon Clarity, has said: “Over 90% of all conflict comes from a lack of clarity.”

Clarity, in my experience, has three different layers.

Clarity of intent.

This is what you want to accomplish (the vision); why you want to do it (the purpose); and when you want it done (the end point). You can also frame this as, “We want to go from X (capability) to Y (capability) by Z (date).”

Clarity of delivery.

As you move towards realizing your vision, you learn a lot more about your situation, which brings additional clarity.

Clarity of retrospect.

We joke about 20/20 hindsight, but it’s valuable because it lets us compare our original intentions with outcomes and learn from what happened in between.

Strategic clarity is really about that first layer. If companies are not clear upfront about what they want, it’s almost impossible for their teams and employees to understand what’s wanted from them and how they can do it – or to track their progress or review it once a project is complete. Announce a change without making it clear how team members can help make it a reality and you invite fear and inertia. While waiting for clarity, people disengage and everything slows down.

I’ve seen, for example, companies say they’re going to “implement a private cloud.”  That’s an aspirational statement of desire, but not one of clear intent. A clear statement of intent would be: “We’re going to use private cloud technologies to shift our current virtual environment deployment pace of 4+ weeks into production to less than 24 hours by the end of June 2016.” Frame it like, and any person on the team can figure out how they can or cannot contribute toward that exact, clear goal. More importantly, the odds of them collectively achieving the outcome described by the goal are massively increased.

I suspect that the overwhelming majority of companies reporting that they’d like a strategic IT transformation document and road map but don’t yet have one, have for the most part failed to decide what exact capabilities they want, and by when.

This isn’t new. For the last 30 plus years, IT has traditionally focused on technologies themselves rather than the outcomes that those technologies can enable. Too many IT cultures do technology first and then “operationalize it.” But that’s fundamentally flawed and backwards, especially in today’s services-led environment.

Operating models and execution

Delivering on your strategic intent requires more than clarity in how you describe it, of course. Your operating model must also be as simple and as focused as possible on delivering the specific outcomes and capabilities outlined in your plan. Otherwise, you are placing people inside the model without knowing how they can deliver the outcomes it expects, because they don’t know what they’re trying to do.

Implementing an effective operating model means articulating the results you are looking for (drawn from your strategy), then designing a model that lets employees do that as directly and rapidly as possible. That’s true no matter what you’re building – an in-house private cloud, something from outside, or a hybrid. Everyone needs to know how they can make decisions – and make them quickly – in order to deliver the results that are needed.

That brings me to the my last observation. When companies have no documented strategy or road map (and remember that’s 55% of companies surveyed in the VMware/EMC report), they are setting themselves up for what I call “execution friction.” With no clear strategy, companies focus on technology first and “operationalize” later. They end up in the weeds of less-than-successful technology projects, and spend energy and resources on upgrading capacity, improving details, and basic IT pools, while failing to craft a technology model that supports delivering the capabilities written in their strategic model. It’s effort that uses up power while slowing you down instead of pushing you forward: execution friction. Again, it’s viewing IT as a purchase, when today more than ever it should be viewed as a strategic lever to accelerate a company’s ability to deliver.

In his book on strategic execution, Ram Charan says that to understand execution, you need to keep three key points in mind:

  • Execution is a discipline, and integral to strategy
  • Execution is the major job of the business (and IT) leader
  • Execution must be a core element of an organization’s culture

Charan’s observations underline what jumps out at me in the data reported by the VMware/EMC study: that you can’t execute effectively without strategic clarity.

Wise IT leaders, then, will make and take the time necessary to get strategically clear on their intended capability outcomes as soon as possible, then document that strategy, share it, and work from it with their teams in order to achieve excellent execution. If more companies do that, we’ll see silos disappearing in a meaningful way, too, because more will be executing on their strategy with success.

=======

Heman Smith is a Strategist with VMware Accelerate Advisory Services and is based in Utah.  

Moving Beyond Infrastructure as a Service to Platform as a Service

Brian MartinezBy Brian Martinez

What's Next - PaaSMy VMware colleague Josh Miller recently explored how companies are extending a DevOps model into their infrastructure organizations and what can be done to speed that essential transition.

I want to talk about the step after that. Where do you go after achieving infrastructure-as-a-service?

Here’s how I think of it. Infrastructure as a service (IaaS) focuses on deploying infrastructure as quickly as possible and wrapping a service-oriented approach around it. That’s essential. But infrastructure in itself doesn’t add direct value to a business. Applications do that. In more and more industries the first company to release that new killer app is the one that wins or at least draws the most value.

So, while it’s essential that you deliver infrastructure quickly, it’s worth lies in helping deploy applications faster, build services around those applications, and speed time to market.

So you have IaaS, what’s next?  Enter the concept of the platform as a service (PaaS). PaaS can be realized in a variety of ways. It might be through second generation platforms such as database-as-a-service or middleware-as-a-service. Or it could be via third generation platforms based on unstructured PaaS like containers (think Docker) or structured PaaS (think Pivotal Cloud Foundry).

The flexibility you have in terms of options here is significant and your strategy should be based on the needs of your developers.   Many times we see strategies built around a tool name instead of the outcomes needed from that tool.  Listening to the developer’s needs should help determine what the requirements are.  Then build backwards from there.  Often we you won’t end up with the same tooling then you thought you would.

All the approaches to PaaS, though, share a key feature: they are driven by both a holistic and a life-cycle view of IT. In other words, it’s dangerous to view any IT function today as either separate from any other, or as a one-time deal. Instead, we need to be thinking of everything as connected and at the same time being constantly iterated and improved.

Work from that perspective and it’s easier to navigate the often daunting array of options you have when it comes to PaaS.

Certainly, as you move along this path, it’s very possible to end up with multiple, small cloud-native apps deployed on multiple platforms spread across multiple different data sets – so be aware of the lifecycle.

One other note: there are so many different tools coming to market so quickly in this space that what you pick now may not be what you use in a couple of years. A lot of our customers are nervous about that. So it’s worth remembering that these tools are designed so that you can move your code, and the work that you’re doing with the code, to whatever platform is best suited to deliver it to your customer.

The bottom line: Encourage your customers to try things out so they can create DevOps learning experiences.  Be responsive in enabling developers to access new tools, while setting the right boundaries on how they can use those tools (think service definition) and where they bring them to bear.  Approaching PaaS with a unified culture of continuous iteration and improvement will enable your developers with the tools they need to move fast, without losing the control and stability essential to IT operations.

=======

Brian Martinez is a Strategist with VMware Advisory Services and is based in New York.

IT’s Payback Time – Calculating the ROI on IT Innovation – Part 1

To justify investment in new IT projects, we need to show that it pays off – here’s how to do that.

Les Viszlaiby Les Viszlai

ROI Calculation“Innovation in IT pays for itself.”  That’s something pretty much everyone in IT believes. But it’s also something that a surprising number of companies I visit aren’t in a position to prove.  Why? Because most companies don’t actually know what it costs to provide their IT services and can’t quite put a figure on the benefits IT innovation projects can bring.  Missing these key data points can make it very difficult to quantify the Return on Investment (ROI) or payback on any IT project, making it harder for IT to compete internally with other departments for scarce business funding.  Many times, approved IT budgets get frozen or delayed because the business does not understand the value of the projects in question and opportunities are missed or delayed.

In Part 1 of this blog series, let’s begin at a basic level in order to get you familiar with the topic of calculating ROI.  We’ll dig in to what you can do to calculate whether an IT project will be self-funding.

Calculating Basic ROI

ROI Increased Revenue Cost ReductionEconomists have used many formal models to calculate ROI (Return on Investment), TCO (Total Cost of Ownership), as well as methods for determining IT Business Value and payback periods.  For this conversation, let’s focus on basic ROI, and ask the question: if we spend X dollars on a new IT project or service in order to get a new or existing capability, will we spend less money than we are paying now for the equivalent capability or service that we will replace?   If an initiative does this, then we can easily make the case for moving forward with that innovation program.

To figure this out, we’ll look at these two areas:

  • Reduced or avoided capital and/or operational costs
  • Increased/Enhanced Revenue

Hard Costs and Soft Costs

Hard cost is money we have to pay. Most hard cost savings or cost avoidance opportunities are fairly easy to quantify. These savings will include the cost of hardware and software you no longer need to pay for and savings from staff reductions and licenses you will no longer need.   However, don’t forget to factor the added cost of the new hardware and software you are installing, any one time professional services fees you will need in order to deploy everything in place and any new staffing needs.  But this should all be relatively easy to quantify from a hard cost standpoint.

Soft cost savings or cost avoidance is more complex, because the benefits accrued are harder to put actual numbers on and its harder to get internal agreement on how its determined. In addition, most companies capture this information over a 3 to 5-year period, which may compete with short-term goals.

If you are already measuring soft costs today, then you’re ahead of the game.  However, you might be surprised by how often I see organizations failing to quantify them. The main reason, typically, is that nobody wants to do the work or no one understands the benefit. Quite often, I see companies look at an IT project purely from a hard cost savings perspective and say, “We can’t figure out how much time this will save, or how much happier this will make the client, so we’re not going to use these additional metrics as a measurement for this project.”

For those of you that want to start looking at this, I suggest reviewing the benefits below to see if they are addressed in the proposed project.  These project benefits are easier to quantify and can easily add up to substantial savings over time.  To calculate the savings for projects designed to improve existing capabilities, look at the current delivery time and associated costs and then subtract those numbers from the new projected delivery time and costs.

Will this IT project:

  • Provide faster delivery times?
    With simplified work flows and more repeatable processes being done more often by a machine automation, we can look forward to faster delivery times.  In order to calculate this, we multiply the current hourly FTE costs by the average delivery duration, by the number of requests on a yearly basis and compare that to the new times and costs.
  • Reduce the cost of training?
    With a simplified system, can we reduce training times for people new to the company, and likely employ more junior staff and divert more senior staff to innovation activities.   These savings can be quite high in organizations that have seasonal hiring needs and organizations that have a high staff turnover.
  • Lower regulatory and compliance costs?
    Automation and simplification activities can have a significant impact on reducing the cost of compliance, especially in regulation-intensive sectors like healthcare or finance.  These savings can be calculated by tracking the current FTE time used to manually record and document audit related activities and compare that to the improvements driven by the project.
  • Reduce human and machine errors?
    With simpler, more repeatable processes being done more often by a machine, we can look forward to less failures.  In order to calculate this, we multiply the current hourly loss, by the average downtime duration, by the number of times this happens on a yearly basis.
  • Drive faster resolution times?
    Using MTTR (how long it takes, on average, to restore a system) we multiply the number of incidents, by the time it takes to resolve, by the cost of personal on a yearly basis.

The above is the short list of soft cost savings you can use as a starting point.  They are easier to quantify and get agreement on, and collectively they can seriously add up.

Projecting Increases in Revenue

It should also be entirely possible to figure what the IT project change will do for your revenues.  Just to be clear: we’re not talking about the results of funding an entirely new product. We’re talking about the revenue enhancements that come with the cost avoidance/reductions and efficiencies tied to existing product/service lines.

Let’s take this scenario for quantifying IT Project payback: A business owner is running a web store where it takes a customer 3 minutes to buy something, but 90% of customers abandon the sale after 38 seconds. Along comes the innovative IT team, offering a project that reduces the average time-to-purchase down to 30 seconds. It’s entirely feasible, then, to figure the increased revenues that ought to accrue, all other things being equal, from the technology change and the faster buy time.

Again, the biggest thing that I see getting in the way of these kinds of calculations is that businesses first have to commit to doing them. I don’t think it really matters which method we use (ROI, EVA, TCO, they’re all fine). We just have to get agreement to pick one.

By doing the work upfront and having those numbers available for review, you put senior leadership in a better position to approve the IT project proposal.  It also leaves very little room for debate on the savings value of the project since we have established agreement within the organization on how the ROI is determined.

Key Take-Aways

  • Don’t forget to establish how you will calculate the expected ROI as you set an innovation strategy.
  • Don’t be hesitant to dive in.  Just pick an accounting method, get agreement on it within your organization, and then start doing the math.
  • This pays off!  In all likelihood it will help you prove that IT innovation does indeed pay for itself.
  • When IT innovation can pay for itself, this leads to more innovation, and that leads to increased customer satisfaction or added brand value, which of course will have a positive direct impact on your business.

Stay tuned.  In my next blog we will dig into the obstacles to watch out for that impact our ability achieve the projected savings.

=======

Les Viszlai is a principal strategist with VMware Advisory Services based in Atlanta, GA.