I was having an interesting discussion with Nick, a good friend of mine and fellow SOA professional (Nick's Blog) and he provided me the best analogy I've come across concerning SOA and modularity. Object oriented programming aficionados and old timer component proponents will often ho hum SOA modularity stating that modularity has been around since Moses wrote the Ten Commandments on two tablets. Of course the basic modularity concepts behind an object, component, or service remain intact but the devil is in the details so here is the analogy.
A traditional module is analogous to a jig saw puzzle piece. Modules can be assembled to deliver a product but the way they fit together is predetermined and static. This can be very useful. For example, if you want to deconstruct a product into modules, to facilitate transport (as in the Moses example), and then reassemble it at its destination ensuring it is put together exactly as it was before transport. However, jigsaw puzzle pieces are a great example of "tightly coupled" interfaces and they do not facilitate reuse.
A tangram puzzle (Tangram Definition-Wikipedia) is analogous to a SOA service (i.e.,module). Tangram pieces are "loosely coupled" and provide the flexibility to create a wide variety of products using the same pieces. This is very illustrative of composing SOA services to serve multiple business processes. Abstraction utilizing industry standards (i.e., ReST and Web Services) delivers the ability to create interface specifications that will allow for business process flexibility. Additionally, these interfaces are discoverable. This means that anyone wanting to use the "piece" can find it and understand how to use it. Abstraction and discover-ability are fundamentally what SOA adds to the age old concept of modularity. These are also the primary reason for the current buzz and investment around SOA.
Think of jigsaw as tightly-coupled and inflexible. The puzzle is built to deliver one picture just as many traditional applications (even modular ones) were built to satisfy one business process. The tangram puzzle or service "modules" are constructed with loosely-coupled interfaces to allow for business process flexibility and use in multiple business processes.
Thanks Nick. This analogy has long legs.
Coming across the Tangram analogy comes as a pleasant surprise to me because I too independently thought of it as terrific example (as opposed to the popular but crude lego blocks example) to depict SOA paradigm. Another good example could be the LED (Light emitting diodes) digit matrix for displayed numbers (digits) from 0 to 9. The LED matrix when all lit looks like digit 8. So, this means, the digital 8 subsumes (or coveres) all the digits. The LED matrix arranged such way, can be thought of as the service layer, designed in perfect elegance. If we needed to display numbers in 10's and 100's and so on, all we need to do is, place the same LED matrix adjacent to each other. (The recursiveness of counting is truly exploited here). What's more strikingly resembling with Tangram is that the LED matrix is also composed of 7 LED's! (I begin to think if number 7 has magical qualities :)
The point here to note is that both in Tangram puzzle or the LED matrix example, there is an 'optimal' use of fundamental building blocks (SOA services) (7 geometrical pieces or 7 LEDs). The square cardboard for Tangram is 'optimally decomposed' into limited and minimal number of geometrical pieces or the minimal number of LED's. Yet compositely, they can so economically generate and fulfil the goals they have been designed for.
Another aspect to notice is that, both in Tangram puzzle and the LED digit matrix, the output generated is more of an approximation of shapes or numbers. The forms generated are more of an abstract style than their precise and perfect forms. One has to be a bit creative to find out a resemblance between the figures generated by Tangram and the actual real world figures they represent. So, it looks like in a true SOA paradigm, to achieve maximum flexibility/adaptability and output in terms of minimal underlying services that support them, it may be required that the business processes accomodate for some sort of approximation. However, I am not yet sure what this approxmation would be translated into in business domain. There could be many factors that might serve a business goal better when approximated.
Extending the idea of LED matrix displaying digits, the LCD screen of TVs or computer monitors is not a good example of SOA because the decomposition is microspcopic (millions of pixels to be orchestrated leading to high cost factor and managibility needs). True, the clarity is close to real world, however, the design, though uniform (as in lego blocks), is not elegant and optimized. The magic of SOA can be truly realized when it matches the design of Tangram or LED matrix example.
As a final note, I think, Tangram serves as a better example to understand the essence of SOA compared to the LED example, because the geometrical pieces decomposed of a square piece of cardboard (analogously, the technology infrastructure) are not all uniform but of differnt shapes and sizes. In reality, for the best design, the services cannot always afford to be unform (just like array of clones). For maximum efficiency of design and support, they need to be disparate or uneven at times for situational advantages (just as in the case of chessmen).
Posted by: Anuruddha | May 09, 2007 at 01:46 AM