Apollo 13 (or app-ollo 13) and apps – the connected universe. Part 2 of a 2-part articlePosted: December 3, 2011
Part 1 of this article made some thought-provoking comparisons about the challenges that the Apollo 13 astronauts faced over 40 years ago, and the challenges faced by today’s mobile app companies. Check it out here.
This Part 2 considers how the old days, where an app would simply be submitted to a wireless carrier for them to sell on their deck, has been completely turned on its head because of;
- the large number of players in the app value chain
- the vast array of places to distribute apps
- the wide range of business models
I guess the analogy is that back in the days of Apollo 13, the only target was the moon. NASA’s entire focus was to get to the moon (replace “moon” for “carrier app store” and you will get the idea). These days we know far more about the rest of the universe, we have sent craft to (or very near to) Mars, Jupiter, Saturn, Uranus and Neptune. We are still learning. This diagram will help to illustrate that the app economy is now an entire universe with so many paths of discovery taking place. (Click the pic to enlarge).
In the past, a developer would build an app, submit it to a handful of carriers, hope they would put it on their decks, the user would be indentified and billed by his mobile number to his carrier bill, and the app would typically be simple or standalone. The universe has got much more complex since then. Here’s why (we will use an example of an Intuit QuickBooks mobile user who is looking for a mobile accounting app to illustrate the point);
- the user may discover the app on something like Facebook (as an example), perhaps via a friend’s comment about a great business app, or Intuit’s Facebook page
- when he clicks to download, he will often be passed to a third-party site for the download
- he may not deal with Intuit to get the app, it may be a third-party VAR or ISV
- when he registers the app, he may use his QuickBooks ID and that will need to be validated / federated with QuickBooks servers
- however he may be signing up for the VAR’s service, which connects into QuickBooks as a value-add, and data may need to be shared between those systems
- integrations with other systems (such as the Google spreadsheets running on his Android phone) may also be required, all via a single sign-on
- the user may pay by credit card, carrier billing or invoice billing, via an intermediary, who in turn has to settle with the developer, Intuit and the VAR and may have to pay commission to others too
- the user’s account management may be outsourced to a third-party subscription management company
- and finally the poor old developer has to design for all of this if he is ever to grow his business and get paid!