IT Directions« Mediaeval middleware | Main | SOA Disasters Waiting To Happen »
November 13, 2007Stress-Oriented Architecture In my last post, I discussed the similarities and, more importantly, the differences between architecture of a very old-fashioned kind - mediaeval cathedral-building - and architecture of a more modern kind, namely SOA. In this post I'd like to take the analogy a little further.
Most cathedrals were built before the basic principles of physical dynamics were worked out. It was not until the 18th century that mathematical physicists such as Poisson and Cauchy developed the ideas that enabled structural engineers to predict stress patterns in a large body. Until then, architects - or master masons, as they were known - relied on knowledge handed down orally, from one guild member to another. This knowledge amounted effectively to rules of thumb, albeit highly sophisticated ones.
Hence, even the supreme achievements of mediaeval architecture were constructed without a true knowledge of what actually held the structure together. The trial and error of centuries had established that certain approaches were valid, and that these approaches scaled well. This was enough to construct masterpieces such as Chartres. But they didn't really know why it worked.
Recognizing this, the master masons took steps to ensure the safety of their structures: they employed a technique that modern engineers call "similar redundancy". Basically, they built more columns, buttresses, arches and so on than they probably needed. Similar redundancy works well if you are confident in the validity of your approach.
Skipping over the next few centuries to the modern day, engineers in fields that demand high system integrity (such as aerospace, for example) now prefer a technique called "dissimilar redundancy". This technique involves first identifying the separate functions of a system (raise the ailerons, decrease the pressure, turn on lighting, etc) - then commissioning a solution for each function from several different manufacturers, who are not permitted to discuss the matter amongst themselves at all. In this way, it is hoped that any fundamental error in one design will not be propagated into the other designs. All the designs are used together in the production system, so that each function has a main operating solution plus a number of "dissimilar" backup solutions. Dissimilar redundancy is a stronger technique than similar redundancy.
Turning to SOA, what is the relevance of this discussion? In an enterprise computing environment pre-SOA, there are generally a number of competing "sources of truth" - for example, different ERP systems, front-end operational systems, data marts, data warehouses, and so on. It is common to shield senior management from this complexity via a layer of reconciliation activity inside the organization, that attempts to understand the differences, or at least choose a set of figures for presentation to the board. Nevertheless, one can safely say that most people working on business systems - and certainly all accountants - accept that a "single source of truth" is a complete myth in enterprise life.
With SOA, this starts to change. The underlying systems are generally still there, of course, but the reconciliation is more likely to be done by IT staff than by managers and accountants, as part of the design of an SOA infrastructure. Which service do we use to present "total revenue per region per quarter" on a dashboard? Service XYZ123, from system XYZ. Or the mean result of XYZ123 and service PQR678 from system PQR. Or the median result of 10 services ... Or ...
Whatever solution is chosen, the people who really understand what to do about reconciliation (namely, managers and accountants) are out of the loop in daily working practice, even if they were involved in the initial design. Effectively, dissimilar redundancy has been dispensed with, since the new solution treats the various sources of truth not as alternative implementations, but as part of a single implementation.
Further, even similar redundancy is often dispensed with! It is quite possible to build an SOA infrastructure in which key services have no parallel implementation (running on different servers, using different middleware, etc). This is not good practice, of course, but in a large enterprise with thousands of services, it can easily happen - and if it does, a single bug in such a service could bring down your entire operation like a house of cards.
TAKE AWAY
Next week I will be delving deeper into these issues as part of my keynote speech at SOA India 2007, and how to solve them via governance techniques based on Human Interaction Management. I will also be running a workshop on the last day of the conference (you have to pay separately for this, but apparently, over 150 people have already signed up). If you're at the conference, come up and say hi.
You might also like to have a listen to the podcast that Elizabeth Book (Editor-in-Chief of ebizQ) and I just recorded, in which we discuss the latest version of the free HumanEdj, that provides software support for Human Interaction Management principles. Elizabeth writes: "I am actually about to download this thing to use in my own office". Why not follow her example? And I am always interested in your feedback - do let me know what you think.
Posted by keithhb in
Service-Orientated Architecture
|
Digg This|
Add to del.icio.us
