Tag Archives: cloud

What is Softbank’s strategy with its 20 billion dollar acquisition of Sprint?

As I mentioned in a previous post, there are clearly significant macroeconomic leverage points with respect to Softbank’s strategy

TREMENDOUS LEVERAGE:

Yen to dollar exchange rate is shockingly close to a 10-year low

Corporate tax rate in Japan is quite high

Bank of Japan prime lending rate is between 0.0 and 0.1 percent

Japan networks and mobile user behavior is very advanced

But clearly this is not just a financial deal. So what does Sprint represent to Softbank?

Sprint is the Financial Platform.

If you look at the consolidated revenue chart, below, Sprint catapults the combined entity to almost double Softbank’s previous revenue to $80 Billion USD. This is an absolute revenue engine. The scale synergies are mostly illusory as we are talking about cross border operations, but the combined entity will have a high degree of free cash flow and produce significant leverage in the most important mobile markets in the world, Japan and USA. These two markets have the highest ARPU (Average Revenue Per User) by far of any country. China activates more IOS and Android devices per day than the US, but the installed base of these platforms is still bigger in the US.

So SoftBank gets customer growth in a region with similar ARPU to Japan–but since Japan is saturated, the growth has to come from elsewhere.

So Sprint is part of the financial platform, but for what?

The key slide is shown below… despite being one of the biggest telecommunications companies in Japan, almost 2/3 of the value of SoftBank comes from Internet company holdings. Interestingly, some of the operational synergies are unclear, for example the Alibaba Group assets can’t have much impact in either the Japan or US markets operationally.

This provides quite a deep insight into the mind of Masayoshi Son, SoftBank’s dynamic founder.

As such, the balance sheet of Softbank provides a:

Financial platform for an Internet investment portfolio.

An even further clue is the slide below where the SoftBank chairman shows the ecosystem that SoftBank represent… This is the Internet platform that sits atop the “classic telco platform”.

He does not see SoftBank as a “phone company”. He is reinventing the phone company by layers…

Internet company layer -> leverages the cash flow while providing an ecosystem for driving Data ARPU

So where does this go?

MBaaS: The Mobile App Development Layer

The third layer beyond this is the mobile app development layer. For years, the Internet has been building out a set of services that can all be integrated through simple interfaces like REST. This kind of integration provides a “snap together” model of the Internet that creates a true ecosystem from an apparently disparate “primodial soup” of companies as shown above.

However, all of the Internet services in the world don’t translate into success in the era of the App Store.

There’s a missing ingredient that brings the value of these layers –mobile application developer ecosystems. So where are the mobile developers today?

Mobile developers today are aggregating around a new form of platform known as Mobile Backend-as-a-Service (MBaaS). MBaaS is defined by Michael Facemire of Forrester and essentially it provides a natively pluggable SDK into popular mobile OS client platforms such as Android or IOS that enables mobile developers to instantly inject cloud services into their apps.

It’s after all a perfectly good word, and can be repurposed as a pot holder or maybe a tea cozy. What I’d like to have is a word that signifies the following:

An organization that has grown in size to the point where the old tricks don’t work anymore.

* Its organization has shattered into factions
* It’s technology has separated into silos
* Its market has fragmented into niches

The big challenge is how does one maintain the advantages of size and scale but still retain agility?

I think it’s possible:

So how does fragmentation affect the use of cloud?

Well in terms of complex demand, cloud principles are very exciting.

If your market is fragmented, you will be happy to offer a platform of reusable services that can be customized by channel partners or even by end users into thousands of possible use cases. Think iPhone App Store. So for complex demand, the cloud is a good thing.

The challenge for the Enterprise and cloud is the concept of “Complex Supply”. Since both the technology in the Enterprise is already siloed, adding cloud just adds another silo. Legacy Mainframe apps, Web Application Servers, Enterprise Applications, you name it, Cloud just adds yet another technology silo to maintain, integrate, secure and govern. Since large organizations are fragmented into smaller organizations, this problem is compounded when one organization creates a dependency on cloud services without a systematic enabling architecture.

Size matters. People try to apply architectural patterns and software solutions as if they were one-size-fits all.

The Gartner Hype cycle research shows Cloud Computing as being on the peak of expectations… the very top of the hype bubble roller coaster.

Vendors are looking for something to sell, and the consolidation of the data center, reducing operational cost and economy of scale are as convenient of an excuse as anything. There are some fundamental technologies as well that will make a big difference such as Virtualization.

Is computing becoming a utility?

