NBIMS, oBIX, and GridWise are large semantic projects that are hard to plug into.
I am more and more convinced that the proper concern of the systems architect is surfaces. Tell me what the interface is. Tell me how I plug into it. Tell me what I get out of it.
I think that this is what a lot of the “Open “ movements get wrong. They may provide me with all of the code to do something, but with no way to get information in or out. “Well you could write that” is not an answer for someone who also has a day job.
NBIMS has as a significant effect, if not a goal, the preservation of information over the life of a capital asset, from the earliest gleam in the eye of the initial request to the final destruction of the asset. Each snippet of information has some cost to get, and some value based upon each use. By converting each of these snippets into multi-use, we are increasing its value without increasing its cost.
The hand-off has to be in surfaces. There is significant value in each of the proprietary engines that create, say, a structural building model. Every consumer of that BM derives great benefit from a free and lively competition amongst the proprietary engine makers, to the extent they can expose the results of those engines on the surface.
This is all a long way of saying that what is not apparent to the developer of a standard of interest to the NBIMS is how to define the surface. I was taught on my last call that something called the IDM is where surfaces are defined. I still have not found the “So you want to propose an IDM” document, the one that encourages the definition of that surface. This document will be critical in bringing the whole list of standards that comes from Deke’s inquiry into the fold.
I talked to someone else who will remain nameless who wanted to bring a standard that will increase the value of a BIM by exposing it to a variety of societal and economic actors. His conversations never mentioned the IDM, nor demonstrated the way to go.
Modern systems work is defining Service Oriented Architectures, interacting with surfaces. People construct large virtual corporations around a unique choreography of external services. Components of a virtual corporation have diverging proprietary interests which make them expose only the defined surface.
And every CIO is now wondering, what does my SOA Governance look like. Whether my virtual corporation is built of internal or external services, the political as well as technical task of managing the surface interactions becomes important. A quick (although Google will reveal hundreds more) search reveals this intro to SOA Governance
http://www-128.ibm.com/developerworks/webservices/library/ws-soa-govern/
I think that at some level, NBIMS, and GridWIse AC, and oBIX need to think of thenselves as SOA Governance organizations, perhaps orchestrated by BPEL-like work flows. I think that the design/bid/construction/purchase can be thought of as a lot of a long-running transactions. I think that the structures that define the surfaces enable “optional services” that enhance the project, whether they be energy models, code reviews, or post-COBIE performance analytics. I believe we should consider whether they become transactional (I’ll have my web service call your web service) rather than static piles of data in a standard format.
I will write of GridWise AC and oBIX later, but most points translate across directly.
My proposed model for NBIMS is not a model of coexistence between a lot of data sets. It is a model of abstract interactions between services. This moves NBIMS from cost and mistake avoidance to heightened service provision. This makes Building Intelligence the enabler of Intelligent Buildings, interacting with the Intelligent Grid, negotiating with external Asset Management organizations.
Many have said, the chief barrier to implementing Service Oriented Architectures in an Organization is if the Organization itself is Procedure Oriented. The nimbleness, agility, and best practices that an SOA defines cannot be achieved if procedure trumps all; the Procedure Oriented Enterprise can only achieve a Procedure Oriented Architecture. I think we have all suffered under those in our professional lives. Service Oriented Architectures demand Service Oriented Enterprises as a precursor.
Procedures are necessary. But if we cast these large initiatives as Services, we can more easily leverage IT governance best practices while knowing how to define the process for surfaces that support plugging in new services to the capital asset. This will make it easier to bring groups to the table. This will make buildingSmart an easier sell.
Can we cast NBIM an orchestration of long-running services?