My contention is this: "The cloud" is a mechanism to enable services of commodity functionality [Which is another name for work] and as such, a well understood taxonomy or organization of these commodity functionality will need to be developed in order for higher level functionality to prosper in the cloud.
To understand this, understand that functionality can be described as: Core (value adding), Unique (necessary, but no provider we trust), Commodity (necessary and providers we trust) and Extraneous (not necessary). Core competencies (functionality), as described by Jack Welch, is work that a company focuses on being the best at to set itself apart from its competitors. Unique is work that is needed to be done but it doesn't set us apart directly and there aren't providers that we can trust to do the work. Commodity is work that is needed to be done that doesn't provide differentiation but there are providers who can do the work. Extraneous are waste in the lean six-sigma sense.
In real-world products, we have seen business outsource accounting, payroll, manufacturing, sales, IT. Following Jack Welch's advice of focus on core competencies and allow others to offer a service which encapsulates the work that isn't core to your value proposition. This makes sense. It leads a company to only, for the most part, focus on things that matter to its bottom line. However, a company will still need to do unique functionality because no one else can. Our goal should be to convert, as much as advisable in terms of security, functionality from unique to commodity. Even potentially creating new industries to provide that functionality. Stated differently all work that is necessary for a business to operate should be provided by an entity whose core competency is doing that particular work.
So applying this to information technology, there are algorithms that are core, unique, commodity and waste. If we follow the same advice, our efforts should be focused on our IT's core competency. Work that is unique we should plan how to make it commoditized. Commodity should be being done by others and waste should be eliminated. But how do we make this happen?
With the advent of services and well-understood interfaces, it has become operationally easier to separate out the core from the commodity services. The cloud starting from the ground up, with storage, database, computing power, networking. Functionality that all systems share and because they have stable, mature, well-understood interfaces. This is not really due to the efforts of the cloud community for they stood on the shoulder of giants. Rather it was the efforts of IT Vendors and standards groups that standardized the interface allowing the creation of their products. Remember these standards allowed the syntactic ambiguity and also, to the extent possible, the semantic ambiguity to disappear. However, this canonization effort is expensive, time-consuming and potentially a pre-ripe standard may stifled innovation to soon.
High level functionality such as business rules, calculation, decision logic may indeed be capable of being a commodity. However, trust, the ecosystem of providers, the organization of functionality and the interfaces standards for the functionality are immature. Thus it traps potential commodity functionality as unique. Or it requires that business purchases a large package that stands in for the undeveloped ecosystem which can hinder your IT organization from being enabling business differentiation which should be its primary objective.
SAP and other large package vendors will tell you that they are opening up to allow highly customized processes and manipulation of data. They will even allow you to call a web service from an external (to SAP) provider (probably will be you!) and use the response in your process. So, in essence SAP (and all the other ones too) has turned into a platform that provides a rich array of functionality and process to accelerate your mapping of your emulated business to your real business. This platform can become the focal point of your business. Is this new? no. Is this bad? no. But the ecosystem needs to extend out. Potentially even replacing parts of the rich array of functionality or perhaps replacing the platform. A business using a package should ask itself, what is the core competency of our large package software and map that answer to the previous goal: all work that is necessary for a business to operate should be provided by an entity whose core competency is doing that particular work. No vendor can provide all functionality to all types of parties as part of their core competency. At least not to the determent of some of the functionality. So, how do we build an ecosystem that will allow best of breed augmentation using external functionality? How will we know who has what? And how difficult will it be to have multiple providers or to switch providers? Asked another way, how do we abstract out the functionality from the provider?
These, I believe, are the core questions to prompting us to make high order functionality available on the cloud. We tried UDDI, but there wasn't a good taxonomy developed to describe where the functionality fit. As well, there wasn't a good semantic ontology developed to describe the interfaces. Nothing helped us be agnostic to the physical interface.
So my solution:
Imagine in a folks-onomy way a provider builds a version of their functional taxonomy. This would include the semantics of what the functionality does. As well, the semantics of the interface.
This world would also includes a more generic taxonomy built with help of linguists, computer scientists that is semantically accurate. These taxonomies will be built, probably, along industry segments lines. The company accomplishing this intellectual property, will work with individual providers to help them map their own taxonomy to the more generic taxonomies potentially across industry boundaries. Where holes appear, the company will modify the generic taxonomies to make it a more complete and living entity.
The beauty of this is when a company wants to consume commodity functionality. They search the functional taxonomy to find what they need. Their platform/package provider will jump start their own taxonomy and the individual consumer will modify it to match their particular implementation. The individual company will a more specialized functionality for its business than its package provider provides. Because providers publish what functionality they provide and a match can be found at run-time. Also, because the interface is semantically tagged, the consumer can provide the correct information based on its data's association with the generic taxonomy at run-time and convert the response to its own format.
Therefore, the physical interface doesn't need to be well-understood, just semantically understood. Which has been a huge problem all along. We don't semantically tag our information (as a general rule) to an authoritative source . In the same vein, we could do the same for describing nouns, processes and events. It is in organizing our functionality (work) and our information that will allow our trapped unique functionality to become commoditized and therefore meet our goal.
I think a company that can build and maintain the taxonomy so that semantic accuracy can be a first order principle in software design would be an awesome place to work. As the cloud grows and encapsulates higher order functionality, semantics will be foremost! Well, until it itself is commoditized.
Anyone want to help me build this company?
No comments:
Post a Comment