My longtime correspondent Raymond Yee, who I finally got to meet when I visited Berkeley last year, is writing a book on remixing data and services. The book mentions my elmcity.info experiment but, when Raymond visited the site the other day, all he saw was the text of the FastCGI script that runs the whole show. It turns out that when BlueHost upgraded Apache, they broke the mechanism that’s used to invoke arbitrary FastCGI scripts like my Django launcher.

It’s fixed now1, but the incident reminds me that I haven’t yet fully developed the line of thinking that I’ve now tagged servicemanagement. What I am increasingly feeling, as I’m sure many others are — and not only geeks, but also and especially civilians — is that it’s becoming impossible to sanely manage and control our growing numbers of service relationships.

That lack of control was the real point of my Verizon story, for example. And my story is tame compared to this one from John Halamka, which begins:

On Thursday, December 20, my FiOS internet/TV service was shut off by Verizon without any notice or warning.

and concludes:

As CIO of Harvard Medical School and CareGroup, I spend millions every year with Verizon and I cannot navigate Verizon Customer Service.

One aspect of the service management console I envision here would be a common view of all the services I depend on, green/orange/red for healthy/sick/dead.

In the case of a website, it’s not enough to know that the box (or webserver) is alive, healthy means delivering the expected page. There are a million ways not to, and so in the past — although not in this case — I’ve used a cache-and-compare method to verify. It would be entirely feasible for a web hoster to wrap a user-friendly interface around that method, so that anybody could easily declare expected outputs, but I haven’t seen this done by a commercial hoster.

Of course every service relationship sets up expectations, so there are all kinds of assertions you might want to make. I received the e-bill by the expected date. My paycheck was deposited. The payment I made was credited to the right account. The package I sent was delivered. The book I returned to the library was received and checked in.

I want a common way to make all these assertions, and to subscribe to notification of assertion failure.

I’d also like my personal service management console to be subscribed to streams of events, from service providers, about the operation of their services. The expiry notice from EZPass, the Apache migration email I may or may not have received from BlueHost, the WordPress upgrade notice that’s only visible when I log in to WordPress — every time I turn around, another of these alerts pops up, but they’re all coming at me in different contexts, and through different channels. It feels scattered and random because it is. But logically there’s just a handful of communication patterns — like event notification, assertion failure notification, and upgrade/renewal confirmation — that could be abstracted into a common interface. As services multiply, and as their management friction increases, the need will become more apparent.

1 Fixed for me, thanks to a specific intervention, but not, I observed and the BlueHost support guy confirmed, for others who wish to map arbitrary FastCGI scripts by declaring handlers in the control panel.