The purchase of Instagram by Facebook is no less than an attempt to redefine the landscape of our industry: today, you are either an app, a service or a platform.
For instance, RIM will become an "app". No disrespect, it can be a formidable app, opening the doors to the Enterprise to an Apple or a Google, but the window of opportunity for RIM to be a platform is gone. In this new world, search is an app which sets the search context with a high degree of precision (yelp, UrbanSpoon...), ads is a service and the Worn out WWW amounts to the Yellow Pages (paper HTML edition).
... and maybe (always smiling) Amazon. The problem with Amazon is that they'll have to choose between being a commerce platform (and compete with WalMart) or an industry platform and play with the big boyz. I don't think these two things work well together and eventually Amazon will return to its commerce roots mainly because of the lack of social capability. Amazon is a formidable company, but they are too late to the game, they have no money in the bank to acquire what they need to compete and they are burdened by a big legacy business, deeply rooted into the Web. As (Microsoft), Google and Apple know, there are only so many social networks that can fuel a healthy platform. Most likely Amazon will become a substrate to support services with AWS, and of course, an "app", the kindle, assuming the platform guys leave these holes open (far from a given).
Yet, Amazon was a decisive factor in establishing the architecture of the platform. It reinforced the power of the vertical integration pioneered by Apple. If you come with a great device or set of devices, and an app store, customers will line up. Something that Google is still struggling to emulate with an open ecosystem, and I am not even talking about Microsoft. In other words, it is not the number of devices you sell that counts, it is the the numbers of end-users actively using the platform to buy digital goods, interact, store their stuff... If you doubt it, just ask Nokia ...
If the social integration is pretty much a given, the game gets really interesting when it comes to the vertical integration. As we have seen with Apple, customers don't see "choice" (or price) as a competitive advantage. People want simple product lines with products they can actually use, with clear and real innovation at each cycle, built by thoughtful product teams: selling incremental junk is no longer an option (as HP painfully learned). And yes, TV or Game consoles will be engulfed in the platform. How could the platform guys leave them on the table? Any device that can run an app will be vertically integrated in the platform (or replaced by one).
My best guess is that:
- MS/FB will partner strongly with or even acquire Nokia and HP.
- Google/Motorola will swallow HTC and/or LG, possibly bring Dell in its ecosystem
- Apple ... huh ... will buy Twitter, and RIM for its Enterprise App
Samsung could team up with Amazon, but most likely it will become the component provider of the platform guys. SONY's, Nintendo's and HP's troubles simply show that there is no more room for Independent Hardware Vendors: you are either a (vertically integrated) platform or you supply the platform with components, no, not even devices (I mean other than speakers and power adapters). The touch points to consumers are going to be completely locked down, not one will be left open.
Even Telco providers will be suppliers to the platform guys, with the Skype/Hangout/Facetime apps being the new face of telephony.
The interesting thing here is that unless social networks are just a fad, MS/FB is the most likely winner of that game. There is a large probability that MS/FB/NOK/HP could take on 80% of a vertically integrated, consumer oriented market. Even Ballmer could pull that off and retire on a real visionary success. Google will lose that game (this is not an engineers game, let alone using corny "Web" paradigms and UX, in any case they will take the decision to move to a vertically integrated model too late without any muscle behind it). Apple will take on a 20% "think different" crowd. Apple is not aggressive enough to win that game, they'll look back to their $100 B in the bank and ask themselves, if they could have used it more "wisely".
Facebook spent a billion, not to buy Instagram but to hold our industry by the balls. With its IPO behind, it will call the shots for years. And yes ... Zuckerberg is next CEO of "The Platform".
Fascinating times ... it's a shame that Steve is no longer with us.
06/18/2012: Microsoft announces the "Surface"
07/04/2012: Google Jelly Bean is a game changer. Google seems to finally get it, UX is key to win this game. I may be wrong after all, Microsoft may never be able to catch up. If Microsoft continues to mess up on the Mobile OS side over the next 6 months, there will be no Microsoft in the Mobile space moving forward.
07/06/2012: Amazon is planning to launch its own smartphone.
07/16/2012: Google (Motorola) is launching the Atrix HD.
07/20/2012: Microsoft reports a big jump in Skype usage, up 50%
07/23/2012: Amazon plans 6 new Kindle variants.
07/26/2012: Facebook works with HTC on its own smartphone
07/28/2012: Microsoft is in trouble, that may well be the statement that signals the decline of the company: Microsoft CEO Steve Ballmer has sought to downplay the notion of Surface competing with partners, recently calling the device “just a design point.
7/31/2012: Details on Microsoft's plans to move to a vertically integrated model
8/20/2012: It looks like Microsoft does not aim at partnering / merging with Facebook, they sold 20% of their stake right after the IPO, that's kind of a shame, without even the shadow of a social network, they will have a hard time getting there. Unless their secret weapon is to make Yammer a general purpose social network.
8/22/2012: "The Platform" is on Amazon's Navigation Bar: App Store, Storage, ... Critically missing is the social network component.
9/06/2012: Amazon unvails the new Kindle, "People don’t want gadgets anymore, says Jeff Bezos, they want services that improve over time. Kindle Fire is a service. It greets you by name. Comes out of box with content preloaded, makes recommendations."
9/06/2012: Mobile gamers outnumber the console core.
9/12/2012: Zuckerberg "Facebook's Mobile opportunity is much bigger than what people think", "Everyone is now "underestimating" Facebook" (I am not ...)
10/02/2012: Windows Mobile market share continues falling
10/02/2012: 1st Apple-approved iOS game controller makes its debut
10/04/2012: Facebook Tops a Billion Users
10/09/2012: Ballmer to Microsoft shareholders: 'a fundamental shift [is] underway in our business' In his annual letter, CEO Steve Ballmer says Microsoft's future is a tight combination of hardware and software
10/12/2012: For the first time this month people searched less than last year. Our interpretation is that people now search more in context, using dedicated apps on their mobile device. This is particularly disruptive because that is the kind of search that has the most impact on commerce and advertising.
10/22/2012 Subliminal message from Zuckerberg: I would have worked at Microsoft if facebook had failed
10/25/2012 Ballmer: Microsoft has more hardware to come.
11/2/2012: Microsoft is testing its own smartphone
11/6/2012: Verizon shuts down its App Store
01/22/2013: Microsoft talks about investing 3B in Dell
02/14/2013: HP to adopt Android
We will showcase Canappi during an AT&T Webinar on "Building Multi-Platform Native Applications" on Wednesday 9/15.
Canappi is a Mobile Application Development Platform that generates iOS or Android code from a DSL. It also generates back-end services (MySQL/PHP and WSO2 Stratos Data Services).
Please register here to view the webinar.
Since 2007, the industry was told by a handful of people that the "Web" could teach us everything about distributed computing, and that everything we had done before was simply wrong. Four years later, we can only see that the emperor is completely naked (what else could we expect?).
REST was designed with an end-user in mind, operating a user agent: the browser (I know Roy is going to get mad if he reads this). Everything that has been written to apply REST principles to a software agent-to-server scenario is simply wrong. To quote Roy himself:
A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API).
A REST API should never have “typed” resources that are significant to the client. ... The only types that are significant to a client are the current representation’s media type and standardized relation names.
A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace.
How many Web APIs are actually designed that way? It is time to move on from all this mind bending serendipitous complexity that brings absolutely nothing, except more lost productivity by forcing to everyone to hand code everything we got for free in previous distributed computing paradigms.
So I encourage everyone to unREST with pride. No offense to Roy, REST is brilliant. It is just not applicable to the problem at hand and we should give him some REST in return, for all that he has given to us. It's cool to be RESTless. Let's not waste any more time.
So what does it mean to unREST?
a) Define a uniform interface that suits your domain
There are many uniform interfaces to choose from: Send/Receive is one, GET/PUT/POST/DELETE is the "REST" one, CRUD has been used for 30 years world widely, ...
Don't be shy, forget the 4 little HTTP verbs, you can even define your own: Query/Do/Notify/Synchronize is a perfectly good one. It means that all methods in your Web API will be of type query, action, notification or sync request.
One could even imagine a 3-legged uniform interface, well suited to support modern converged / composite applications.
In fact, REST's so-called "uniform interface" is quite broken outside of the Web as some queries must be implemented with a POST and lots of people struggle to use PUT, POST and DELETE meaningfully. I have seen a standard using DELETE to implement the "cancel" payment operation. (I bet that's what some would like to do with their CDS transactions... )
A uniform interface is essential to a healthy API, pick one that fits your domain and stick to it. Let your infrastructure know about it from a security , scalability ... perspective.
b) Specify messages
when two agents communicate, they exchange messages. Duh? These messages rely on a shared understanding of some sort be it a standard type or semantic. Define your API messages loud an clear. This is a major step in becoming unREST. The syntax of your message doesn't matter, who cares about XML, JSON, Protocol Buffers? What is essential is that your syntax must be extensible. This is what allows forward versioning.
Explicit message definitions which can be explicitely versioned is essential to a healthy API definition. Message Extensibility is the property that makes distributed computing work.
c) Specify contracts with a clear versioning strategy
There has been many "IDLs" defined over the years, few were truly message based. Think of a relationship between software agents as forming a machine readable "Contract" that defines the rules upon which messages are exchanged between them. A contract is something you break only when you have no other choice. A Contract is most often bi-directional and asynchronous (anyone is receiving any notification on their phone?). Thinking of every relationship as being synchronous and of type client/server, is pure nonsense. Convincing people that they could do without a contract, just with some "human readable documentation" (HRD) is also pure nonsense. How many millions of hours have been wasted worldwide the day we decided to drop WSDL for "HRDs". A uniform interface is not enough to form a contract, it is only the substrate on which a contract is defined. That contract is not uniform, by any stretch of imagination.
Machine readable contracts are the foundation on which to build a healthy ecosystem of Web API consumers. Versioning is essential to evolution and reuse, and hence a healthy API.
Please note that, reuse, in distributed computing, happens the other way around when compared to traditional software engineering. It is the old "clients" of a Web API that "reuse" the new versions of a service (without breaking). Who would expect that anyone could design an API that 3 years down the line would be "reusable" by any 3rd party consumer? It is far more valuable to enable existing client to "reuse" the new features of your API, at their pace, without breaking them, for every tweak you make into your message formats.
That's it, that's all you need to create a successful API nothing else, nothing more. Sure, it would be great if we converge on a handful of uniform interfaces and versionable message /contract specifications. I am not sure we can find "the one" that works for everyone.
I have participated in crafting web-based protocols for most of the last 12 years, starting with ebXML in 1999. The big difference between today and then, is that we have thousands of openly available data points teaching us, we, the "standard" guys, how people actually create APIs, for what purpose. Maybe for once, they could teach us a thing or two. That would avoid picking just a couple of use cases convenient to a vendor's product and forcing the REST of the world fit under that petty umbrella.
You are now free to unREST and laugh quietly at anyone who asks you to marvel at an HTTP header, a "link", use a 7 letter acronym, or tells you with the authority of a story teller that you don't get it. REST was just a (bad) dream, unREST is what you want to do.
The core of the presentation is on two slides (10 & 11). They focus on two important dimensions of mobile apps: the information dimension and the actions dimension (there are more such as the Converged dimension or the UX dimension).
Mobility is a major paradigm shift because mobile apps are based on a 3-legged information model: Product-Place-People, unlike the tethered Web that has no actionable location information. Amazon's business model, for instance, relies solely on linking products to people and I would not be surprised if a startup coming out of nowhere disrupts Amazon's eCommerce franchise.
Why? because location is not just about finding disruptive way to link products and people, it is also weaving time (i.e. events) into the business model and, most importantly, it makes the world "actionable" (taking actions at a distance doesn't always work well...).
This new relationship between people and products (via places, events and action) gives the opportunity to create a virtuous circle (slide 11): people, places and events enable advanced advertising/offers models and as people take actions on goods, services, media, knowledge ... (such as purchase, consume, invoke, favor, link, collect ...) it gives the ability to capture favorites and historical data (which would be impossible to tie to a location or event without a mobile device) thereby providing a formidable feedback loop to advertising models and offers in very innovative ways.
Hope you like the presentation and join us in Redmond if you can !
Boris posted yet another article on SOAP vs REST on InfoQ yesterday. I had demonstrated last year that REST had brought nothing new. This is year it is even more crying. Nobody cares any longer about being RESTful, the industry even came up with a new term to celebrate this transition: "Web APIs". "Service" is the new "Distributed Object". I am actually ready to give $100 to the first person who proves me that there are more than %1 of Web APIs on the Programmable Web that are "RESTful" (i.e. at least 33 with the current count of 3300+). What I mean by RESTful is that 100% of the provider's Web API follows REST principles (URL path, correct use of HTTP verbs, use only HTTP verbs + nouns, HATEOAS, media types ...), you know the kind of things that the RESTafarians sold to the industry way back when in 2007. (I am dead serious, send me your list and I'll publish it and send you a check).
The problem that REST has created (that my good friend Jim Webber would simply qualify as the Same Old Atrocity) is that now any API designer gets a free license to be a distributed computing guru, artistically deciding where to put things like version and credentials, and encode actions and queries as they please amongst a wealth of headers, tokens, query parameters, bodies and what not. If you ask me, REST has produced the software industry WOrst Atrocity ever.
But, let's move on, because it actually doesn't matter: we now live in a POST REST/SOAP world. Converged (Mobile) Applications have pushed the envelope of what distributed computing should do and how it does it. Never HTTP or SOAP were really prepared for 3-legged authentication, respect privacy and support monetization at the scale of several billion API calls/month. Actually SOAP was a bit more prepared since a message could have a number of security tokens representing different principals, but who cares, we were told that HTTP was the answer, because it was "RESTful" so now we struggle with all kinds of three-legged authentication mechanisms.
A converged app is an app that is leveraging a combination of 21st century capabilities like voice, messaging, data, location, video, payments ... in a secure and privacy-friendly way. A typical converged app would be for instance an app that is able to call FourSquare Web API to get my list of friends nearby, lookup their phone numbers from a "My Contacts" API (Local or Remote), then call Yelp to find the places where we could meet or EventFul for the events we could go to and finally call Twilio's SendSMS API, and see who responds. The app collects the votes, and everyone meets at the place that has the most votes. After the party, the same app would allow me to share pictures and videos with all my (FB) friends. When using a converged app, end users don't want any API provider (and marketer) to know what they are doing, this is called privacy, something the good old Web made a business model of, on your back. Web advertising has become creepy lately because I visit sites I never visited before who advertise for products I searched on Google last week. That is really creepy, it turns me off completely.
Converged applications are changing everything because the ability to mashup APIs (and no longer just establishing a one-to-one consumer/provider relationship) becomes the most important focus of the application, in a 3 legged scenario where the user, the application and the Web API provider(s) are in a completely different relationship than the monolithic relationships we were so used to, in the mainframe, client-server and Web app days, where basically the enduser "logs in" to a monolithic app and that app only knows what the user does with it.
What's a "contract" in this new world of Converged Applications? after all the industry is only selling billions of them every year. Shouldn't we care a bit? As a starter, if you are an API provider you better get ready to manage the "apps" that consume your API and start issuing API keys. Is there a standard for that? uh? sorry, the standard bodies missed that. API keys are now the key to your endpoints. Shouldn't you also try to avoid the embarrassment of a Facebook which leaks its enduser identifiers in its API in 3-legged scenarios, seriously and totally compromising the privacy of their members. uh? is there a standard for securely and privately identifying users (and other key identifiers) across converged apps? uh? can REST do that? SOAP? wake up... guys the world if moving at lightning speed.
The old "consumer/provider" relationship established by SOAP/WSDL and later "enhanced" with HATEOAS is completely overwhelmed by this new world. Just take the simple problem of mapping data identifiers in a mashup (PK/FK). We need a new "contract" concept much more consumer centric, that helps build and maintain converged applications. At canappi, I have started to come up with such contract definition. If we wait for another year to come up with a decent Web API versioning strategy will create "for-ever" APIs or a massive break-down in all the converged apps. We also need much more sophisticated security standards, where a service provider needs to enforce that an authenticated application, used by an authenticated user does what it is supposed to do while understanding a thing or two about privacy and monetization (Converged App users vote with their wallet, not "clicks"). Finally, I contend that HTTP is completely inefficient to serve Gazillions of API calls per year and that we need a much better API protocol.
We also need standards that are (client) developer friendly not Google or Facebook friendly, that let them write apps that are (3-legged) secure, privacy-aware and monetizable (unlike HTTP or SOAP). It's already hard enough to write a mobile app, we don't need any kind of additional crap because it is convenient to X,Y or Z API provider. We are in the digital economy (if you doubt it, just check how many swords your phone carrier sold last year): we need the standards to support it. Will the industry really have the courage to take that on? will my good friends in the standard bodies, for once, try to be ahead or at the very least in line with their time? or will the RESTafarians one more time force us to hand code every f**ing API calls? I doubt we'll do the right thing, but I'd love to be wrong.
The Web, as it was designed 20+ years ago, is old, way too old to move forward in the Converged Apps world. Anyone who tries to convince you otherwise is emotionally attached to this great but rapidly aging platform.
I attended a presentation last night by Tim Bray on the Android Ecosystem. Here are my notes, he provided a great perspectie on defining a business model for your mobile app.