It’s the Viewers Dummy

I hate to pick on Mindjet again but I wouldn’t bother if I didn’t love their program (MindManager) and really want to see other people use it, yadda, yadda. I’m the “enthusiastic but cranky customer”. Sometimes it’s important to listen to me. So here goes:

What’s with the overhead of getting a free, viewer-only version of MindManager? Seriously, didn’t Adobe (and hundreds of others) show everyone the way on this? The value of any document I create in MindManager is directly proportional to the number of people that can “easily” view that document. And (this part is important) the bar on “easily” is going down as the internet evolves. Ten years ago you could ask people to spend 20 minutes jumping through hoops to get a free version of your product but, as they say, “things have changed”.

I’m trying to share information with people that may or may not understand the value in mind maps. A lot of people are still unfamiliar with the concept. Most of the people I have introduced to mind maps have gotten really excited about them. But, if you make it too hard for them to at least see their first map, there’s no chance you are ever going to convince them.

The best thing Mindjet could do would be to implement something in the “code-on demand style” that could view any .mmap file (doable in JavaScript? – no idea, sorry.) Short of that, they need to make it very easy to download and install free viewers on whatever platforms make sense (can you really do anything useful with a mind map in a handheld form factor?)

Finally, if you (the mythological reader) are thinking of taking me to task for using proprietary file formats – yeah, yeah. I may often claim to be right, but I seldom claim to be consistent. I like all the bling, bling in MindManager and I haven’t found free mind mapping tool that gives me that.

Cloud Broker Overload

'That's a great deal to make one word mean,' Alice said in a thoughtful tone.
'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'

- Through the Looking Glass

“Cloud brokers” are a hot topic, thanks in part to their inclusion in the NIST Cloud Computing Reference Architecture [1]. NIST’s definition derives, in part, from a 2009 Gartner report [2]. As Ben Kepes points out [3], these definitions of cloud broker are at odds with the accepted meanings of the word “broker”. Ben also makes the point that the issue is more fundamental than what names we use to call the various actors in a multi-provider scenario. The article suggests the term “service intermediary” as more descriptive of the kinds of things that companies like enStratus and RightScale actually do – where “service intermediary” is defined as an actor that does service intermediation and/or service aggregation but doesn’t do service arbitration. Although I agree with much of Ben’s article, I think it misses the main problem with the NIST definition.

The Boat Analogy

Suppose I wanted to buy a boat. For various reasons, I decide to use a boat broker. I expect the broker to (among other things) introduce me to the parties selling boats and help me work through the process of buying the boat. The interaction pattern is three-way. The seller, the broker, and I are all aware of each others existence and expect different things from one another. For example, if the engine seized the day after I bought the boat, it is doubtful that I would hold the broker responsible.

Suppose that, instead of buying a boat, I simply wanted to rent one. Now, instead of seeking out a broker, I would look for a boat charterer. In contrast to my dealings with the broker and the seller, my interactions with the chartering company are two-way. The chartering company may or may not own the boat. I don’t know and, ultimately, I don’t care. All I care about is that the boat is made available for my use over a specific period of time. Any problems with the boat are the responsibility of the chartering company – regardless of who owns the boat.

The main problem with the NIST definition is that it lumps “brokers” and “charterers” together and, in so doing, masks the significant differences in the interactions and expectations of the parties involved.

It’s the Relationships

The first step to unraveling this hairball is to stop focusing on the functional aspects of what (for argument’s sake) I will simply call “the intermediary”. Whether the intermediary simply arbitrates requests amongst (nearly) identical back-end providers or synthesizes an aggregation of different providers to create a new service is not as important as whether or not the consumer does or doesn’t have a contractual relationship with these back-end providers.

Regardless of how many back-end services an intermediary uses and regardless of how imaginatively it might use them, if the consumer doesn’t have a contractual relationship with those back-end providers, their interactions with that intermediary are no different than those of any other cloud provider. While the intermediary may have more fodder for excuses (“our storage provider failed in exactly such a way as to expose a heretofore unknown bug in our billing provider”), an SLA is an SLA and, if the intermediary fails to meet their SLA, the consumer is entitled to whatever compensation is specified in the service contract.

