Thursday, July 27, 2017

Cloud vs. clouds: A CIO’s conundrum

Beware of cloud "stickiness." Plan for redundancy. Clouds do fail!

Originally published on SETHspeak , July 13, 2017
There was a tear in the fabric of the cloud universe on February 28, 2017 when Amazon Web Services had a significant outage.
It highlighted what some described as a “critical lack of redundancy across the internet.” The outage was a wake-up call for many to build in redundancy (both multi-region as well as multi-provider) in their cloud strategy.

Can I jump from cloud to cloud?

So from cloud the conversation has moved to clouds.
However, good tools with capabilities that allow seamless dynamic interoperability between public cloud providers especially in the PaaS and SaaS space are hard to find.
Public cloud providers' idea of redundancy is to provide geo-redundant storage, replicating data to a secondary region that is hundreds of miles away from the primary region. They talk about seamlessly migrating from one to another in quick easy steps but are silent about dynamic real-time interoperability.

Dynamic real-time interoperability (DRTI – Voila! A new acronym is born)

What I mean is that, ideally, these tools should allow dynamic switching between public cloud providers based on rates, availability, etc.
Customers are getting wary about putting all their eggs in one basket. They would also like to leverage differential rate structures across public cloud providers to their advantage.
What one really wants: A cloud load balancer/scheduler that switches the processing to whichever cloud offers the best mix (rate, availability, processing speed, etc., at that point of time). Cannot say there is one quite there yet.
Interestingly a patent assigned to Red Hat Inc., "Methods and systems for load balancing in cloud-based networks," has been out there for quite some time. But does not seem like it has been effectively commercialized yet. 

Why is my cloud so “sticky”?

This brings me to the other pet peeve about the existing public cloud providers: “stickiness.”
The economic model presented by leading public cloud providers highlights a “consumption-based infrastructure,” which moves the cost model from CapEx-centric to OpEx-centric, and aligns costs directly to usage (see "Pay-as-you-go IT: CFO’s dream, CIO’s nightmare/opportunity?").
However, just like the classic software/hardware vendors, public cloud providers have tried to create a “stickiness” using technology or commercial barriers to make seamless interoperability across multiple providers somewhat of a challenge. (Oh, AWS Cloud is the AWS Cloud and Azure Cloud is the Azure Cloud, and never the twain shall meet – with apologies to Rudyard Kipling.)
In SaaS, vendors are perhaps getting too “sticky,” like to own the application, platform, infrastructure, cloud – the whole shebang! 
That works fine with me when I am the vendor for others, but being at the receiving end of the stickiness is scary.
Perhaps, it could be reduced a bit for some applications where other vendors are pulled for the underlying platform or infrastructure (Oracle SaaS or Salesforce on an AWS cloud). But all applications vendor claim their applications work best on their own cloud!
I do not blame them for that. Any vendor in any line of business would like to make sure the customer stays with them and goes no place else.

The future is cloudy!

If I had access to the ear of Jeff Bezos or Satya Nadella or Sundar Pichai or Larry Ellison, this is what I would whisper: Build the cloud “switch.”
That means a tool/appliance/service that allows storage capacity or processing loads to move from cloud to cloud or cloud provider to cloud provider based on cost and demand.
Create a true “cloud grid” like the electricity grid (where distribution companies can draw power from whichever generating company based on rates and availability).
What next: a “computing exchange” where processing and storage capabilities are traded and futures are locked in like any other commodity (electricity, jet fuel, etc.). Now, I may be getting ahead of myself.

Don’t forget the R word

Well, in the short term:
  • Think redundancy
  • Plan redundancy
  • Execute redundancy
You are only as good as your plan B.
Originally published on SETHspeak ,

Monday, July 10, 2017

The CIO and the driverless car: Are you ready for the Transportation as a Service (TaaS) revolution?

                                Credit: Volkswagen
Originally published on
Well, not many of us have seen a driverless car yet (The closest I have come to one is the Tesla with its many autonomous driving features). But it could very well be a “platform disrupter,” which throws us off track if we don’t prepare for it.
In my comments published in the Harvard Business Review I had opined that failure to recognize platform disrupters (and the self-driving car is one) can be very detrimental to corporate health and existence. ( focusing on the downstream disrupters and failing to recognize these Platform Disrupters, companies are missing the woods for the trees.)

Are you kidding?

