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.