A Better Way to Do the Monster MashBy Michael Vizard | Posted 2006-01-14 Email Print
Mashing together data and Web services can do more than just put Google Maps on your site. It might free you from dominance by software vendors.
Among hard-core Web developers and the aficionados of all things Web 2.0, there is a lot of excitement over the concept of creating new Web applications by mashing together diverse sets of data.
The most obvious instance of a mash, sometimes known as a hack, usually involves something like Google or Yahoo maps being married to a data set that can benefit from being displayed in geographical context. For example, a distributor of gasoline might want to use Google maps to display gasoline prices in a particular region as a service to its customers, or Ziff Davis, the company that publishes Baseline, might want to display where there are high concentrations of storage sales based on the demographic data it collects from subscribers.
More recently, Amazon took this mashing concept a step further by deciding to open its Alexa search index to third parties. In effect, this means that anyone can create Web applications that for a relatively nominal fee can incorporate the Amazon search engine, and then go one step further by linking that application to the Amazon e-commerce engine using Amazon's Web services platform.
By adding a little imagination, the average business could probably come up with a half-dozen or more similar concepts that leverage either publicly available data sources, such as census records, or data that their existing business partners might be willing to share across a supply chain.
None of these application concepts are particularly new, but what is new is that the barriers to creating these types of applications are diminishing rapidly. Previously, if you wanted to create an application that used geographical information, it usually meant investing in a geographical information system. Or if you wanted to have a first-class search engine, it meant licensing industrial search engine software.
The potential impact that Ajax could have on the application development backlog of the average enterprise could be nothing short of immense. This is because Ajax essentially allows departments within the organization to quickly develop a wide range of graphically rich customer-facing applications on the Web without diverting development resources from major I.T. projects that require Java or .NET developers.
And because of the nature of the way Ajax applications are updated, it introduces a more effective paradigm for managing applications because typically there is no client-side code. This means that application functionality can be added on a continuous basis, rather than today's twice-a-year version number update process.
Ajax, along with technologies such as Really Simple Syndication (RSS) and Web services, represents the full floweringafter half a decadeof the potential of XML, which gave people a self-describing, data-neutral file format. And with the advent of new applications such as Microsoft Office 12 and future upgrades to SAP, XML is well on its way to becoming the dominant file format.
Once that happens, applications will start to behave a lot more like containers for data rather than places where vendors grab hold of our data as part of some misguided effort to lock customers into their platform. XML will make it easier for customers to share information across a broad number of users, and ultimately buy a greater array of application software to leverage those core data sets.
So the next time you want to create that new application, take a look at what services on the Web already exist and how they might be leveraged using tools like Ajax. After all, anything that can cut the time it takes to develop an application is well worth investigating.Michael Vizard is editorial director of Ziff Davis Media's Enterprise Technology group. He can be reached at email@example.com.