Tune Into The Cloud

The current frontrunner – Software Defined Networking (SDN) – might very well already be the most hyped term of 2013. All network technology providers are busy either building or acquiring SDN capabilities but the largest acquisition to date (for more than one billion dollars) was done by a virtualization platform provider. Meanwhile most network providers are looking to leverage SDN to increase the agility and reduce the cost of the services they provide.

An important reason for the interest in SDN is the size of the market it is promising to disrupt. The total revenue for Network and Communication services makes up a large part total worldwide IT spending. Of the total 3.7 trillion IT spending in 2013 46 percent will be spent on Telecom Services (next to 8 percent on software, 22 percent on hardware and 25 percent on IT Services). Any development that such a large proportion of the total cost influences can count on great interest, also from the telecom industry itself. At the SDN World Congress in Darmstadt no less than 13 of the largest telecommunications companies announced a joint initiative to promote ‘Network Function Virtualization. This initiative encourages network technology providers to enable their network functions to run on (clouds of) industry standard servers instead of on proprietary hardware appliances.

The main advantage of a software defined network – just like any other kind of software defined infrastructure construct – is that it no longer consists of dedicated and proprietary boxes with names like: firewall, load balancer, router, etc. If an organization tomorrow suddenly two times more firewalls than load balancers needs (or vice versa), they can just provision other software on their existing hardware. In addition everything that is controlled by software can be much easier automated than something that is based on hardware. And this offers benefits not just to providers but also to end users as it can reduce the time needed to reconfigure en network to changing needs from several days or weeks to a few hours, or even shorter. And as a result the network can become as dynamic a cloud resource as compute and storage already were.

But let’s not forget that for many organizations the transition to ‘as a Service’ and “on demand” began in the network area. Back in the 80-ties companies started to give up their own in-house controlled and managed wide area networks in exchange for the use of shared packet-switched networks, often based of X.25 and commonly called the “public data network”. Maybe something to remember for those currently afraid of “public clouds”?

PS Gartner press release : Software Defined Networking Creates a New Approach to Delivering Business Agility

In that era the term BPR also became popular. BPR stood for Business Process Re-engineering (see for example Hammer, M. and Champy, J. A.: (1993) Reengineering the Corporation: A Manifesto for Business Revolution), a movement that in my perspective*really gained steam from the realization that throwing new technology (ERP) at existing processes, only offered limited improvement potential. As Business Process Re-engineering often resulted in massive redundancies and layoffs, BPR got kind of a bad rap, especially among employees and unions (remember those?).

Today the term Business Process Redesign is a more socially acceptable reincarnation, and even though that could fly under the same acronym (eg. BPR II), people seem to prefer to call it by its full name.Nowadays all the buzz is around cloud. And also here people are finding that just throwing this new idea at existing processes is not bringing the benefits expected, not to mention that the cost of absorbing it into our existing ways of working is very high (remember how much we spend on trying to force fit ERP packages into our existing processes by modifying them beyond recognition, only to reimplement these packages a few years and a few releases later in a more off the shelf manner?).

And increasingly the topic of adapting processes to the cloud is becoming popular. Last month my note “Cloud Solution Providers Ignore Customer Processes at Their own Peril” published, and this month KPMG published a study called “the cloud takes shape“. In that study KPMG uses the term Business Process Redesign and states “One of the most important lessons uncovered by this year’s research is that business process redesign must occur in tandem with cloud adoption if organizations hope to achieve the full potential of their cloud investments.” In my note I describe the need to challenge the status quo on processes using the term Cloud Process Re-engineering  (the cloud generation is likely to have a less emotional response to re-engineering, while some of its disruptiveness still rings through).

Some IT departments I speak to seem to think of cloud computing largely as a way to move their applications to the cloud. But if an enterprise organization with thousands of applications running in their datacenter, moves these apps to the cloud, they will still have thousands of apps. And more importantly those apps will do the same they did before, just running somewhere else (so you might ask “why bother?” as the savings on hardware, housing and electricity are small compared to the overall cost and today’s management is much more interested in new (revenue) possibilities and agility than in efficiencies that in the end form a mere rounding error in the companies overall bottom line). If organizations however look at each process and decide how the cloud can optimally support or even completely eliminate that process (for example through Business Process as a Service (BPaaS) or by participating in multienterprise applications) the potential impact can become much more significant. 

