The three biggest trends impacting computing today are what I call the Computing Troika. Cloud Computing, Mobile Computing and Social Computing.
There is a fourth trend that is on par with each of the Troika movements. The API Economy.
Finally there is the question of the role of standards in these trends.
First, here is my definition of Cloud Computing—and its opposite—Non-cloud Computing.
Cloud Computing involves offering network computing services with the following three characteristics:
- IT Virtualization
- Service re-usability
IT Virtualization—Network services, including management and support, that are geographically independent. That is not to say that services are not on-premise, it just means that it doesn’t matter.
Multi-tenancy—Network services that offered to more than one tenant at a time.
Service re-usability—Network services that can be used and built upon for all tenants over and over.
All three are important. The one that needs explaining and is not so obvious is the Service Re-usability feature. AD FS (Active Directory Federated Services) integrated into WAAD (Windows Azure Active Directory) is a good example. Because it is virtual and multitenant, a single SAML instrumentation to WAAD gives permissioned SSO and integration to EVERY customer connected WAAD by default. This makes it highly leveragable and “reusable.” Further, all of the services to all tenants of WAAD have the same APIs, the same console UI, indeed, the same infrastructure from top to bottom. This lets IT departments be much more efficient and competitive.
But here is where the new rubber meets the road. WAAD is specifically designed to give the customer real freedom of choice. This is done by not trying to keep the customer captive with either architecture design or terms of service.
The architecture design moves from keeping the customer captive in a Silo with two main features.
- Standards support
- APIs for everything
Standards support is the traditional bailiwick for interoperability. Interoperability is the key feature of services that are vendor independent. But standards are not a panacea. Standards movement is slow. Further, it is a myth that standards compliance guarantees interoperability. One vendor’s standard floor is another vendor’s standard ceiling. To remain competitive, vendors tend to tweak the standard game—sometimes in excess—to maintain an advantage.
The new equalizer—for both the customer and the vendor—is the API Economy. By providing open simple API access to everything, a vendor can still differentiate and yet offer real freedom of choice to its services. With complete APIs infrastructure, services are no longer Silos. Any customer or competitor can duplicate or extend the Apps that use the services (such as an admin console, user portal or developer portal) without repercussion.
“Non-cloud” then becomes any architecture design that does not include all three of these features. Note that this puts even more importance on the API Economy. The IT computing silo prison can only be broken through an active API Economy. The key to the successful customer-centric product design is giving the customer Freedom of Choice. Freedom of Choice is not freedom of captor. Freedom of Choice must be vendor independent. Independence can only be gained thru the API Economy coupled with traditional standards process.
There is more than one type of standard.
The three main types are:
- de Facto
- de Jure
- de Riguer
De facto—is the Latin definition “by default”. TCP/IP is actually a de facto standard. It was declared by governments that the standard network protocol would be the de jure OSI standard. As we all know, OSI never happened. TCP/IP is the de facto standard of the internet.
De Jure—is the Latin definition “by jury” or committee. HTTP is a de jure standard by the WC3.
De Riguer—is French for standard by current fashion. De Riguer goes far beyond “fashion”. Both de facto and de jure standards are very slow moving. In fact, a de jure standard is—except for governments— obsolete and certainly out of fashion by the time the committee ratifies the standard.
I bring up the distinction of these three standards because I think that what we can expect is to see a rapid proliferation of de Riguer standards that are built on top both de Facto and de Jure standards that are highly usable and can be referred to and used as “standards” that can provide interoperability without either a laborious and expensive de Jure process or the expectation of an accidental de Facto crown.
For example, the use and creating of “Graph API” design and methods as we see in the Facebook and WAAD API design are going to become standards independently of any committee. Of course the thought of this kind of talk scares a lot of people to death because of the kind of crazy behavior we see from vendors like Twitter and what it has done to its developers and its API.
But it is my opinion that when vendors act in such irresponsible ways they do so at their own peril I believe in the long term that we can successfully lean on rational thought and behavior that will support a strong three standard ecosystem that works.