When someone refers to cloud, the etymology of the term should be examined. This term comes from the days of network diagramming, and a cloud was an abstraction for the network. Basically whenever someone didnt feel like drawing all of the network entities, they would just draw a puffy white cloud. In essence the puffy white cloud is shorthand for “don’t worry your pretty little head about this stuff”.

In doing so, one hands over both control and visibility to a third party.

If your cloud provider fails, then you fail. Unless of course your cloud provides non-essential services. Don’t count on it. Large scale failures such as Gmail recently point out some of the flaws in “don’t worry your pretty little head”. You better start worrying your pretty head. Failures aren’t the only problem implicit in the cloud, the lack of transparency can lead to privacy failure. No SLA can ensure privacy, just ask the customers of UBS Bank in Switzerland.

So are there things that a business should not have to worry our heads about? (whether they are pretty or ugly or little or big)

Of course. At the risk of using the most tired analogy in Cloud Computing, we take our electricity and water as a utility. Of course any organization of sufficient size knows that backup generators may be needed. Or even emergency water supplies.

Now reading all this, you may think you know where I’m going with this “Cloud Bubble” thing. After all, vendors are our cloudwashing all of their products and the potential for an economic bubble is pretty large. but I am actually thinking of a different cloud bubble.

An Architectural bubble.

Much like the idea that everything can be viewed from a single point of view did not work for the SOA era, the idea that everything is in the cloud is equally preposterous. This is a legitimate perspective, as I said in my talk at the Burton Group Catalyst conference it is the perspective of Mr. Magoo.

Cloud folks need to understand that while cloud is their entire business, it is not and will not be the entire business of IT.

SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS, Cloud Computing, and all other architectural approaches that depend on “services”.

It’s a good read and certainly a legitimate way of looking at the world. As you know from my blog, I have taken a very evolutionary perspective on SOA and on technologies used in the Enterprise in general. When I say “evolutionary” I do NOT mean incrementalist. Over the course of 2 years, very little changes–but over the course of 10 years things are typically substantially transformed. I subscribe to the model of evolution espoused by the late great Stephen Jay Gould–of Punctuated Equilibrium.

The image of the big SOA dinosaur is certainly a viable image… We could characterize project like these as being very large, slow moving and vulnerable, and part of the large upfront capital expenditure model of IT in the late 1990’s.

The thing is, evolution grows by leaps and bounds–I spoke of this when I wrote about what I learned from my breakfast with Steve Wozniak, which is that evolution is constantly devising new solutions, and doing so under extreme survival pressure. The lungfish crawls out of land to breathe air not because it’s expressing itself creatively, it is because the pond has dried up. The Archaeopterix flies in the air not to experience the trancendental joy of soaring, but to avoid the snapping jaws of predation. These moments in evolutionary history are not without precedent and always of historiographic import as they are subject to revisionism.

What remains is the fundamental evolutionary need–to survive and to compete in business. Those “organisms” who are burdened with the evolutionary legacy of their heterogeneous infrastructure and are unable to come up with agile, dynamic ways to recombine these systems will become extinct. Whether the patterns of management to enable these new adaptation layers are called SOA or something else remains to be seen, but the organizations that fail to transcend their legacy history and complexity of architecture to emerge reformed as the new flying, air breathing, small, furry mammals of the new age (not neccesarily all of the above strategies can be combined in a single creature) will of course be doomed to the tar pits of history.

I believe that use of SOA as a term will certainly decline, but the strategies to address the fundamental problems will have to continue to evolve out of the SOA “stream”. At the same time SOA is dead, SOA is also inevitable–but it may come under a different name. The DNA of large organizations will require interfaces to appropriately segment the what of requirements from the how of implementation, and the design patterns of SOA will be the ones that will realize the long term vision of an Enterprise, Multi-Enterprise, and indeed “cloud” platform. Any term like SOA has to experience the hype cycle and goes through linguistic mystique, implementation, experimentation, and eventually a degree of nomenclature fatigue. SOA had a particularly “big tent” agenda and so a lot of folks latched on to it in the hopes that SOA would be their savior. Frankly I see the same kind of pattern in “cloud”, which is to say that it’s not an easily defined technical term, rather a set of political interested tied to a set of insights and realizations.

For 2009, it’s incumbent upon us as participants in the unfolding of the world’s technology platform that we don’t overreact to the external conditions that are foisted upon us. Fear about the economy should take a back seat to the project of becoming the change we need. The era of knee-jerk emotional reaction can hopefully be relegated to 2008 (or perhaps the first half of 2009) and we can move forward together to both re-envision and rebuild our infrastructure. And to realize the big vision we need each and every person to become the change we need.

I’m indifferent to whether we continue to call it SOA or not, lets just keep building the future together.