That’s what some of you may ask. 
How can an autonomous car or driverless car or self-driving car or whatchamacallit impact my company and above all disrupt IT?
Combine facets of the “sharing economy” with it (think Uber, Lyft) and you have a veritable TaaS (Transportation as a Service). And that can be a game changer.
For starters, the study: Rethinking Transportation 2020–2030 (from RethinkX, an independent think tank that analyzes and forecasts the speed and scale of technology-driven disruption and its implications across society) highlights the impact Transportation as a Service (TaaS) is likely to have on entertainment, work and other opportunities: 
Americans spend around 140 billion hours in cars every year, a number that will increase by 2030. The TaaS disruption will free up time otherwise spent driving to engage in other activities: working, studying, leisure options and sleeping. 
This will act as an increase in productivity and provide a boost to GDP (see Part 3.5). From the TaaS provider perspective, additional services could be offered, such as entertainment (movies, virtual reality),  work services (offices on wheels)  and food and beverage (Starbucks Coffee on wheels). 
Providers could act as distributors, earning revenues via a range of business models, including a percentage of sales generated on their platform (as in the Amazon and Apple stores), advertising revenues from onboard entertainment (similar to the Facebook and Google AdWords models), or the as-yet undeveloped business innovations that are likely to arise from the TaaS disruption. 
  • Car being so comfortable that people spend more time in it rather than less
  • Think of it as workplace of the future: work in there, pay bills etc.
  • Touch screens all around (“immersive”); 
This space is evolving very fast. Ford has appointed a new CEO who had just recently been brought in to head up its “smart mobility” operations. An indication that the big players are acknowledging the direction the industry is heading. Cars are no longer transportation but part of a larger “smart mobility” initiative.
It is this “offices on wheels”/“smart mobility” premise which should get companies thinking. 
Our cars of the future may be evolving as an extension of the workplace/office.
Do all the auto manufacturers see that yet — perhaps not, they suspect it, but do not seem to be sure how to factor it into their designs. That’s where other players could step up, take the lead and create/define a market.
All TaaS cars may not be offices but in big cities customers in the future perhaps could request a ride in a vehicle equipped with office capabilities. The jury may still be out on Uber’s Pittsburgh driverless car experiment, but it does show the shape of things to come.

What does this mean for the CIO?

As employees start treating the car as extension of their offices IT infrastructure teams would need to figure out best ways of implementing “telepresence” in cars assuring seamless connectivity. The autonomous car could also very well be the epitome of IoT/Edge Computing.
There would be major implications for information security as well. The driverless car with its ubiquitous connectivity with the external environment and other vehicles on the road multiplies manifold the threat vectors compared to the current physically static office environment.
The question you may need to answer in the near future: is your business ready for Transportation as a Service? And what can IT do to facilitate that?
A few thoughts:

For the business leaders, especially if you are in a business sector even remotely involved with the “office”:

  1. Preliminary assessment of demand potential for office capabilities in driverless vehicles.
  2. Engage with vehicle manufacturers – Ford, Toyota, Tesla, Navistar, etc.; Driverless capability service providers – Uber, Lyft, Google etc.; Automobile accessory companies – Harmon-Kardon, Pioneer etc.To understand their vision of the “office package” for the driverless vehicle of the future.
  3. To “sell” them the need to include office capability as part of their “office package” offerings

For the CIO

  1. Engage with business stakeholders to ascertain where the “driverless car” or TaaS fits in their business plans/vision for the future and associated timelines thereof.
  2. Ascertain the requirements and gaps from an infrastructure and security perspective for extending the office to the car.
Get ready for the ride. It will be arriving at your doorsteps soon.
Originally published on

Tuesday, June 20, 2017

5 Leadership Lessons from the Indian Meltdown (ICC Champions Trophy Final- Cricket)

ICC Champions Trophy Final June 18, 2017; India lose by 180 runs

Pakistan 338-4 (50 overs) ; India 158 (30.3 overs)

1. The Game Is Not Over Till It Is Over: Play till the End.

While the Pakistani team even after building a clear path to victory continued to play with the same vigor; the Indians had essentially given up after their first few wickets fell in quick succession. Only one player (Hardik Pandya) took the fight to the other camp but he too was let down by his own team-mate in a disastrous run-out.
Turnarounds are possible in any game.......and in business and life.
For a successful leader the zeal to recover from losses, regroup and fight till the end with an indomitable spirit needs to exist at all times.

2. All for One, One for All: No First Among Equals.