If you squint at the NIST definition you can infer that the distinction it draws between “given services” and services that “are not fixed” are a reference to the visibility (or lack thereof) between the consumer the back-end services. If this is the case, this distinction needs to be made explicit and unbundled from the definitions of intermediation, aggregation, and arbitrage.

Functional and Business Relationships

Most of the discussion around cloud brokers tends to focus on the functional relationships (i.e. who sends requests to whom and how are the results processed). Above, I point out the importance of the business relationships (i.e. who has contracts with whom). Obviously both sets of relationships are important. What makes multi-party cloud scenarios interesting is that the two sets of relationships are independent of one another. This can lead to a fair number of different scenarios.

Take, for example, the “punch out” scenario found in many enterprise purchase portals. The consumer (an employee) has both business and functional relationships with the intermediary (their employer). At some point there is an SSO exchange and the consumer is redirected from the intermediary to the provider (the supplier’s website). Although the consumer now has a functional relationship with the provider (in that they are sending requests and receiving responses from the supplier’s site) they do not have a business relationship with the provider (i.e. they aren’t asked for their credit card). Behind the scenes, there are both functional and business relationships between the employer and the supplier (the order information is sent back to the portal and the supplier expects to be paid by the employer).

If we confine our considerations to a cloud consumer, a single intermediary, and a single cloud provider then further restrict ourselves to consider only those cases in which the consumer has, at a minimum, a functional relationship with the intermediary and a business relationship with at least one other party – I figure there are 26 possible scenarios (you may want to check me on this). Granted, many of these combinations may not have a workable business case, but here are some discrete examples:

Jamcracker

• consumer has business and functional relationships with intermediary (Jamcracker)
• consumer has business and functional relationships with the cloud provider (e.g. WebEx)
• intermediary and cloud provider have business and functional relationships

SpotCloud

• consumer has business and functional relationships with intermediary (SpotCloud)
• consumer has no business or functional relationship with cloud provider
• intermediary and cloud provider have business and functional relationships

Akamai

• consumer has functional but no business relationship with intermediary (Akamai)
• consumer has functional and business relationships with the cloud provider
• intermediary and cloud provider have business and functional relationships

Again, the danger with calling all these scenarios “cloud broker scenarios" is that you will mask important differences in their characteristics and behavior.This creates both confusion and misunderstanding.

The Taxonomy Challenge

Obviously we can’t simply give each of the possible multi-party scenarios a unique name; there are too many to remember. What we have is the classic problem of taxonomy. The scenarios are distinguished along a number of different axes and it is difficult to tell which axis is “the most important”.

While I don’t have a complete answer to this problem, it seems to me that it makes the most sense to do the “top level split” around the existence or non-existence of any business relationship between the consumer and the back-end provider(s). Although it pains me to admit it, the industry is coalescing around the term “cloud broker” to refer to scenarios in which there is no business relationship between the consumer and the provider (exactly the opposite of how the term is used in the real world). This leaves the term “service intermediary” to refer to those scenarios in which there is a business relationship between the consumer and the cloud provider.

When describing new things it is easy to fall into the trap of wasting time arguing about their names. Regardless of what terms people use, it would be helpful if we consistently used the same, separate names to refer to the top-level cases I outlined above. “Broker” and “intermediary” are as good as any others.

Final Digression

I suspect that the term “cloud broker”, as it is currently used, derives from an older term – “message broker”. This makes sense because “message broker” is misapplied in exactly the same way as “cloud broker”. “Message broker” is commonly used to refer to an architectural pattern in which you use an intermediary to minimize or eliminate the producer’s and consumer’s awareness of each another.

References

[1] NIST SP 500-292, “NIST Cloud Computing Reference Architecture”, http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/NIST_SP_500-292_-_090611.pdf

[2] Gartner, “Gartner Says Cloud Consumers Need Brokerages to Unlock the Potential of Cloud Services”, http://www.gartner.com/it/page.jsp?id=1064712