The idea of optimizing processes to new realities – for example through Business Process Management (BPM) – is not new and covered broadly in Gartner’s  existing body of research. Cloud practioners – both consumers and providers of cloud services – should take an interest in this softer, more human, side of the cloud.*

PS. Whether CPR will turn out to become the acronym that replaces BPR is debatable, also as it seems to be already firmly taken by the medical profession (for both the life saving CardioPulmonary Resuscitation and for Computer-based Patient Records).

As an App user* I am increasingly amazed, affected and annoyed by what in my view can only be described as turf wars between various technology providers. Increasingly cooperation – that originated by a desire to have a quick time to market – is being replaced by outright competition driven by a desire to own the full stack. Some recent examples:

Even though it defines three key actions – around Standards, Terms and Public Sector taking a lead role – most described actions consist of softer items such as “promoting trust by coordinating with stakeholders”, “identifying best practices”, ”promoting partnerships” and “investigating how to make use of other available instruments”. Now of course European cloud computing can benefit from funding reserved for other EU initiatives such as the Connecting Europe Facility and from side initiatives such as the “Opinion on Cloud Computing” published by the Article 29 working party that gives privacy-related contracting guidance, but in general the recent published plan seems to be more about what could and should be, than about what is or will be.

Meanwhile, both regular and social media seem to be increasingly negative regarding the progress that Europe is making. With the North American continent clearly being the biggest cloud geo and ASIAPAC – also thanks to its many emerging economies – claiming the position of fastest growing cloud geo, it only leaves less desirable labels – such as slowest or most fragmented – for describing the state of cloud activities in Europe.

Continuing to look at why things are harder and slower in Europe will just further reinforce negative sentiments, better to focus on European examples that are showing success. And in “Switch: How to Change Things When Change Is Hard” the brothers Dan and Chip Heath offer an engaging recipe for doing just that. In their book they describe how by identifying “Bright Spots” (small pockets of positive exceptions) potential future success scenarios can be discovered. Next, they encourage promoting very specific actions instead of giving broad directions. For example: Instead of asking people to eat healthier (too vague, too hard), they suggest healthcare activists promote a specific action such as “buying skimmed instead of full fat milk” (simpler, easier, more actionable, more effective).

So in Europe, instead of pushing cloud as a concept (too vague, too hard), why not focus on identifying a few very specific and very simple scenarios including their specific benefits. Next Europe can concentrate on removing any (legal, fiscal, economic, cultural) barriers to these specific scenarios and promote these few clearly and broadly. And in doing so best to follow the Heath brothers advice to promote this both on a rational and on an emotional level (or as the brothers put it eloquently: both “Direct the Rider and Motivate the Elephant” ).

PS What potential European cloud Bright Spots would you suggest (using the comment field on this blog)?

In fact, when asked: who do you expect to provision your services to the cloud?; who will monitor your services’ performance and availability? and; who do you expect to take action if something goes wrong?, a majority of the companies asked look to be somewhat surprised by the question, as they simply assumed that their service provider would do so.

This is a bit like going to a supermarket (a typical self-service facility), pointing to the ingredients you like and expecting the cashier to clean, cook and serve them for you. The name we generally use for such a service however is “restaurant” and it comes with significant different expectations and pricing, as demonstrated by the price of a bottle of the wine in a restaurant versus that same bottle at a supermarket (which is one reason restaurants prefer to buy from exclusive wine merchants and not to put bottles or their wine list that are available in retail).

The supermarket versus restaurant analogy may sound like a silly comparison, but is useful to further illustrate the difference between cloud computing and more traditional IT services. It is not just that the product is vastly different: a raw steak on styroform and a brown bag with vegetables versus a prepared steak – cooked to our liking – on a nice plate, brought to our table with a smile.

The much more telling difference lies in what we would reasonable expect to happen if something goes wrong. For example: if a supermarket burns down, we would expect the supermarket to – first and foremost – concentrate on building a new facility so it can restore its service. We would not expect the supermarket to call us and help us plan tonight’s meal or offer any alternatives on an individual basis. Likewise expect cloud providers to focus primarily on getting their cloud back up in case of problems.

