"XML optimization" is a shorthand reference
to optimizing business benefit through the
practical application of XML in commercial,
technology and data management
settings. With respect to Saint-Exupery's
quotation about advances in transport,
XML is not itself a transport mechanism,
but instead a means of information
containerization that makes information more "portable" and "self-describing." XML is ready to be used and is widely used, but the missing ingredient often is the doctrine as to how to apply - profitably - this containerization capability.
Most Companies Have The Essential Infrastructure
You probably have already invested in much of the necessary IT infrastructure, because XML-enabled processes can leverage your internet and intranet services and other IT assets. Although the .com era created a lot of waste, it also stimulated investment in browser access to the web, firewalls, etc., all relevant.
XML is Itself "mature" and ready to work for you
XML is not yet ten years old, and from the perspective of practical industrial use it is younger still. Nevertheless, over recent years, XML standards groups and technology suppliers have been and continue hard at work defining XML and using it to frame out processes such as "Web Services." Although more standards work needs to be done, today's priority should be to move the fruits of the XML community into effective practice, and Colts Neck Solutions LLC is very much focused on tranlating XML potential into payoff.
What are the advantages of "self-describing" data
From a general management perspective, what is important is that "self-describing data" is an advance over "non-described" or "obscured" data.
With an XML-facilitated process, as data moves, it carries with it interpretative information, often referred to as metadata - notably XML "tags." For example, a data field such as purchase order number would enclosed by descriptive beginning and end tags that clearly distinguishes and labels purchase order number.
Also, data fields do not move individually, but within larger, often standardized contexts, such as transaction-specific electronic documents. XML standardized documents are technically neutral: the XML documents generated by , say, a Unix-based system and XML generated by an MS Windows or IBM Mainframe environment will be interchangeable, presuming that all three environments were applying a standard document definition - e.g., to create a UBL (Universal Business Language) purchase order. Additionally, XML can be used not only to convey the metadata regarding data fields and transaction documents, but to convey information about the larger services and relationship context within which those documents move.
A receiving system uses XML parsers to identify XML tags as a means to locate and extract the relevant data. Generally speaking, human beings making normal use of systems do not see the XML tags or other XML artifacts, because the tags are inserted or stripped off by automated processes.
Absent use of XML, most data moves between systems as strings of data packaged in "flat files" (e.g., "gf3458sd123..."), perhaps with no field and record separators or perhaps with onl rudimentary separators. In EDI transaction documents, the data stream will include hard to discern, complex data structures - for example "repeating groups" of sets of data fields, with a value in another data field defining how many "repeats" to expect, so the data tends to be self-obscuring rather than self-describing. Even within given application systems, data may move between modules in forms that are far from "self-describing" - e.g., within SAP R/3 as iDocs (intermediate documents).
In all these non-XML cases, human beings need to engage in detailed "out of band" communications to describe the file layout and other "data about the data." Indeed, standards such as ebXML have the potential to describe rather complex services and relationships - again expressed in XML.
Therefore, XML has the potential to eliminate or at least greatly reduce the need for those discussions. Not only does this save you money, it eliminates a major choke point and repetitive busywork that is very unsatisfying for the professionals that have to do it.
Standards and Data Quality Requirements
Lunch, unfortunately, is still not free. Forethought and data discipline are both essential - e.g., tags are more useful by being standardized, certain data coding conventions need to be honored - e.g., by using ISO units of measure and various industry and multi-industry document and process standards need to be supported. Colts Neck Solutions LLC is a member of OASIS, one of the important sources of such standards.
Apart from standards conformance, what is important is that the payload data needs to be reliable. If your company sends a "bad" price or "bad" part number, no amount of XML will prevent process breakdown. There are fears - some justified - that the ease with which XML-based "web services" can be created will hit enterprises where those enterprises are weakest - in data quality, especially with respect to "fitness for purpose."
Also, as we progress toward deeper and more automated inter-entity data integration, "world-views" tend to collide, raising some challenging epistemological and ontological problems. What is "good" data in its original setting may be "bad" in a new context. Managers need to think ahead about reuse, because there is huge economic leverage in getting additional value out of information you had to collect and manage for some specific purpose.
Plan on buying bandwidth - data transmissions tend to "bulk up" because the "overhead" tags usually exceed the information payload in size. Fortunately, "brute force" computing and networking makes "bulk" affordable and practicable. (See "brute force"). Also, in many cases it will be advantageous to invest in upgrades to application packages - ERPs, etc., because although XML is technically neutral, the limited feature set or architecture of older versions may make it difficult to leverage XML in a fully competive way.
The essence of the XML value proposition is that it makes it far easier to set up data exchanges between systems. Consequently, the question to management on is "What value can your business derive given that XML helps put all sorts of data exchanges within your grasp? Note that managers of smaller enterprises do not get a "bye" on this question, because XML capabilities are becoming both ubiquitous and cheap, and your trading partners will know that fact.