Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML strategies
 Robert Leftwich wrote on Fri 7/19/2002 6:57 PM EDT: > I am interested in what are the best strategies for > leveraging XML in an enterprise. I guess what Uche Ogbuji was alluding to is that XML is currently experiencing a lot of hype, and it seems that you fell for it. It is good to see that you are trying to sift through the hype, maybe we can help here. First of all, XML is like any other technology, it is just a tool to get a job done. So, the decision on whether and how to use XML should be like any other tool decision task. That means that deciding to use XML should be an architectural decision, to see if it is even an option for you, and then for each project, you would decide (along with all the other things you would be considering) whether XML is applicable in the specific situation. One method to help you in deciding whether to use XML as an architecture is an old fashioned SWOT (strengths, weaknesses, opportunities and threats) analysis. This type of analysis should point out rather quickly that you can view your systems needs as being internal or external. Actually, they could be equated to being systems you have control over, and those systems that you have no control over. This will point out what systems you can even determine if XML is an appropriate technology, or those systems that the use of XML may be imposed. Some more control criteria to consider about your specific application. Is it stand-alone, like a word processor? Does it need to share XML documents, such as a content management system or a catalog application? Another important point is that XML documents themselves are information stores containing a variable level of meta-data to that can assist in setting a context for the data stored in the document. This gradient can vary from hardly any meta-data being supplied to a vast quantity. This is where you see the concept of document vs. data purpose come into play. One hand of the gradient, you could just have a root tag and a large body of free text. At the other extreme, every text token would be inserted between a set of tags. Depending on the functionality desired from the application, your XML documents would require some amount of meta-data to be functional. There is an equilibrium established, where an application would want as much meta-data as possible, while available resources will want to minimize the amount of meta-data supplied to the XML document. Expect that over time, your application's requirements will be translated into changes in this equilibrium, resulting a need to alter the meta-data. "Change is good". BTW, this meta-data is the XML document's vocabulary. IMHO, the main value for enterprises to consider XML technology is system integration. The reason is _not_ because XML textual in nature or man-readable. As a matter of fact, the textual nature of XML makes it inefficient when compared to binary methods. Rather, a wide range of vendors have elected to provide XML support. Therefore it is becoming a popular method for inter-system communications. One problem with XML technologies is that they are not finished. So you can count on a continual commitment to feeding cash into XML activities if you elect to take that path. If you have full control over the system, you have to ask yourself, do you really need XML? At this point ISVs have been falling over each other to add XML support to their wares. They are even retrofitting ancient systems with XML interfaces. So, you may buy yourself some time and save some angst by avoiding adding XML technologies to systems that do not really need to use it. Of course you will want to keep your options open when you make this decision. If you have trading partners, system integration may drive you to use XML. If you are joining a established transactional pool, you may have no choice but to use an established XML vocabulary (such as xCBL). Even internally you may have systems, that due to fiefdoms, you will need to treat as if they were external systems. For example, ERP vendors are offering XML interfaces. Note that XML vocabulary selection is pretty much at the end of the list of things to do, after you made the commitment to spend money on XML technologies. If no vocabulary exists for your application, you can create one (just like any other data design task). If the system is internal, you/your firm may want to establish a team to design its own vocabulary. If you have trading partners with a common need, they could create a consortium to design a vocabulary. Or you can look at what is already out there and see if it can be tweaked to meet your needs. Note that none of this analysis is a hard and firm way to approach the question on when and how to use XML technologies, so please do not come back three years later and claim this strategy did not work. At the minimum it should strip some of the hype away. Regards, Ralph 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
