System Architecture

Biological Patterns for Systems Control

Last weekend, Fred Hapgood blogged at CIO magazine about network management and monitoring. He described how current models are hitting a wall of complexity and numbers. Conventional networks, and particularly their management, do not scale gracefully. As networks get larger and more complex their management problems will keep get more difficult even faster and the time scales for solving problems get smaller.

Hapgood points out in his blog that many researchers are now looking toward biological models for management and control. Biology is rich with large networks—protein cascades, gene switching networks, intercellular networks, nervous systems, and whole ecosystems that efficiently organize a large number of unreliable and dynamically changing components. These networks manifest adaptive and robust behaviors, despite the lack of any central management. This robustness and tolerance of diversity is in sharp contrast with man-made networks despite embracing far more individual variation among its nodes.

Hapgood went on to cite recent work primarily from the University of Bologna that tried to develop taxonomy of the modes of biological signaling and how they might apply to intra-node network communications and control. These modes of communications handle increase and loss of nodes well; more important, they degrade well, providing reduced functionality rather than failure. Fred was kind enough to share the paper with me (and I have placed it here).

The paper classifies biological signaling patterns into plain diffusion, reaction-diffusion, proliferation, and stigmergy. It goes on to consider biological entities as instances of object oriented design; and the signals as design patterns. Through simulations and modeling, they demonstrate effective and performant control of large systems. I would have liked the authors to reach for one more abstraction, to consider invoking these patterns in aspect oriented design. It is a fascinating and useful article.

Austrian school economics and developmental biology have long swapped concepts and vocabulary to describe the development and behavior of as complex adaptive systems. I think we are, as Fred suggests, beginning to recognize networked engineered systems as complex adaptive systems with the capability for their own emergent behaviors.

Complex adaptive systems have large numbers of diverse agents that interact. Each agent reacts to the actions of the other agents and to changes in environment. Agents are autonomous, using distributed control and decentralized decision making. Eventually, the dominant interaction becomes the agents interacting with the system environment that was itself created by the agents’ own independent decision making.

In economics, we call the order that arises out of markets emergent self organization. In biology, we call it embryology. In either case, a large scale pattern emerges out of the smaller decisions and interactions. The emergent pattern is not imposed top-down, but rather arises from decentralized agents interacting within bounds of distributed control (or self control if you will).

A characteristic of meta-systems (or systems of systems) that demonstrate self organization is resilience in the face of change, what the economists call adaptive capacity. Market design theory, in the news this week with a new Nobel Prize, is in part concerned with ensuring adaptive capacity.

We are just beginning to apply the concepts of biology and markets to aggregates of engineered systems. In nature, systems that have too many direct interactions become brittle, and break badly. The Cleveland Outage of 2001 could be described as such a shattering, with the cracks extending into Canada and the East Coast. Less control and more heterogeneity in agents may be what we need to acquire resilience in our engineered systems.

EBMS – Bringing the EBMS Project to life

This post continues a series about a particular large system at UNC

It is said, you go to war with the Army you have, not the Army you want. And you go to bid with the contractors you have, not the contractors you want. And you specify the technologies the market has, not the technologies you want. And we had to buy the Enterprise Building Management System (EBMS) we could rather than the one we wanted.

When we were finalizing the specification for the EBMS, Web Services was all the buzz among control vendors. Many vendors demonstrated SOAP-based building gateways to us – but the product never quite had a part number. Standards were non-existent. oBIX was not yet even a committee draft. The BACnet-WS committee had not begun to meet.

Administrative IT at Universities is always behind the times. The culture that cherishes and maintains Old East, the first State University building, preserves and protects old business processes as well. Our CIO had pronounced a year before that he was pretty sure that XML was a fad, and he knew Web Services were a fad, and we were to let none of that stuff in here. We needed innovation; we needed to push the building controls industry. Such efforts require very clear communication. We went to bid with a document that never once mentioned Service Oriented Architecture, or Web Services.

Building system contracts are traditionally managed as construction projects. UNC is a state agency. State construction projects rely on a very structured business process producing very predictable results. Because we were breaking new ground, we needed to contract for performance, not design. Performance contracting is not part of the normal process in the North Carolina State Construction Office.

State construction did not know what to do with this project. Our creative and resourceful energy manager, Jay Evans, continued to fight for EBMS. At one point, we actually received a suggestion to bid a small portion of the project and do most of the work on change orders; Jay rejected that approach and kept pushing. Finally, State Construction agreed that we could run a controls project through the State IT business process; SIPS supported an RFP / performance based project cycle.

So it began. All communications outside the building were going to be XML based, but no standard was specified. All Monitoring and Operation was going to be from a single web-based system. All graphics were going to be vector based, so every page could display on any device, and scale as needed from large screen to small. (And this worked – I’ve already seen our system operated from an iPhone).

