Infinite Diversity in Infinite Combinations

To continue to build on my earlier post "Revolutions in Computing Affairs", let's look at  a paper published in IEEE Software in late 1995 titled "Architectural Mismatch or, Why it's hard to build systems out of existing parts".  "Architectural mismatch", as the authors of the paper define it, can be of two types: 1) low-level problems of interoperability, such as incompatibilities in programming languages, operating platforms, or database schemas or 2) the much harder problem concerning invalid assumptions a reusable component makes about the structure of the software system it is being integrated with. These assumptions are more than often implicit in the design of the system resulting in tightly-coupled monolithic applications. As a case study, the authors put in about 5 person-years of effort to attempt to build a system using an OODB, a UI Toolkit and an Event based implicit invocation component. They encountered several problems such as excessive code size, poor performance of the integrated system, the need to modify the external packages, need to re-invent existing functions and unnecessarily complicated tools. Based on these problems, the authors identify four main categories of architectural mismatch:

1. Assumptions about the nature of the components, specifically, the underlying infrastructure, control model and the data model.
2. Assumptions about the nature of the connectors, specifically, the protocols and their data model
3. Assumptions about the global architectural structure
4. Assumptions about the construction process

Fast forward a decade later to 2006. A casual survey of the software landscape tells us that these types of problems still exist and building large-scale software systems using COTS components still remains a hard problem. What we do see a leap or a revolution in concerns the adoption of what's dubbed as "Web 2.0". De-composing systems, data encapsulation and loosely coupled components are not new ideas (in fact they're often attributed to D.L. Parnas' seminary 1972 paper "On the Criteria To Be Used in Decomposing Systems into Modules"). SOA, Web Services, SaaS (Software as a Service), etc., all follow architectural principles that make avoiding "mismatch" easier, hence the plethora of "mashed-up" applications all around. IMHO, Web 2.0 avoids the problems outlined above. Consider:

1. Assumptions about the nature of the components: this becomes largely irrelavant. An engineer "mashing-up" services could care less about the underlying infrastructure of Flickr or MapQuest or whatever.
2. Assumptions about the nature of the connectors specifically the protocols and the data model are still relevant, but again Web 2.0 "standards" such as Microformats, JSON or even plain "old" XML over protocols such as HTTP make these assumptions more explicit and commonly understood.
3. Assumptions about the global architectural structure: One word: WWW
4. Assumptions about the construction process and tools also become secondary in Web2.0.

Whether this constitutes a real revolution in computing, only time will tell (check back a decade later :)  )

|  Add to del.icio.us |  digg this