<body><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar.g?targetBlogID\x3d8907963\x26blogName\x3dWS-Comments\x26publishMode\x3dPUBLISH_MODE_BLOGSPOT\x26navbarType\x3dBLUE\x26layoutType\x3dCLASSIC\x26searchRoot\x3dhttp://ws-comments.blogspot.com/search\x26blogLocale\x3den_US\x26v\x3d2\x26homepageUrl\x3dhttp://ws-comments.blogspot.com/\x26vt\x3d-792153501087690591', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>

WS-Comments

perspectives on open-source and web services

Friday, October 29, 2004

aversion to new stuff

why is it especially true in IT, where things are supposed to be constantly changing, that few people really embrace change? some developers are 'open' to change, but very few actually want to change. why do we spend hours and hours re-creating programs that do exactly what our old ones did? I've encountered a specific example that has boggled my mind...

from a sales-person for an IT product designed to handle data integration and business process management. nearly in the same breath, this person both says that their product embraces XML so much that much of their product runs off of XML-defined processes (BPML, specifically). but also bashes XML in comparison to EDI for b2b ecommerce.

they said that people went to XML and found out it was too flexible to be viable.
WTF?
now, I thought it would be in the best interest of a firm to be able to work with their data in their own way, such that they could adjust for the various demands of their business...but I guess that's not right. what we should do is have everyone use exactly the same kind of information to describe not only what, but how to display, an invoice, or a purchase order, or a Cementing Template. rather than let firms, or even industry comittees, adopt their data representations to fit their needs, we should all cling to out-dated and cryptic formats, described by either printed documents or proprietary schemas?

the flexibility of XML is its boon. if my firm needs to digitally receive price list updates from a small, non-technically-oriented vendor, we can work up an .xsd and send it to them in a matter of a few minutes. or, we could spend a few hours looking for the right EDI transaction set to use, and then bicker with them about the version, and any exceptions, oh, and yeah, they can't afford a VAN or and EDI parser. oops.

this guy was from a mega-corp that is used to dealing with mega-corps and it's obvious. this stuff is why I'm so excited about lamp5. none of these monolithic dinosaurs realize that open-source, open standards, and the internet are going to end up making the entire IS industry MORE disperse, flexible, and dynamic. it probably scares them too much that they won't control any portion of the market anymore. they will have to out-perform their competitors to keep customers. something these shops are not accustomed to.

0 Comments:

Post a Comment

<< Home