[
Lists Home |
Date Index |
Thread Index
]
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
|
