I have been asked several times recently why we went our own way, away from the standard packaged “Enterprise Energy Management Systems” A few posts ago, I wrote how energy management systems have been pitched to owners and operators.
I still have my response to the salesman’s follow-up email. The vendors name has been removed, well partly out of politeness, but really because, it could have been almost any building automation system vendor, and any presentation – including a few I heard pitched in Chicago three weeks ago.
Dear xxxxxxx,
Your letter tap-dances around the fundamental issue that your system is *not* designed as we have indicated. Please show us the favor of not talking around that. Java does not make something open. ODBC access to pre-digested data does not make something open.
Having said that, your system does provide many very interesting features, features that we have already worked long and hard to get with our current system and includes some that the Energy side of the house really likes. I am positive that with a good deal of work, we could get what we already have. It may be entirely possible that with some small amount of additional effort, we can get beyond that to something marginally better.
The unfortunate truth is that we are already have a system, it does many of the same things, and the likelihood of changing in mid-generation is slim. The system we will change to is one that qualitatively changes and advances the way we can access building systems operating data. This is only going to be achieved by allowing direct unfiltered, un-aggregated access to local data.
We feel quite strongly that this will be achieved when local, shall we say "floor-level" controllers can be accessed as a standard web service. As a term of art, a Web service is "a collection of functions that are packaged as a single entity and published to the network for use by other programs. Web services are building blocks for creating open distributed systems, and allow companies and individuals to quickly and cheaply make their digital assets available worldwide."
We are certain, that Web Services are defined in terms of XML and SOAP (http://www.w3.org/TR/SOAP/) expressing standard semantics.
We are telling you, as we have been telling all vendors for the last year, if you want to show us something new, show us XML and SOAP.
When you can show us that, you will have our full and complete attention.
When you can show us that, we will be able to afford to abandon our current working system . When you can show us that, we will be able to let central admin applications compete purely on merit, something [your company] should be poised to do.
Until that time, you can only offer us marginal improvements, even if, as you have described below, you are the supreme implementation of the technology of the 90s.
I am happy to discuss this with you any time. But please do not do us both the disservice of agreeing with me for half a letter, and then describing how your system meets these requirements (architectural, as well as standards) in every way. Please re-read your own writing if you need to understand why the proposal as written is unacceptable (your note contains its own rebuttals on scaling and access). You do the evaluation of your product a disservice by doing so.
tc
I have shared this letter, with identifying information removed as it was here, with several friends in control companies. Nearly always, the first question was “It wasn’t us, was it?” The sad thing is, I could still write this same letter today, a full five years later. The standards have moved on. Some of the links may be broken. SOA (Service Oriented Architecture) based on SOAP is in place and running the business to business infrastructure of America. Standards are now in place for business transactions and business processes in XML.
But for access to operating information from embedded building control systems, for the ability to coordinate control systems with any sort of high-level directives. . . I’m still waiting.