However, if a restaurant burns down we would find it reasonable they would call people that have made reservations. And if we booked a wedding there for next weekend, we would expect the restaurant to help us find a new facility, help us agree the new menu with the new chef and reimburse any additional cost (unless we change the menu from steak to lobster).

Self-service in most cases means the provider is not aware of what the individual customer is using its product or service for. As a result it is not getting involved with individual outcomes (as it simply does not know those). This separation is also not uncommon in self-service infrastructure and even used as line of defense in case that infrastructure turned out to be used in “less than legal” ways.

Hybrids

Self-service supermarket have a lot of benefits that restaurant customers may also be interested in: choice, speed, price, no need to make a reservation, ample parking, to name just a few. So is there a way to eat our cake and have it to?

One option are self-service restaurants, like the ones you may find along most European highways. Service tends to be fast, no need to make a reservation and if the restaurant happens to be full, we just drive to the next one. Here self-service is the overriding attribute. It’s a supermarket with cooked foods, in most cases without the price advantage. And we probably would not plan having something important, like a wedding (or another mission critical event) there.

An option closer to the desired experience may be eating at a full service restaurant that sources from a supermarket. Such a restaurant could source it ingredients on demand (by simply walking across the street), it could offer enormous choice and would in most cases not run out of ingredients. It would however likely have to pay retail prices for these ingredients (supermarkets margins are thin and they do not have a lot of room for additional discounts, especially if you don’t buy in bulk). But retail prices might conceivably still be lower than what a restaurant would normally pay from it traditional channels (like the exclusive wine merchant).

Pricing

As the prices of the underlying ingredients are now transparent, end-user pricing becomes an issue. Do we pay for an all in price a cooked meal (including seat and cutlery) or do we pay separate for cooking, serving and use of the facilities. In North America paying separate for service is still customary, and although not too long ago – in the southern parts of Europe – you would be charged separately for the couvert and the service, European restaurants now largely evolved to all-in-pricing. The drawback of such fully inclusive prices is that people compare it to the publicly known ingredient prices (a problem not unfamiliar to many an IT manages, who tried to explain the difference between the TCO based price of the fully managed PC their department offered and the price of that same PC in the local mall or – even more pronounced – from an on-line retailer).

Resilience

But -just like cloud computing is not all about cost – eating out is not just about price, it is also about agility, productivity and resilience. By not having to spend time cooking, people can have more quality time or -more likely – spend more time at work: finishing that last assignment, winning that additional customer. This does however mean we are now dependent on the restaurant for a pretty essential part of our life: eating. So what happens if our restaurant – that now sources from a third party self-service supermarket- runs into problems?

As we are not buying this as self-service, we would expect the restaurant to care about the outcome (us being hungry or fed) and take DR measures in case something goes wrong. But in how far is it fair to expect that the restaurant can reasonably do this, as they are now dependent on the supermarket? Can the restaurant stay open if the supermarket closes for a holiday or if I order something after supermarket closing hours. Or is it relegated to being a middle man no longer able to control its own SLAs.

Having the supermarket and the restaurant under the same management (meaning the restaurant guys have keys to the supermarkets’ back door) can help. But only if the supermarket manager allows his restaurant colleagues to interfere in his operations and impact his targets and quality (something not very common in larger organizations).

Smart restaurant would likely source from two or more supermarkets – preferably from separate chains, located in different streets. So it will be able to serve its customers even if one of them closes or burns down. And maybe that should also be the conclusion if you are looking (even though the definition would argue there is no such thing) for a non self-service cloud. In other words if we want to eat your cloud and have it too.

Disclosure: Before getting caught up in IT & Clouds, the author worked as a manager at the largest restaurant in the Netherlands, which indeed did burn down during that period but managed to restore it services within a week and keep it running throughout the reconstruction.

This cloud year we saw quit a lot of change – also from existing mega vendors entering the cloud market – but did it match 7 years of progress in traditional IT (taking us roughly from SOA till today)? And do we really expect the next three years to bring as much change as we saw since the days of client-server or the next seven years to be the equivalent of the journey from the days of the mainframe to today?

