As a veteran of three or four (depending upon how you count them) majorly disruptive changes in computing, I’m always on the lookout for things that distinguish cloud computing from what-has-been-before. I am seeing a rather interesting change in the notion of “conformance” as it applies to the way specifications are written and negotiated.
What Does “Conform” Mean?
To be brief (and oversimplify somewhat), in the age of packaged software, a statement in a specification that “conformant implementations MUST support FeatureX” is a promise about the possible behavior of any software claiming to conform to that spec. If you buy a chunk of software that claims to conform to this specification, it must be possible for you to configure that software such that FeatureX is supported. Note that this configuration doesn’t have to be the default configuration. The vendor that sold you the software may even recommend against such a configuration. Nevertheless, that vendor can rightfully claim that their product conforms to the spec, even if some of their customers “choose” to configure their deployments in ways that are not spec conformant.
In the cloud, a statement that “conformant implementations MUST support FeatureX” is more closely a statement about the actual runtime configuration of any system claiming to conform to that spec. Because the vendor and provider roles have merged, “the vendor” cannot simply allow “the provider” to enable support for FeatureX – FeatureX has to actually be supported in the systems that are deployed and operated by that provider. There are ways the provider can skirt this, for example, by allowing/enabling FeatureX on a per-tenant basis – but, overall, it seems to me that the move to cloud computing has reduced the amount of wiggle room available to implementers.
Sausage Making
Warning to anyone laboring under the illusion that specifications are crafted by disinterested scientists whose main goal is technical quality: this next section deals with some of the political/technical maneuvering that goes into creating specifications and may be unsettling.
Let’s lay out a scenario: You are involved in a standards-development group that is collaborating on the specification of some API. It turns out that some members of this group feel that it is absolutely essential that the API MUST support FeatureX. After researching their proposal you become convinced that these people have been engaging in some activity that seriously impairs the functioning of their pre-frontal cortex. You try arguing them out of it, watering down the requirement, etc. all to no avail.
If you are representing an organization that develops and sells packaged software, this situation is not too dire if (1) FeatureX doesn’t affect too many other areas, (2) a minimal FeatureX isn’t overly complicated and difficult to implement, (3) you are reasonably sure that none of your customers will ever want FeatureX. Simply get your developers to implement a minimal version of FeatureX, enable it as a non-default configuration option, and ship. If you are right about (3), the code for FeatureX will never be exercised outside of conformance testing. You and your organization may not want to do this, but you have some degree of flexibility.
Now suppose you are representing an organization the develops, hosts, and operates a cloud service. Even with per-tenant configuration tricks, the call to require FeatureX means that your organization not only has to develop the code to support FeatureX, it may have to deploy it and support it. This significantly raises the stakes around conformance – particularly for features that are “operationally infeasible” in your particular architecture. You can’t be flexible about a requirement to support a feature you can’t actually support.
Upshot
I see a couple of obvious effects of this difference in the context around cloud specifications. The first is that cloud specs will take longer to develop. Arguments that formerly could have been resolved with a “fine, have your FeatureX” now have to follow some (in all likelihood torturous) course that morphs FeatureX into something everyone can support and/or some parties have to reconcile themselves to the refactoring work necessary to support it. Secondly, I expect cloud specs to have fewer strange requirements that were included due to the intransigence of some parties and laziness of others. This is a good thing for interoperability and thus for humanity at large.
Caveat
Note that none of this has anything to do with the creation (or blessed lack thereof) of “optional features” – i.e. features that are described by a spec but not required to claim conformance. As near as I can tell, there is nothing about the context of cloud computing that effects the creation of such features one way or another.
