Search Archives
Why New Daedalus?

Daedalus was the mythical great architect and artificer of the classical world. Today, embedded intelligence is enabling the most profound changes in the way we create and use buildings since his day.

Building Intelligence meets the Intelligent Building. The Intelligent Building negotiates with the Intelligent Grid. How will this transform how we interact with the physical world?

More on the Web
Powered by Squarespace
« Sloppy Wet in Carolina | Looking where it is easier to see »

IT is the One Department that Can’t Afford to Miss This Boat.

A recent poster commented that IT Departments word be serious opponents to enterprise enabled building systems>

The IT groups have the least to gain and will be asked to support additional risk. Without a high level sponsor for the project, the chances of success are minimal. Even with high level support the IT department wields a lot power, they throw around support issues, delays in core responsibilities, risk and fear.

I think this is partially true.

A report that came out this week reported that Servers, PCs and network gear us 9.4% of the entire energy load of the US. A conservative estimate is that data centers use 45 billion kilowatt hours per year. I suspect that number is low because cooling is often on a different budget than the data center.

The poster continued that corporations only want to be “Green” only if it doesn’t cost appreciably more than the status quo. With $80-a-barrel oil, we will find that many data centers will soon scramble to explain their new costs. Many a data center manager will find that the cost of not integrating building systems into data center operations is larger than integrating them.

oBIX, and even BACnet Web Services, reduce the cost of integration. Certainly, there some IT shops who still do not have an architecture. Many who claim to will say something nonsensical like [database vendor] is our architecture. If we set the bar higher than that, the better IT shops are moving to some sort of Service Oriented Architecture (SOA), often based upon web services. (I must admit, though, that many are become disillusioned with SOA. These are often the ones who “bought” SOA as a product without adapting their IT business processes.) Those IT shops that have developed some experience with SOA, that is, the better IT shops, will not see as much risk.

I have worked with a data center whose first request was “Can you take all that web services and change it to SNMP.” They were definitely risk-adverse, with change being the risk they feared most. They certainly did not want to be anyone’s whipping boy, again, certainly not for embracing something new like SOA. Still, they were asking the right questions. They lived by their old fashioned network service monitor. It ran on old fashioned SNMP. By demanding that the building interfaces communicate with them in their language, they were actually embracing SOA. Shhhh – don’t tell their management.

Some of the best companies are already integrating building system operations with the enterprise. They do it with great expense, and great effort. These companies have so many facilities, and such large demands, that they cannot turn a blind eye toward them. Each site, each store that they interact with requires a custom integration. These are the companies that will leap first upon the tools for simpler integration.

IT groups fear additional responsibility for systems that are complex and outside their expertise. The disciplines and techniques of building systems are outside their experience. Inappropriate integrations may put at risk both the IT shops current responsibilities and the performance of the building systems.

The answer, then, is to not do inappropriate integrations. Let the building system be a building system. Leave the contractor or engineer responsible for the internal operations of the building system. Integrate only with the external surface of the building system. Define the surface of the building system in terms of services.

Services concentrate, rather than dilute responsibility. Services hide their internal processes and thus reduce complexity. Services imply their own metrics for measurable performance, increasing accountability. Service definitions enhance interoperability, and thus reduce the risk of technology selection. The service, not the process is the right level of integration.

The IT is the only group that by speaking out early, can mandate the building systems expose only services. It is failure to do so that will increase their risk most.

PrintView Printer Friendly Version

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>