Now Einstein pointed out that speed is relative to the point of view of the beholder. In that spirit one of my former employers handed out gold watches after 10 years, instead of after the customary 20 years, because he felt “It all moves a little faster here”. I never made the 10 year mark there (not would that have mattered as they changed the policy in my seventh year), but I did make my first A-year last month (A as in Analyst). No watch here either, just some musings on time.

Talking about musings on time, several dog years (and a few employers) earlier, I wrote a small time perspective on the ERP market, called “the Best Years” (named after the little rural town called Best, where we had kept office till then). I did not keep a copy of that internal note but the main theme was that in just a few years the way customers procured ERP had completely changed. From vendors leading the sales process, often doing custom demoes that wowed prospects with fancy features (features that BTW seldom got to be implemented post sale), to cookie cutter selection cycles where third party consultants fed vendor profiles and offerings through standardized spreadsheets generating normalized scores. Vendor offerings became more and more comparable and our RFP responses were demoted to becoming column fodder for the Lotus123 sheet (Yes, was some time ago, when there was still a market and not an oligopoly).

Question is whether the cloud market – or more specifically the Infrastructure as a Service market – has started on a comparable journey and at what speed. At Gartner we are currently working in full swing on the next iteration of the Cloud IaaS Magic Quadrant giving us an upfront view of convergence and comparability (or even compatibility) of various offerings. For those of you interested in the MQ process, I suggest reading the recent blogs of my colleague Lydia Leong, who shares some useful background and pointers.

At the risk of simultaneously offending two groups (people who believe in wedding vows XOR people with trust in SLA’s) lets compare the two a bit further. In both cases (you would hope) participants start with the best intentions. And although few will consult the agreed paperwork before making daily operational decisions, you would expect they follow policies in line with the original intentions  (for example refrain from …fill in the blanks … and/or from buying old, refurbished hardware).  But once we have a breach, hitting the partner over the head with a copy of the agreement only gives some emotional reprieve.

While discussing SLAs with a colleague we -only partly in jest – concluded that most SLAs are not worth the paper they are printed on, and consequently, on-line SLAs – which are generally not printed – are worth even less.   But – you may ask – is that not what penalty clauses on SLA breaches are for? Strangely enough, not many people are using penalty clauses in their wedding vows. Vows are about trust, and having a financial or other compensation clauses seems to contradict this trust. Of course Ronald Reagan popularized the idea of  “Trust but Verify” but that was in the context of the cold war, and if your partnering situation is comparable to that, no amount of SLAs or vows will help you.

Not to mention that verifying anything in the cloud is still severely hampered by lack of provider transparency. In many cases success is more about monitoring input and behavior than about monitoring output. Just like a good sales manager should not routinely ask his reps “How much have you sold today!”, but rather “How many new prospects did you call, how many demo’s did you agree and how many proposals did you send?” Likewise,  SLAs (and vows) are best monitored by checking policies and behavior upfront.  That is also the only way to do some verification of how realistic the given SLAs are.  We have all seen the calculation that five components with 95% availability give an overall availability of barely 78% (95%⁵ or (1-5%)⁵), however having a spare for each of these five, increases availability to 98.7% ( (1-(5%)²)⁵ ) , which by the way is still about 7 days of unplanned, unexpected and undesired downtime per year.

If a provider does not offer the transparency needed to verify the numbers (the input), you may conclude that all you can ask for are penalties. But such penalties are known to invite calculative behavior, with partners evaluating – in a rational but not very partner-like way: “What is more expensive? Paying the penalty of addressing the issue?” Which quickly leeds to aforementioned cold war feelings.

PS As I am writing this blog, the Dutch papers are filled with in-depth analysis of  –no, not of a cloud outage – but of the latest soccer celebrity divorce.  Somehow this seems to be more newsworthy than the EU cup predicament of the Dutch Soccer team, which has somehow managed to miss all its SLAs (to the large frustration of its customers/fans). And just like with today’s cloud outages, the debate about what went wrong (and who is to blame) happens mainly through public interviews, blogs and articles.  It seems that when something goes really wrong, transparency quickly becomes the norm again.

Disclaimer: blogs are not research, they are not peer reviewed (except maybe through heated comments below) and yes, I agree some (but not all) SLAs and/or vows may make (some) sense.