Thursday 14 April 2016

CAPEX and OPEX Structure and Cash Flow on an IT Cloud Strategy (II)

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.




Wednesday 6 April 2016

About Exponential Organisation's Book

Just a few days ago, I posted about the fast changing labour market we are all living in, and mentioned some future strategies as to where labour market is, in my opinion, driving to.

Today, after being halfway through the book Exponential Organisations, and though agreeing most of the times with its ideas, I came to a few points I can't agree upon.

The book shares same ideas as I posted last week on the future of the labour market, about changing relationships between employer and employee, and about the need to keep ourselves up to date on technologies and knwoledge, but...

There is at least a sicking point when the book affirms and talks about ever faster obsolescence of labour force. It talks about a ever reducing length of time in which an employee can "be of use" for an organisation. In the past, an employee could be thought of as useful during as long as 30 years, but that period keeps shortening due to the rapid change of technology and the need to keep the pace with it.

I wanted to write about that opnion, since this morning I had a conversation with a young consultant working on my team. We talked about disruptive technologies, how it will, and it is already having an impact on our sector (banking), and we agreed on the issue the book addresses, but with a difference. We shared the idea of a company maintaining valuable people, and keeping them trained as to obtain the best use of their knowledge, acquired thru years of collaboration and education, and we didn't agree with the way the book sees it, being the only responsibility of the employee of keeping him/herself up to date.

If we, employees, are responsible to be constantly searching for training, we see drastic rotation of personnel, resulting in a lack of knowledge and expertise due to the constant renovation of resources.

A company is more than young people being hired, coming in by the herds... Nobody is effective in his post from the first moment. Value is added everyday to the employee, who gets fed with comapny culture, long-term relationships and being able to leverage on those relationships, cultivated during years.

For that reason, though the book may have great ideas about future relationships within organisations, and correctly explains the reasons of growth on disruptive technologies, I feel it falls naive when not seeing deeper in the value that employees, being themselves on staff (not on demand staff as the book wants us all to be) offer to any organisation.

As a summary to my thoughts. Good to know about technology, how it affects big organisations, and how to take advantage of it, but a big BUT on the book's approach to labour force, since it seems lacking reality and underestimating its value offered, thus reducing the human factor to an economic transaction.

Sunday 3 April 2016

Why Agile Methodologies Won't Be the Solution you were Looking For!

It's been quite a long time since "new" approaches to software development have been around.

Though approaches like Agile seem to be the right solution for our software development issues, they are far from delivering an answer, and I'll explain that to you in this post.

Since I started working for the ICT world, I've been working most of the time by the old-fashioned "waterfall approach". According to it, all software should be developed by small incremental steps, as the following image reflects:


Source - Wikipedia

From the moment, the most important consulting firms try to convince us that new and better approaches are available (let's focus on Agile!), they tell us to follow this path:


Source - Wikipedia

Now I have tried and worked with both approaches, I'm perfectly ready to give a deeper idea of what they both mean, their CONS and PROS.

Waterfall -> When working on a classic waterfall model, steps are not thought to be iterative. There is little room to change once the project has started, so it means all requirements and business needs must be well analysed in advance, and those same needs are understood as "fix" over the passing weeks or months the project may take to be delivered.

Agile -> When working on an agile model, its own iteration means there is always room to implement changes (user may raise his hand anytime and ask for a change without much problem).

The truth is:

Waterfall -> Based on a nice and deep understanding of project scope. Based on agreement of all parties involved in the project. Based on a given budget and little room for change during the project development.

Agile -> Based on subtle understanding of project scope. Although there is agreement, changes may get in as soon as any of the parties want it... as long as there is budget left... and here it is when from my point of view, problems arise... and let me get into that.

My own experience got me believing the agile approach would be the answer to all the problems I had already endured when working on a classical approach to software development.

First iterations, and first deliveries of software (they are called "sprints" in the agile approach) were poor on expectations. You get thinking that each delivery will offer a good and usable chunk of software, and it can be as an atomic unit of it as useless.

As in any software project, deliverables have always a good portion of criticism, of improvements, of misunderstandings, and if in a classis development those problems arise close to the end of the cycle (normally at the user acceptance test stage), on an agile approach those disagreements arise every two weeks (depending on the number of sprints you define).

The well-known discussion about what is a mistake the development team did or what is a change the user wants, is this way repeated periodically (due to the iterative method the agile approach follows). Statistically, the more discussions we have, the more chances we have to lose the battle, and therefore be asked for more money to implement those "changes" the user needs in order for the software to be compliant with his requirements.

This way, project managers see how their assigned budget goes down the sink in a blink of an eye, resulting in the best of the cases, in very few deliverables completed, though to be true, brilliantly executed since all budget and care has been put on them.

As a conclusion, and trying not to let agile approaches down, do please think twice before throwing your team onto an agile development cycle. At least, if scope is close to being well defined and if the customer is not bound to keep changing requirements, do not go agile, stay by the waterfall model.

If those two simple issues are not clear, them, go agile, but always taking into account point mentioned above. Budget and requirements come me put at risk unnecesarily, so, be cold-minded, and do not follow what seems to be fashionable now, unless you do a clear study of your needs.

Should you have any mention or questions, do not hesitate to address them to: asalbares[at]gmail.com and I will be willing to help you out!



Friday 1 April 2016

A Fast Changing Labour Market (Ideas for the 21st Century)

We woke up today to new about another massive layoff in one of the biggest bank in Europe (Banco Santander).

That piece of news got me to think about what the 21st Centurty labour market will look like and how it could affect my children and future generations.

I just came to the following conclusions I would love to develop in the short term:

- Current labour market model still based on post-WWII growth rates -> past growth would assure long-life jobs

- Technology-powered jobs, meaning employees have to offer a higher education and specialisation, though educational systems are a way too far to be updated to current business needs

- Monetary exchanges are more and more based on "abstract" exchanges. No physical transaction is accomplished, no physical money travels on the way -> end of physical money transactions, no doubt driving us towards a no money exchange economy (exchange of value added services)

- Future exchanges of value will be based on knowledge and expertise of labour force and not on monetary exchange -> what can you offer to me and what can I offer to you? No Money Exchange!

- World driving towards a more democratic economy -> your monetary income (current measure of a person "value") will depend on truly what you give to society and not based on what a given employer thinks you are worth

The way we are currently changing the way we shop, we do business, we interact with each other and the way we make our money move, is a clear pattern showing we move towards a no money world and to a more democratic value exchange.

Unemployment rate, number of physical monetary transactions, stats about shopping online versus physical and GDP growth all point to those changes on the way.

If you got interested in finding out more about stats:

Stats on Online Shopping US

Stats on Online Shopping EU