[3] Diversity, “NIST Decides to Redefine the English Language, Broker != Service Intermediary”, http://www.diversity.net.nz/nist-decides-to-redefine-the-english-language-broker-service-intermediary/2011/09/12/

Spec Conformance in the Age of Clouds

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.

lyrics daddy moon

If you came across this because you are searching for the artist or lyrics to the song that played on the episode of Parenthood that aired Tuesday, January 11th 2011 that has the hook line “oh daddy moon …” this post is to tell you that artist is Tom Freund and the name of the song is “Little Room Of Mine”. You can find the song on his latest album “Fit To Screen”.

Obviously I like Tom or I wouldn’t be trying to help other people find him. If you liked “Little Room Of Mine” you’ll like is other stuff.

Technorati Tags: music,tomfreund

The Mind that Maps

Considering my appetite for cool software tools, it shouldn’t come as a surprise that I’m into mind mapping software. I’ve used MindManager for years now and, though I like the product, I can’t see shelling out $180 for an upgrade when there are so many cheaper/free alternatives. Is it too much to expect Mindjet to factor the existence of these competitive offerings into their pricing? Or is it just the case that MindManager is targeted at the enterprise and no one actually uses their own money to buy it?

Technorati Tags: mindmap,tools

Something Clever to Say

I often wonder how many misbegotten trends in IT have their origin in the need to say something clever about a subject that you don’t know very much about. Example (circa 2002):

Joe’s Manager: Joe, what do you think about this web services stuff?

Joe: (scrambling) I think it has a lot of potential but, uh . . ., they really need to solve the security problem first.

The truth of the matter is, at the time, Joe knew almost nothing about web services, SOAP, etc. but he had read/overheard just enough to know that “everybody” was concerned with “the security problem” (whatever that was). The result was the development of a boatload of  new technologies (WS-Security and its attendant profiles, WS-SecurityPolicy, WS-Trust, WS-SecureConversation, etc.) when the vast majority of SOAP deployments do fine with little more than SSL and BasicAuth. I remember a SOAP-oriented conference in 2005 in which a vendor rep asked the audience “How many of you are using or planning to use WS-Security?”. When only one hand (in a room of at least 100) went up, the rep went slightly non-linear saying something to the effect of, “WTF, you asked us to build all this stuff …?!?”

Fast forward to today and substitute “cloud” for “web services”. I’m willing to admit that there are a few security issues that are unique to the cloud (mostly around multi-tenancy), but I assert that 99% of “cloud security issues” are no different than current IT security issues. I’m worried that, in their need to have something clever to say about the cloud, people are creating the false impression that someone needs to invent a whole boatload of “cloud security” technologies when we simply need to re-apply our current security solutions.

Technorati Tags: cloud,security

For the Children

BuzzNet Tags: prop19,marijuana,legalization

While I’m on the subject of marijuana legalization, I just have to spend a few moments rebutting one of the stupidest arguments I heard in the recent debate on CA’s Proposition 19 - “If you legalize pot, all your kids will be doing it”.

To understand why I think this is such a dumb argument I have to relate the following. When I was a kid growing up in the suburbs of Chicago in the late 70’s it was way, way easier for me (and everyone else I knew) to get our hands on pot than alcohol. Why was this? Because alcohol was legal for people 21 and over and pot was illegal for everybody.

The people I bought pot from, and the only way that anybody I knew got pot, were acquaintances of mine – sometimes slightly older kids. Meanwhile the only place to buy liquor was stores and bars. The kids selling me pot weren’t taking any great risk in doing so – we’re talking very small quantities here and you had to be a true idiot to get caught. The people who weren’t selling me liquor were doing so because they didn’t want to lose their liquor license for the sake of a cheap case of beer and a bottle of peach schnapps.

This may all be anecdotal, but I’m pretty sure it’s not. If you want to stop people from selling any kind of drug to kids you have to (a) legalize that drug for use by adults, (b) license the sale of that drug, (c) revoke that license if they are caught selling to minors. You need the carrot and the stick. If I were emperor of CA, I’d tie your liquor license, your lottery concession, and your marijuana license into one big bundle – get caught selling any of these to minors and we’ll revoke all three.