Fortunately, every group associated with the final team approached the project as partners. An example of this occurred about six months in. To preserve legacy systems until the next building renovation, we were placing special purpose gateways in front of the existing building systems. The subcontractor installing these gateways, Yamas, was using the only solution available at bid time: a proof of concept web services engine available from Tridium. oBIX had become a committee draft, and was sliding into the slow process of OASIS Committee Standard approval. Based on a Phone call, Tridium agreed to re-write their gateways around oBIX and deliver us the newer product based on the standard. Yamas agreed to accept later delivery and still meet their delivery schedule to provide us a standards-based solution. Cyrus Technologies promptly agreed to revamp their development work our standards-based vision. All willingly cooperated as a team to deliver the innovative standards based solution we wanted.

One last system hurdle rose up in our path – standards-based XML graphics. When we launched the project, SVG (Scalable Vector Graphics) – a vector-based W3 standard - seemed the clear choice. During the project, the market leader in SVG tools and rendering bought a market leader in a competing technology; Adobe abandoned SVG after it acquired Flash. We had to scramble and switch to XAML. I am not entirely happy with that change, but that was the way the market developed. On the bright side, there are some DWG/XAML converters, so it looks like we will be able to bring our AutoCAD floor plans into EBMS.

Open Standards-based development is new to building systems. There will be hurdles that you do not expect. You need a team that is willing to commit to a vision. You will probably need to define a performance based project, as the road is not entirely clear. For us, the results are well worth it.

Abstract for Grid-Interop

No time to blog today - I had a deadline for the final draft of my paper for Grid-Interop. Grid-Interop is a conference presented by the GridWise Architectural Council to engage public and private electric systems stakeholders in the integration issues in creating a more efficient, reliable, and resilient electric system.

Long time readers may have noticed how hard I have struggled to lose the academic tone of voice in writing. I hated to see it come back... 

Well,here is the abstract.

True Scalability and interoperability require abstraction and security. Most control systems today expose name/value tag pairs as their interface. Interaction with exposed tag pairs requires a deep understanding of the underlying systems. Secure interaction with sets of tag pairs can only practically be exposed as monolithic yes/no decisions for the entire set. Lack of abstractions, in both process and security, are a barrier to new business interactions.

The smart grid will require integration with smart buildings and their associated power capabilities. Abstract models for system interaction will enable large-scale system integrations. Abstract service models will hide underlying system detail while exposing the diverse systems for orchestration.

Security is the application of policy to service. Situation awareness is required of any mature security model. Situation awareness is only useful when applied to abstractions above identity, above process, and above function. Only when these abstractions are defined, can one then define security.

Service abstractions and Security Abstractions must develop together. Security enables the open provision of business services. Defined services enable the definition of business policies. Service and security together enable open trustworthy interactions with third parties.

If you want find out more, see you in Albuquerque

Software Architects and Architecture (SOA 1)

I often use the word Architecture when talking about systems. I often get blank looks, or nods that are so quick that conceal a lack of understanding. This leads me to answer the question, so what do I think a systems architect does? Is an architect the senior programmer? What does an architect produce? What should programmers know about architecture?

I don't think architects are just senior developers. It's a different skill. Architects work primarily in models, patterns and process, not code. There are different process patterns that an architect can work with.

One prominent pattern is the Service. A service is a fundamental business function, stripped of process. I say stripped of process because procedures are often mere accretions of tradition. One can’t look to the procedures to see if the service is proper, or what the correct metrics should be.

Think of it this way. I am a regular customer of yours. Your shipping department provides a shipping and logistics service. Your shipping staff may be friendly, and polite. If you find out that I know every one of these friendly guys by first name, you should be concerned about the service you provide. Why do I need to call them so much? Do my shipments never arrive on time? Do I frequently need to arrange for returns of defective merchandise?

I won’t be happy if you automate this system without addressing the underlying issues. If you set your programmers to enshrine your current process in code, the service will still b bad, and you will lose the benefit of your friendly staff. If you work on improving the current processes, but select the wrong metrics, you will waste a lot of resources. All that time you spend training the process of training your shipping staff in customer service will be wasted because I still need to talk to them regularly.

Service Oriented Architecture is the discipline of finding the proper surface on each function, that is the proper interaction between that function and all others, internal or external. In a business it must be a joint process with full participation between IT and business management.

If for some reason, only one side can participate, the business manager participation is the more important of the two. A business that has defined its internal functions as services, a Service Oriented Enterprise, will always be healthier than a business that defines its internal functions as procedures, the Procedure Oriented Enterprise. As someone once said, the problem government, universities, and very large corporations is that they attract people for whom means easily become ends. It also has been said that implementing a business function as a service is trivial in Service Oriented Enterprise.

Companies that understand this quite well still get it wrong sometimes. Dell built its business using a virtual inventory and supply chain based upon solid service oriented principles. Its customers trusted it and the Dell experience. It outsourced its tech support function badly, outsourcing the process rather than the service. Its partners success metrics were process oriented rather than service oriented. Dell took a beating in customer perception.

Next: Applying Service Orientation to the world of Engineered Systems.