SOA in the Synapses

I am most interested in the space between the large domain standards efforts, NBIMS, oBIX, GridWise, and OGC. When two areas of the brain try to interact, the action is all at the synapses. It is at the synapses that new ideas are formed, and that new actions are embarked upon.

The organizing principles of the synapses are what IT calls the architecture. We posit that we want each instance of these domains to hide their internal procedures, and offer up a surface. That surface should be defined not in terms of the underlying procedures, but as services. The architecture for linking these big domains together, then, is Service Oriented Architecture (SOA).

Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different owners. It is natural to think of one person’s needs being met by capabilities offered by someone else; or, in the world of distributed computing, one computer agent’s requirements being met by a computer agent belonging to a different owner. There is not necessarily a one-to-one correlation between needs and capabilities; the granularity of needs and capabilities vary, and any given need may require the combining of numerous capabilities while any single service may address more than one need.

SOA provides a framework for matching needs and capabilities and for combining capabilities to address those needs. The purpose of using a capability is to realize one or more real world effects. In SOA, an interaction is “an act” as opposed to “an object” and the result of an interaction is an effect (or a set/series of effects). This effect may be the return of information or the change in the state of entities that are involved in the interaction.

Under SOA, people and organizations, and in my world, embedded systems offer capabilities and act as service providers. Those who make use of services are referred to as service consumers. The service description allows prospective consumers to decide if the service is suitable for their current needs and establishes whether a consumer satisfies any requirements of the service provider.

SOA is scalable because it makes the fewest possible assumptions about the network and also minimizes any trust assumptions that are often implicitly made in smaller scale systems. The Architect who uses SOA principles is better equipped to develop systems that are scalable, evolvable and manageable.

As Don Box once said, “SOAP was designed to let computers surf the web for data the way people surf the web for eye candy." With SOA, they are able to negotiate and interact as well.

Anyone interested on SOA would do well to read the OASIS Reference Model for Service Oriented Architecture

 http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

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.

Surfaces – the kind of Abstractions I like best

My personal interests are in making each building a participant in an open market of energy sources that span a continent. (www.gridwiseac.org\) At the same time, within a building (or campus) there might be mix of energy generation (PV, wind, Stirling Engine,..) and energy storage (Battery, Hydrogen, water pools, …) systems.

The complexity of such systems is impossible to manage, or orchestrate, or choreograph unless it is hidden behind abstract interfaces. If they are all tied into one tight control system, then we have created a realm wherein the producer of each system cannot be held accountable for performance. We also create a rigid system wherein individual system failures lead to cascading failures rather than simple degradation of overall performance. This means that I want abstract interfaces even between systems in the same building.

With these abstract interfaces in place, one could add new systems as new technologies become available. I can swap in substitute systems without re-programming the others. This intensifies competition between these large systems by reducing the friction on the transaction of switching from one to another in an existing facility.

If we make these abstract interfaces discoverable, the we can easily imagine a competitive market of agents that can find and interact with these building systems as well as with the business processes (or life preferences, if in a home) of the building inhabitants. Those agents could interact with the power grid and live energy pricing on the basis of a single building. As the abstraction level grows, the agent could be located outside the building, to bid aggregate power use for an industrial combine, or for a portfolio of homes with either similar desires (I want all wind power. I want a carbon-neutral mix. I want the cheapest power available.) or complimentary power use patterns.

In other words, I want to place Intelligent Buildings as fully actualized agents on an Intelligent Grid. To do that, I hope to leverage Building Intelligence (NBIMS) to discover abstract interfaces to the point-by-point complexity of the underlying control systems. Rather than create these abstract interfaces from scratch, I had hoped that the pre-existing interfaces between the Building Model and Energy Models would be a good starting point. By doing so, I hope to avoid the complexity of introducing Yet Another Acronym and Yet Another Interface, thereby avoid increasing complexity.

Abstract interfaces that hide rather than reveal complexity are the key. Here is an example from within oBIX discussions. When we discussed abstract interfaces for scheduling, each control system developer quickly claimed that “scheduling systems are quite complex, and there are no agreed standards.” Spirited discussions ensued about factoring how long it takes to air condition a room in advance. Should we factor in humidity. and on. and on. But there is already a standard for scheduling. We each receive ICAL invitations to each NBIMS event. It is a W3 specification. Our own systems know how to adjust for where we are in the world, including such local oddities as when Daylight Savings Time begins. Each of us considers whether we have to drive to the meeting, or fly, or simply be near a phone. Those details are not the concern of the interface but of each of us and the complex systems we represent. I want to simply invite the conference room or class room to an event on a certain date, with a certain number of attendees anticipated.

If these questions are answered correctly, they expand the value of capital assets by extending their ability to provide services and amenities to the owners and tenants, not merely to avoid costs. An Energy Model consists of Envelope, Weather, and System Operations. An abstract interface that works for energy modeling could be re-usable in tuning System Operations in response to Weather Predictions to improve quality of service provided. It becomes the basis for external system analytics to enable predictive maintenance and thereby economically provide enhanced reliability.

Adding Service Orientation to Large Semantic Projects

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?