Over-hyping the contributions of some players like Virat Kohli and M.S. Dhoni made the team mentally over-dependent on them resulting in a situation where the team was psychologically undermined when these players were quickly knocked out of the game.
Also, players need to be willing to take one for the team and sacrifice their own personal agenda in case another player is better suited to take the cause forward (Seeing the way Hardik was playing; Jadeja should have been willing to sacrifice his own wicket as the run-out fiasco played out)
A successful leader needs to acknowledge and recognize key contributors but not at the cost of undermining the efficiency and efficacy of the entire team. No one is indispensable and the game needs to go on even if some key players get knocked out early.

3. Manage Expectations.

The Indian Team had tried to temper the unrealistic expectations that had been created for them by the media. However, the weight of the nation’s over-hyped expectations was like an albatross around the team-member’s necks. The Pakistan team despite the expectations from their own nation managed to create an under dog image. As a result every win of the Pakistan team was a bonus for the fans (esp. after a string of early losses, including one to India).
A successful leader needs to manage the expectations of the stakeholders, ground them in reality and also shield the team from the unreasonableness.

4. Be Flexible, Creative and Responsive: You are only as good as your Plan B.

The Indian team failed to respond flexibly and creatively to the Pakistani onslaught. They seemed to be caught in a warped game-plan and were not able to modify it once they saw it unraveling.
Successful leaders war-game different scenarios and the options to switch between them. Even if the real life scenario may turn out to be different, the practiced ability to switch between scenarios will come in handy. Very rarely will a one trick pony come out on top.

5. Stay Calm, Stay Focused and Execute.

Unfortunately the game played out to the stereotypical “Fail Under Pressure Indian Team” vs. “Go for the Kill Pakistani Team”.
I am not sure wearing ones emotions on one’s sleeves and creating hype ahead of the event is the best approach for high stress scenarios. There is something to be said about staying focused and keeping the emotions bottled up till after the game when they can be all let out.
Successful leaders have the ability to channelize their teams emotions – anger, sadness, joy towards achieving the goal at hand rather than wasting that energy on unproductive displays.

Friday, June 2, 2017

Healthcare Sector and the API Economy

Harvard Business Review talks about the The Untapped Potential of Health Care APIs
Leaders of most internet-based businesses have realized the critical importance of using open application programming interfaces (APIs) to expand the reach of their organizations. If the health care industry followed suit, the impact on the quality and cost of care, the patient’s experience, and innovation could be enormous.
IBM has outlined 5 entry points to an API Economy:
  • Creating value by offering APIs that others want
  • Using APIs to help your developers innovate freely
  • Supporting your mobile development team with APIs
  • Making APIs the common language in a hybrid world
  • Linking devices to data on the Internet of Things (IoT)
The first 3 ones seem to be most relevant for any corporation.
A next step could be an exercise to figure out what data resources a Corporation may have which there may be value in exposing to others via APIs.
Several healthcare related open APIs are now accessible via API markeplaces.
A good opportunity for some healthcare player may be moving a step up the value chain and creating a Healthcare API Management Portal/System . Lots of players – insurance companies, hospitals etc. would be providing APIs. APIs in many sectors are “open” APIs but in the healthcare sector there are several privacy related constraints so there is an opportunity for players to create a Healthcare API Management Portal/System which:
  • Helps set up and define rules related to who can access what and how much. A single point clearing house for validating requester credentials and matching it up with what access it should get him/her to the various discrete APIs accessed via the portal. Obviates the need to provide credentials multiple times.
  • Facilitates different sets of rules for different groups of people based on their role (caregiver vs. patient vs. provider etc.)
  • Monitor traffic for usage and abnormal spikes.
  • Provides analytics on how data is being used, for what and by whom.
I am not sure if any player has offered such a System yet. If not, then a good opportunity for someone to get in and get some early traction.
Users will like to have this portal/system because they will have a one-stop shop to access all healthcare related APIs presented to him in a curated fashion on a self-serve platform which s/he can customize/personalize. No need to provide security credentials multiple times.
Companies will like to use such a portal to list their APIs because it makes them easily available to a broader audience without dealing with headache of security validations etc. Reporting available to them as a package.
The business model can either be subscription based from users or could be free for users but a fees from institutional participants. The portal could be accessible as a customized plug-in on institutional websites too.
I may be getting ahead of myself though. Or maybe, not.

Search Google


Site Meter