Anyone who has ever struggled with the “moving from CAPEX to OPEX” question knows that it is one of the most difficult barriers to overcome within IT. Although it is a challenge, it can be achieved if you can answer the following 3 questions:
- What is the barrier?
- Why do we want to overcome the barrier?
- How do we overcome the barrier?
In the rest of this post we will try to answer each one of these quandaries.
What is the barrier?
Resistance to moving away from CAPEX essentially falls into 2 categories: Business Resistance and Finance Rules.
Business resistance to loss of control
As we’ve seen with the move to virtualization, one of the biggest obstacles to adoption is resistance from the business because of their sense that they are losing control. In the days of old, the business was used to having a ring-fenced domain where its developers, production support, and users had complete control over its every detail. IT was there to just make sure that the network and server were up and running. The idea of sharing was a completely foreign concept. They had a CAPEX budget and they wanted complete control over how it was used. Going to a completely shared environment is just one of the last steps of a process that started many years ago, but is still no less difficult.
Business resistance to show back or charge back
Invariably when we discuss OPEX, the topic of show back and charge back come up. In an effort to use resources more efficiently, many organizations attempt to instrument first show back (or shame back as its known in some circles) and then charge back. Like above, the business is not used to having to justify the use of resources it paid for and is, not surprisingly, resistant to the idea of starting.
Although various elements of the business will resist going to an OPEX model, the biggest challenge to moving to an OPEX model is an organizations finance rules. Given that this level of effort is not trivial and will certainly involve C-Level people and probably the board, it’s no wonder that organizations are hesitant to address this conundrum.
Why do we want to overcome the barrier?
Probably one of the biggest reasons to adopt an OPEX model is to change how the Business consumes IT. In an environment without chargeback or an OPEX model, the business is used to “squatting” on as many resources as possible due to the fact that getting new ones often has to wait until the next fiscal year. Under the traditional way of delivering IT, the business wants as much as they can get all of the time.
An example of this was at a large East Coast bank where before any form of OPEX or chargeback, every business unit had every environment backed up every night. This included even test and development systems. Trying to get business units to consume less backup resources was largely unsuccessful. However, once an OPEX chargeback cost was introduced, this behavior changed almost over night. Very quickly when business units saw how much it cost them for just backups, they slashed their use of backups to mostly just production databases. All other things such as development and production environments were expected to be backed up through other means by the developers and production support teams.
Traditionally, IT has tried to restrain the use of resources of the business units, which has been largely unsuccessful. By charging businesses for what they use, the business now controls its own usage to maximize their OPEX value.
Granularity and choice
As part of changing behavior, giving the business the ability to choose what they consume with their OPEX payments, allows them to save money on things they really don’t need. It also allows IT to offer multiple types and levels of service depending on what the business needs. Common examples of this are the silver, gold and platinum levels of service for virtualized workloads, but can also include things such as backups and storage tiers.
Another example of this was at the same large East Coast bank where before choice was in place, performance of production VMs had to be guaranteed at all times no matter what. This led to IT providing their platinum service that had no over commitment and was as a result fairly expensive. However, IT also offered a gold service that had some degree of performance guarantee, but was much cheaper. As a result, over time many business units elected to go with the gold level of service by improving the resiliency of their applications and planning for scale out when needed. This saved them quite a bit of money that then they could use on other projects.
If you combine the granularity and choice available with an OPEX model with automated provisioning, the business can innovate like they haven’t been able to in the past. Between technical restrictions that require new resources to be manually provisioned over the course of several weeks and financial rules that don’t allow much flexibility to change allocations quickly, many projects don’t take flight because they take too long and are too much trouble.
However, when a project can be launched in a matter of hours because automation allows a new environment to be spun up quickly and the OPEX model allows discretion on how funds are applied, many new opportunities are open to the business that weren’t worth it in the past.
Be more efficient
Traditional IT is essentially a form of rationing in how resources are allocated. Users are encouraged to hold on to resources they don’t need because they know they may not be able to get them when they need them. This of course assumes that they can give them back, which in many CAPEX models, they can’t.
By going to a shared resource OPEX model, business units can consume what they need and give back what they don’t.
Avoid shadow IT
One of the biggest drivers for IT moving to an OPEX model with the above advantages is that, like it or not, IT is competing with the open market. Many Business units today are just pulling out a credit card and buying resources directly from hosting and cloud providers because IT isn’t responsive or competitive. As offerings on the Internet continue to improve, shadow IT is likely to increase as a result.
How do we overcome the barrier?
IT as a Business
To be relevant, IT needs to start operating as a business. Traditionally IT has provided resources to business units by essentially “throwing it over the wall”. Unless it breaks there is very little effort spent of the resources. Successful IT departments now define services that they offer to their customers with defined service definitions that describe not only the technology provide, but any SLAs provided along with other non-function requirements that have been included. As part of that, IT can highlight the value added that they provide above what hosting or cloud providers offer. IT has to also start doing customer relationship management to make sure that the right services are being offered, at the right time, and at the right price.
CAPEX and OPEX can co-exist
Many finance departments resist going to an OPEX model because it is presented as either CAPEX or OPEX. In reality this doesn’t have to be. In order for IT to realize the benefits outlined in this article, OPEX only has to exist in the relationship between IT and the business. CAPEX can still exist in the bowels of IT somewhere; it would just need to be converted to OPEX according to rules set up by finance.
A good example of this is how some private clouds operate today. They assume the CAPEX budget of the business unit in return for OPEX credits that the business can use over a predetermined time period.
By answering the questions above regarding moving to an OPEX model, IT departments can become enablers to the business instead of a hindrance.
Richard Benoit is an Operations Architect with the Operations Transformation Services practice and is based in Michigan.