Abstract, yes, but which abstractions…

Building systems do not often produce useful information because they usually serve up concrete data, not abstract information.

Data is that annoying stream of consciousness woman who sat next to you on the bus. “Now my arm itches. Look at that girls over there; didja ever see a dress like that. I have something in my shoe. That man is looking at me funny. My nose itches. I hope I don’t miss my stop. I wonder if the fish at the store will be fresh. The fish last week was not fresh. My bra is uncomfortable.”  You really can’t do much with data, unless you know a lot about its source.

Information conveys something that is actionable. This means that all of the background details have been stripped away and you are presented with something simple, something that offers a choice.

Right now, there is great concern about information and choice about energy as a matter of national policy. Many measures are being presented as the basis for policy and law. Social and editorial arguments are being made about metrics and information. One element I am thinking of is, is fleet mileage and miles per gallon (MPG).

Richard Larrick and Jack Soll have just published a study of decision making using the MPG standard on cars. They have concluded that when presented with multiple choices, people usually make the wrong one when presented with MPG, and indicate that people would make much better decisions if presented with GPM, (or perhaps Gallons per 100 Miles).

You see, if we can move 10% of our automobile fleet driving SUVs from 12 MPG to 14 MPG, we will have a much greater effect on total gas used than if we move a different 10% of our fleet from 38 MPG to 44 MPG, assuming both segments drive the same miles. My readers are a numerate bunch – do the math; it is bet to upgrade the least efficient vehicles. People presented the same information expressed in terms of Gallons per 100 miles, have a much greater tendency to make the correct choice.

Now if everyone switched to driving 44 MPG cars, it might be better still, but that is not likely to happen. The people who sneer at hybrid SUVs may be off the mark, because there may be a lot more value for society in hybrid SUVs than there is in hybrid coupes.

Even though it grieves me, as a Carolina boy citing work from economists at the Fuqua School of Business at Duke, I recommend checking out the article in the June 20 issue of Science.

Regular readers know that I am interested in developing simple numbers to represent building performance and service provision. This study provides a caution. Even if we get the variables correct, deciding which is the numerator, and which the denominator may be critical…

Decomposing Services

I had a very nice conversation with Bob Smith of Tall Trees yesterday about building services. Bob is one of my co-conspirators launching the Building Service Performance ONTOLOG group. Bob had just submitted the laundry list of check-offs developed by the City of Irvine for its construction process to the ONTOLOG discussion.

I was both happy and disturbed to receive this document. These check-offs clearly drive the contracting process, They are also inherently backward looking, enshrining the best practices of yesterday as we move forward. The best practices of yesterday are better than the normal practices of today, but can be the enemy of better practices going forward. They trade innovation for good enough.

The ONTOLOG (just google it) project is to define an ontology of Building Service Performance. The problem we are trying to resolve is that while people want specific services from their buildings, we always specify technologies or systems, which is something quite different. Buildings may be providing alert students, productive office workers, or regulated environments to store labile chemicals. By discussing the services rather than the systems, we can

• Allow earlier discussion of / decisions on building goals in keeping with buildingSmart approaches
• Move conversations about building performance to the business level where commercial building owners will get interested (we want to provide healthy office space metrics in the upper quartile while staying within energy use goals).
• Commissioning then gets re-defined in terms of service performance effectiveness rather than in terms of system operations, a much more useful measurement.
• Commissioning numbers that look like B are simple enough to get built in to the sales and leasing processes for commercial buildings, enabling owners to monetize improved performance.

Check off lists such as Bob provided are the opposite of this approach. Nonetheless, I agreed to try to dig up two other documents that are contrary to the goals and thinking of the new group.

One such document is the original list of nearly 50 vertical control system markets that we came up with as oBIX was launching. These systems are specified in buildings now, but only rarely with any sort performance or business deliverable tied to them.

The other document I am trying to come up with is a comprehensive list of ICC (International Codes Council) domains. It struck us during conversation that many of the ICC areas deal with avoiding the failure to perform these services. While we are trying to twist these services around into a new ontology, a list of all the services which must not fail to be provided would be useful.

I have found neither list yet. If you think you have one, please send it along.

It's about Growing Up

I have recently gotten a few letters from advocates for one of the many fine existing standards protesting that are already several fine protocols (in each domain) and all we have to do is wrap them in a “ web-service oriented API” and we are done. I think this is fundamentally wrong.

The established control protocols are too detailed. This makes them both too powerful to let into the open, and too difficult to use. An enterprise interface should not require its consumers to have extensive domain-specific knowledge about its inner workings.

Using them for enterprise interactions is far too much like planning an outing with small children. Say one wants to go to the lake:

OK kids, put on your shoes. Katy, where are your shoes. No, those are your Sunday shoes. Margot, you have to use shoes that match. Are your water shoes where you left them on the porch last week? (There’s that domain specific knowledge requirement!) Did anyone pack the sun-screen? Do not sit on the couch to put on sun screen. (Experience as a requestor and knowing, alas, where most of the sun screen will end up) Who put the dog in the car - -dogs are not allowed.

And so it goes.

Instead plan the same trip with some adult friends:

I’ll come by at 7:30 tomorrow. Can you bring the beer? See you then.

I am delighted that the lower level protocols exist. We will always need them to do what they do now. I just don’t want to be required to oversee someone else’s toddlers.

Interface for Enterprise systems need to be abstract, need to occult details, need to reveal surfaces only. Interfaces for internet-scale systems need to be abstract, support appropriate security, defend their mission, and focus on service rather than procedure.

I don’t hate children. I love playing with my own. I even love, for brief periods, playing with those of others. But when I want to get something done, I want to talk to grown-ups.