Monday, September 20, 2010

AppComms:Removing the Splints from the Octopus

AIS (Agile Integration Software) conjures up the image of information flowing freely wherever it needs to be whenever it needs to be there, aligning and merging with other information as needed by each endpoint person or application. The information is not yesterday's wilting snapshot of the world, or dusty data that has struggled and morphed through five different formats along the way. Think clean, precise, and now.

I contend that the ultimate culprit that works against AIS is the classic "Adapter," along with its cohort "standards." Now please understand that they are not equally culpable, and perhaps neither is, in the perfect world. Unfortunately, as far as I can tell, we haven't reached Utopia yet. An integration model that adopts a specific standard simply pushes the responsibility of dealing with the tough issues outside its world for someone else to handle. That's why Adapters exist; they must get data from whatever/wherever/however it is into a specific destination's requirements ("standard"). The Adapter has no visibility or responsibility to adjust to run time situations. Its job is simply to get predefined data from one application or format to another.

AppComms have a different responsibility; that is as an "application specialist" that can interact with the endpoint application or database at run time as it is instructed by the integration coordinator. Each record or block of data from that endpoint that is needed somewhere in the integrated environment is provided by the AppComm on request, and similarly, data is posted to the destination as requested. AppComms know how to auto-discover the schema for that application or data store, whatever "schema" means for that application; they know how to perform all CRUD (Create, Read, Update, Delete) operations as appropriate (or not) for the specific endpoint application; and they are responsible for generating the reusable metadata defining desired data across scenarios. The specialization of an AppComm is not for the specific instance of an application, but reusable across all instance of that system. For example, a Salesforce.com AppComm will be able to work with any configuration of Salesforce, as opposed to assuming a specific schema.


The elimination of the classic Adapter is like taking splints off an octopus. The integration coordinator can orchestrate a huge range of concurrent information flows performing all kinds of tasks. Multiple live AppComms can be coordinated to access data in an order and timing to resolve cross-application virtual relationships at run time. Imagine eliminating all those staging databases! Adapters simply can not possibly offer the same fluidity and flexibility for integration as AppComms.