I have been using the word recombinant on and off to refer to changing structures in a network environment. What we see at various levels - from organizations to schema - is growing modularization accompanied by flexible reconfiguration of those modules. Remixing and mashups have some of the same sense in current discussions. In fact, I like to think of interoperability as 'recombinant potential', the ability of services or content to be combined to meet certain ends.

Here are a couple of pieces where I have used the term:


Truth be told, I have been gently chided in some quarters for my use of this term. Too hi-falutin' by far.

However, my colleague Mike Teets has just drawn my attention to a full-page advert for Accenture in yesterday's Wall Street Journal. It is cast as an article: High performance: a modular approach in business simplifies internal processes, boosts innovation and brings sustained competetive advantage.

The article talks about modularization, reusable code and shared platforms. The argument will be familiar to some. Componentization supports flexible recombination to meet changing business needs. Additionally, shared platforms reduce the complexity and cost of development by making common functionality available in multiple development environments. We are becoming familiar with this pattern as we see the functionality provided by Google Maps, eBay or Amazon Web Services used to accelerate the development of other applications.

Accenture talks about three steps companies are taking in this direction:

First, these companies embrace "recombinant modularity," breaking their offerings, processes and technologies down into components and platforms that form the basis of extensive lowcost reuse. "Like Volkswagen, and numerous other companies in industries ranging from consumer electronics to consumer packaged goods, firms are converting their businesses into reusable components and platforms and recombining these into new offerings," observes Paul Nunes, an executive research fellow at the Accenture Institute for High Performance Business in Wellesley, Mass. The advantages of this approach are greater agility and flexibility, and a greater ability to help the business evolve. [Accenture High Performance Archive]
The second stage is acclerated recombination into new products using this 'design once, build once' approach. Unfortunately, the article cites Lego as an example here: that seems too easy ;-) And third, "successful companies carefully choose the right combinations of these reusable modules based on an understanding of their distinctive capabilities".

The Boeing example is interesting:

Boeing Co., the largest manufacturer of commercial jetliners and military aircraft, based in Chicago, has resolutely embraced modularity in both its products and its processes to simplify its business and accelerate innovation.
This began with reducing the complexity of the design and production process of an aircraft by reducing the airplane to common modules such as flight control systems and avionics.
Using this modular product architecture, the company has effectively reengineered its aircraft to share key components.
Boeing has since taken its modular approach to the next level, redesigning and standardizing components of the manufacturing process. An example is the advanced lean-manufacturing technique the company has implemented to build the wings and aft fuselage for the U.S. Air Force's nextgeneration F/A-22 Raptor fighter aircraft. [Accenture High Performance Archive]
There are many ways in which this is relevant to current library discussions. Here are three points from one perspective.
  • Modularity and what we have now. We are clearly moving to greater modularity with current systems, as APIs and protocol-based interfaces become more common. However, as current discussions about the catalog and ILS show, we are some way away from the flexible recombinance that is being talked about above. Moving data between systems, exposing functionality as web services to other applications, uncoupling the library discovery experience from the ILS: these are not straightforward. And this means that library services play less well in a web environment than they might.
  • Modularity and where we are going. Reusable components depend on agreement about desirable shared functionality. As we move forward, there are many places where we do not yet have the level of agreement needed to develop substitutable components, agreed interfaces, or shared services, which in turn drive the ability to quickly develop locally responsive applications. Think of the discussion around repository interfaces (how do move content in and out of repositories in consistent programmatic ways), electronic resource managment, metasearch, disclosure to search engines, and so on. Much of the complexity of current digital library development is because of lack of reusable work - models, code, services. On the positive side, there is a growing appreciation of how applications need to be architected as service frameworks, even where we don't have commonly agreed interfaces or commonly accepted service boundaries. And there are several intiatives which are trying to move towards a better understanding of service frameworks and models.
  • Platform services and organizational structures. We will see more platform services in the library community in coming years. By platform here I mean commonly sourced functionaility that can be shared across institutions. In coming years, these will be increasingly made available with web serices interfaces which allow them to be built into other applications. We are in an interesting intermediate stage at the moment, where we can see a direction but still have to work through what it means in practice - in technical, service and business terms.
Incidentally, service and platform are words which it is difficult to use in some conversations without qualification. General senses exist alongside more specialized senses.

Related entries:

(Update: added partial set of related entries)

Comments: 1

Jun 22, 2006
Lorcan Dempsey

Interestingly, the Loosely Coupled Glossary defines neither service nor platform.

Commenting on my own post here, as we have switched commenting back on and just checking!