Before we settled on our current Enterprise Building Management System at UNC, we came close to buying several off the shelf products that just could not fit us into their marketing model. We were OK with their revenue goals, large as they were, for selling their product to a campus our size. We could have made their architecture work. Their bits were already shrink-wrapped and on CD. Their products would have been a less risky buy. Somehow, they just couldn’t bring themselves to sell it.
We had a few hard and fast goals going in.
- We wanted to get low level control protocols off the enterprise backbone.
- We wanted to remove spurious interactions between the embedded systems of disparate buildings.
- We wanted to be able to orchestrate behaviors across a large campus.
- Where previously some “less important” buildings had been no cost effective to control, we wanted to extend control to all buildings. It was acceptable to have less nuanced control in simpler buildings.
We also wanted to add some new enterprise interactions that required that we be able to interact with building systems at a higher or more abstract level.
- We wanted to be able to open up direct access to reading certain kinds of information to our customers [tenants]. This requires that, say, a temperature be recognizable as a temperature and mapped to a particular space.
- We wanted to be able to expose a programmable interface to functions such as operation scheduling (not configuration) to customers.
- This required that we have a security model of services that we could map to organizational staff and responsibilities.
- We wanted to be able to compare live operational postures with live meter readings to determine how effective our energy saving modes actually were.
A few products came close to this. Enterprise Energy Management Systems consumed lower level protocols and offered user interfaces for the control room. They allowed us to define operation postures (code blue energy saving) to invoke when we needed to. They offered Web Services interaction with the enterprise so we could let enterprise developers work with them.
We just couldn’t get those vendors to sell us any product. You see, the market model we proposed didn’t fit the way they were used to selling it.
These applications were all designed with a traditional focus on The Man In The Control Room. They brought all control protocols back to the Server In The Control Room. They exposed a limited number of postures for the entire campus through their web services.
We wanted to use these applications differently. We wanted to place an “Enterprise Server” at each building. All control protocols would then never travel outside the building. The limited number of web services definitions for the campus would then be a plentiful number to use for each building. Security could then be defined for each building, rather than for the whole campus.
The vendors priced their product for one server for campus, and the price was steep. We were willing to pay a premium for our model, but not a multiplier as large as the number of buildings we had. Could we arrange some sort of site licensing, letting the vendor achieve their revenue goals for a project of this size, but letting us install the bits in multiple buildings?
The salesman would nod, frown, and have to go back to headquarters to check. In multiple visits, they would report back that they had been unable to get an answer.
Some of the large controls companies and energy companies have asked me since then why we didn’t buy their product. My only answer is, “We tried. You couldn’t find a way to let us buy it.”