Months ago I published a post about the differences on the
CAPEX and
OPEX structure between an IT model thought to be located at our own premises versus one thought to be located off our own premises.
This time I want to go deeper into that model, make some reflexions public and sum it all up on important conclusions on why going into the cloud is the right strategy and path to follow.
ON PREMISES APPROACH
CAPEX structure and cash-flow over different periods of time follow the patterns show on graphic below, meaning:
Initial investment is very difficult to estimate, since at this early stage:
- We can't barely know about our own business growth in the future and its needs for technology.
- We are unable to estimate future technological trends and if they'll make of our investment an obsolete one in the short term.
These difficulties, in a world of rapid disruption, results in one of the following two failures, either making an initial investment well above our needs or well below our needs, thus resulting in unexpected and unwanted costs.
According to graphic shown above, our initial investment will tend to be really high (we use to overstimate our needs!), and since technology trends, disruptive strategies in IT and an ever faster changing market will turn our investment quickly obsolete, further investments will be needed on the way.
OPEX structure and cash-flow over different periods of time follow the patterns show on graphic below, meaning:
- Cost could be as low as we want (remember OPEX costs are flexible on its own concept). If we hire less security measures, etc., OPEX will no doubt be lower than if we hire state-of-the-art "measures".
- Nevertheless, OPEX costs on an "on-premise" strategy are not flexible enough, since they are closey bound to our hardware, software or IT goods and equipments.
For that reason, graphic above shows an OPEX structure and cash-flow where variable costs get higher and higher as our technologies become obsolete (bigger need to adat, to evolve and fix our system). Since we try to keep up the pace of the market and our own competitors, cost will go up, only coming to a lower level as soon as a new investment is made.
OFF PREMISES APPROACH
CAPEX structure and cash-flow over different periods of time follow the patterns show on graphic below, meaning in this case:
Initial investment is very easy to estimate:
- It will be for sure the best fit for our current requirements and business needs. Over or under estimation of initial investment is therefore avoided.
- CAPEX structure in this scenario es a very small and insignificant variable. Its weight in our cost structure is minimum following this approach.
As the graphic above shows, initial investment is minimu, and slightly higher at first stages, but just keeping constant throughout time.
OPEX structure and cash-flow over different periods of time follow the patterns show on graphic below, meaning in this off-premises approach:
- Maximum flexibility is achieved. Most of our cost structure corresponds to variable costs, thus being dead easy to adapt them and out IT system dimension to our real business needs (remember these needs may change frequently in such a disruptuve environment we are living in!)
- If business growth gets important (as it should if your business is to survive!), our OPEX costs may increase by a slight step, always accompanying the evolution of our business growth.
- In the worst-case-scenario, if our business just shuts down due to its lack of profitability, our OPEX costs would just be reduced down to zero at lightspeed.
- This approach is similar to a "pay-as-you-go" scheme, you are just been billed for what you use.
- Going off-premises allows you to get state-of-the-art technology, you are just riding the last wave, may we say we are on the groove?
CONCLUSIONS
In a world of disruptive technologies, rapid change and uncertainty, we must be prepared for the unexpected. We must get ready to fail, and to fail as much and as fast as we can, taking risks and learning quickly).
Getting our IT systems up to the cloud (be it on a SaaS, IaaS or PaaS scheme), will allow us just do what I mentioned on paragraph above.
Should any doubts arise, do not hesitate to contact me at asalbares[at]gmail.com and I'll try to do my best to help you solve your issues and give you further detail on the strategy to follow.