The way XML has been positioned over the last several years - namely, as some type of savior for companies that have invested in myriad systems with numerous incompatible data types - it makes you wonder why organizations aren't adopting any XML solution they can get their hands on.

But for companies that have been burned once too often by the promise of the next "can't-miss" technology, it's easy to understand the reluctance many might have toward XML. Yes, it's true, XML has been a hyped technology. The question becomes, has it earned the right to hype?

A Lot to Like About XML
Let's consider why XML is being positioned as a so-called savior. The most uttered praise around XML is its adaptability - by encoding data in XML, organizations can quickly make information available in a simple and usable format, thus allowing for greater interoperability between previously incompatible systems. Also, because information content is separated from information rendering, it is much easier to provide multiple views of the same data. In short, XML is designed for data representation that is simple and easy to use.

Moreover, the attraction to XML is the ease with which it handles legacy data. This point cannot be overemphasized. After all, companies have spent years and millions of dollars developing legacy infrastructures. More often than not, these mainframe-based systems cannot "talk" to each other, so trading data becomes a frustrating exercise. The problem is, these legacy systems are often business critical.

In a perfect world, companies would rewrite their legacy applications to run natively in our increasingly Internet-centric world. Of course, in that utopian view they would also have a blank check in hand to pay for that rewriting - not to mention the considerable time to undertake such a project. But time-to-market is critical today, which is why companies are turning to XML middleware as a way to quickly transform old data for use in new applications.

It's no longer really about IT - it's about finding solutions that will solve critical business needs. Companies are grappling with a multitude of noncompatible standards - some old, some new, but almost all evolving - combined with a multiplicity of IT disciplines. This breeds frustrating complexity and, most importantly, added cost to the bottom line.

It's the Industry
Every vertical industry comes with its own set of unique challenges: everything from compliance to industry-specific standards - such as HIPAA regulations for health care - to partners who refuse to conduct business unless one can electronically "talk" in their standard. While XML may not be the panacea, it will go a long way to overcoming most of these obstacles.

Unlike most legacy data, XML is self-describing - organizations can create a more human, readable data format (as opposed to data that is solely machine readable). From a system integration point of view, that's critical. For example, take a common challenge with legacy systems that might be 20, 40, 60 years old. Instead of finding the original programmers to perform the data translation, today's data analysts perform gap analysis between different data formats using XML as the middleware layer.

Add to these horizontal issues the unique challenges native to a particular industry. Insurance companies are under constant pressure to drive down costs and streamline processes to sharpen customer focus and reach out to target markets with competitive products. Complicating the problem is the fact that these companies often own a mix of incompatible systems, applications, and databases that store information in a variety of formats, including COBOL, AL3, flat files and several proprietary data formats.

This makes automation complex and costly. But the implications are huge. After all, if a company can take a dollar off every transaction - or even 10% off every transaction - that's a huge impact on the bottom line.

Enter XML. XML adoption is becoming widespread in the insurance industry among vendors, institutions, and other organizations adopting the ACORD standards. Insurance companies are exploring ways to use ACORD forms and XML to provide a standard vocabulary to facilitate communication among business systems. For organizations that are considering ACORD forms and XML, the key is to understand how the technology works and the specific business benefits to be gained. By adopting the new standards via XML, organizations can share data with trading partners consistently, accurately, and instantaneously, as well as retain and expand customer relationships.

Compliance with industry standards is also a huge issue. Using XML, an organization can store metadata or specific data that's required for compliance in an XML repository. Also, there's a rapid movement to technology that's being developed by software companies to enable enhanced search functionality using XML.

For example, a financial organization can file budget statements in a searchable XML repository. This allows searches down to the field level or metadata tag in XML - as opposed to creating some sort of proprietary format in the database and having to deal with referential integrity. As a result, if you have specific schemas associated with select data, you can quickly get to the information.

XML has benefits in other areas, such as customer relationship management. Most CRM systems have their own proprietary formats. If an organization wants to trade information between those two systems, XML is a logical technology to allow them to "talk" to each other. Even these large software companies see the value of XML as an integration layer and are adopting Web services or adapters to the core business processes of their applications.

Once a company recognizes that XML is a viable platform for their organization, enter the next challenge: how to implement it with minimal disruption. From the outset, one of the biggest obstacles is making the decision between using a standards-based or proprietary schema. There are advantages and disadvantages to both - trade-offs, in other words. Early on, there was a tendency to go the proprietary route, simply given the nature of the standards' world: changes to standards were slow since decisions were made by committee. As a result, many organizations came out with proprietary schemas because there wasn't time to wait for a standard. But the groundswell for standards is strong, particularly since they attempt to harmonize all the hard efforts of individual companies and people to adopt comparable technologies.

Often what's needed - and this is a challenge that's outside the technical realm, but one that is just as critical - is someone within the organization to take the bull by the horns and say, "This is the direction we need to go in."

Vendor Q & A
A company looking to adopt XML should ask its vendor several questions. Most importantly, does the vendor know the industry? Companies should feel confident that the chosen vendor understands their particular business challenges - their pain - and that the technology solves that pain in an organization's particular infrastructure.

Does the vendor know the challenges of the legacy formats being presented? For example, the insurance industry often uses AL3 data and COBOL data (the EDI of insurance). While an XML or middleware vendor might position itself as having the best technology available, this won't mean anything if the vendor doesn't know how the company or its industry uses that specific data. The vendor needs to understand the business processes of the industry's data.

A challenge for any organization is recognizing the trade-off between the value of an IT solution and its price - the return on investment. An XML solution is no exception. Ultimately, the value of a solution comes down to a simple, bottom-line answer to the question: will the solution do what we require?

There are a few things an IT department should know when it comes to the technical challenges of implementing an XML solution. For one, it's important to have a solution that is not intrusive on existing systems. The old adage of "don't break something that's already working" holds true. Don't put a square peg into a round hole. Other technical challenges include ensuring that the solution is adaptable across the enterprise and that there's adequate support for integration of other solutions. After all, no application today exists in a vacuum. You should also pay attention to automation needs - being able to schedule business-process rules and automating pull-push data - and to whether the solution can scale up to your trading partners. And, of course, you can never forget about security.

A good way to get one's feet wet with XML is to start small - risk something that may not be strategic to the organization. For example, export a content management software system into XML. It's important to understand the technology - as you better understand the functionality, it becomes easier to add to it.

In the ever-changing world of business, companies are faced with the hard fact that people and their systems need to communicate in a more efficient manner. Is XML a panacea? No single technology solution will solve the entirety of an organization's business challenges. But the benefits of adopting XML - allowing improved system interoperability and greater information sharing, not to mention its potential ROI gains - will go a long way to addressing key organizational pain points. So don't necessarily consider XML a savior - but it's certainly a good, dependable friend.