Picture this…It’s the 1980s and Reaganomics is in full swing.  Computer hard drives are about the size of a flash memory stick and modems are barely pushing the 14.4 envelope.  But I’m a business and I need to connect electronically to other businesses.  And I need to send them a data file that from today’s perspective hasn’t changed much in size.  But in the 80s I’m not perpetually connected to a network, and disk space, not price feasible.  Standardized connectivity, transactable messaging and security are not en vogue.  Enter the VAN market.  Someone to sit in the middle, catch and store a message from someone hold it for someone else, log it, and if they’re really ambitious transform it into something else.


Flash forward to the world of today.  Organizations are ALWAYS connected to the Internet, disk space is plentiful and connectivity speeds are lightning fast.  Standards are rapidly being adopted.  And yet VANs are still there, still sitting in the middle…and going forward, mostly costly, proprietary and redundant.  But what is the alternative?  Large organizations can’t afford to connect individually to thousands or end points using application integration technology of yesteryear.  


So how about SOA?  Coupled with rich transformation engines like found in BizTalk Server 2004, connectivity tools found in the same and the ability to express services in a service oriented architecture using web services, and now you’re talking.  Even some VANs recognize the need to do this in their own infrastructures now acting as web service hosting proxies for their customers.  How about the customers just doing these themselves?  And where there is a need for connectivity to many endpoints leverage custom application architecture or packaged application with thin or smart client architecture backed by the web services sitting on the SOA.


I’d challenge financial firms to take a hard look at their investments in their VANs of choice.  Could they accomplish the same thing with newer technology?  Look at the money spent (connection charges, storage charges, data transmission charges), and if applied elsewhere, do you end up with a more flexible infrastructure for the future?  


Thoughts leading up to a holiday weekend….