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
« Interfaces for the Power Grid | It’s all too cheap! »

It’s not Use Cases, it’s Interaction Patterns

The NIST B2G efforts so far have annoyed me like an itch I cannot quite scratch. The B2G (Building to Grid) group is trying to collect applications and use cases, to create the desiderata for the new interface standards. These are the traditional ways to characterize known systems. Certainly even distinguishing the two can be a strain, although practitioners may prefer one over the other. And yet there is that annoying itch…

This morning over coffee I realized that it is because we should be talking service instead of procedure.

One of the truisms of Service Oriented Architecture (SOA), is that it is nearly impossible to implement a SOA in a Procedure Oriented Enterprise (POE). (POA is the "antonym" of SOA, only discovered after SOA existed, in a manner similar to the term Analog Watch only being discovered once we had digital watches). It is easy, relatively, to implement SOA in an organization in which each department and each departmental system knows what its purpose is, and what its effective business metrics are. Such a well understood business can be referred to as the SOE.

A standard SOA talking point is the virtual company assembled entirely from the Services provided by others. Virtual companies are almost inherently SOEs. Many of the new markets I can imagine seem more like virtual companies than they do like the process-oriented companies that make up today’s energy markets. We should be thinking service.

We need to focus on interaction patterns, the approach at the heart of service integration in the e-commerce side of web 2.0. To enable the new markets that most of us hope can arise from these efforts, we need to shift from thinking in terms of request-response and buyer-seller-shipper interaction scenarios. The patterns we must document here go beyond simple bilateral interactions, to include multilateral, competing, atomic, causally related, and routed interactions, and should allow for any number of long-running business processes.

The new smart grid, and the new economies of Zero Net Energy Buildings (ZNE) will involve the discovery of and interaction with services. These service will be involved in energy generation, storage, and conversion. These services will be diverse and multi-party. These interactions will not be procedural.

Now that I have my head on straight, I hope to submit interaction patterns required for new energy markets soon. But I thought I would give everyone a heads up on what I think is the real task.

PrintView Printer Friendly Version

Reader Comments (2)

Perhaps I am showing my non-IT-background ignorance, but I think this is a false dichotomy. A use case is nothing more than an illustration of a transaction (to an economist like me). You can use a use case to lead you to expand on interaction patterns, right? Just like you can use a use case to lay out a process-oriented design.

Process and interaction are different things, but I don't think they are mutually exclusive.

August 26, 2008 | Unregistered CommenterLynne

Very true, Lynne.

At some level, all of these things are indistinguishable. And yet, while a chemist repeating an experiment and cook replicating a dish are doing the same thing, they come from different directions and have different criteria for success....

August 26, 2008 | Registered CommenterToby Considine

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>