Re: Am sure we agree, issue is the question

Post #41,711 by dmarker2 6/9/02 3:35:26 AM Reply	Re: Am sure we agree, issue is the question It is being said that parts of IT as we know it could be obsoleted but we have heard this story very strongly since OOT was introduced but it just hasn't happened. Am sure we all recall the threat of the early 1990s when as a result of emrging global peace, IT development would move to India, Russia & China - that is happening but hasn't impacted us that I am aware of. Refering to the analogy of Containerization - that sure changed the business of shipping goods. So if XML & Web Services live up to some of the claims, then IT could change dramatically. Applications licensed by subscription from specialst solution crafters. If that takes off, who knows. I understand though, that there is a great desire on the part of business to get IT out of the loop as much as possible when it comes to quickly crafting business process that can use IT. I know that what is really being said is that roles will change (as they have done over the past 30 years) and the question is likely to be who fits where. Are business analysts who get better & more automated tools for crafting solutions from IT components (such as Web Services) part of a new IT or are they not ?. I think the points you are making are really a debate on the potential for where who belongs. The issue with IT has become crafting processes that suit the business, not adapting the business to suit IT - this is where I see the challenge to IT from aggregations of Web Services. Cheers Doug
Post #41,802 by ben_tilly 6/10/02 7:57:15 AM Reply	XML can't kill IT My sanity check for XML killing IT is this, Does this technology involve sufficient complexity and sufficient hidden consequences that becoming an effective user of it is a full-time skill? The answer is yes. In that case the "priesthood" that masters the technology will de-facto be IT. IT with a different skillset than today, but IT nonetheless because they have to put enough into their craft that that is their primary skill, not the business. This is as opposed to business analysts who may understand many technologies very well, but for whom that is not their primary skill. As for the impact that XML will have on the world, I don't know what that will be like. But I suspect that it will be less than the hype has it. Why? Very simply because XML requires all parties involved to look at the same numbers, label them the same way, and think of them the same way. That works very well in a homogenous business, or if a small number of suppliers dominate a vertical market. But it stops working so well where different industries have to interface. And it runs counter to how competition in business proceeds. A often missed fact is that businesses generally avoid competing head-on. Instead they attempt to define themselves a currently unoccupied niche, and then aim to expand the impact of that niche. What that means is that if you find a thousand different businesses, they will be trying to do a thousand different things. What is more, even ones that are very similar will be attempting to differentiating themselves, and their top management will generally have a pretty good idea of how they are trying to distinguish themselves from various nearby competitors. What this means is that attempts to homogenize how businesses interact with each other run counter to the businesses real need to each be different. Of course there are huge savings in transaction costs in being homogeneous, so businesses walk a fine line between what to be homogenous on, and what to not be. But the closer you get to the core business processes, the more they each need to be different. (Which is one of the fundamental reasons that most of the software development done in this world is in-house - and why that will remain the case.) To the extent that XML allows businesses to interact in their own customized ways, it will have an impact. But that impact will be coupled with more and more custom work as it moves from the current low-hanging fruit (ie stuff that is easily homogenized) to smaller and smaller niches. And that coupling will mean that somehow the incremental win from its incremental growth never quite meets the old projections, and never quite achieves the overall impact that boosters believed it would. At least that is my take, as a non-booster... Cheers, Ben "... I couldn't see how anyone could be educated by this self-propagating system in which people pass exams, teach others to pass exams, but nobody knows anything." --Richard Feynman
Post #41,805 by dmarker2 6/10/02 8:33:20 AM Reply	Re: I am sure that is agreed (?) Andy Grygus posted a sanity check a few days back about what was going to kill what & whilst the question can be raised, I go along with the view that not a lot is likely to change as a result of XML & Web Services, but, one point I was trying to raise, was the containerization changed shipping of goods beyond recognition, I raise the spectre of if XML & Web Services might be to IT what containerization was to shipping. Of course the reality will always be that even if change comes, we all change titles & shuffle chairs & learn new buzwords. That then becomes an additional proof of change :-) Cheers Doug
Post #41,817 by Andrew Grygus 6/10/02 11:13:02 AM Reply	To quote one writer on the subject . . "XML isn't even a language, it's a syntax." XML doesn't do one thing to simplify the business logic used by companies or to make their processes more similar or compatible. It does provide a common syntax they can use as a basis for communicating with each other, and that's a giant step. Extremely important is that software developers are starting to integrate XML into their systems so the systems themselves have some understanding of the new syntax. This will greatly decrease the cost of implementing XML interfaces - to where companies can actually afford to do it (providing IT employment opportunities that do not now exist). Traditional EDI entirely failed to do this. While a number of my clients sell primarly to large retailers that demand EDI, only one, the largest, has made any attempt to integrate an EDI interface with their internal system, or could afford to. The rest hand enter invoices and shipping documents into the interface provided by an EDI network / translation service, and hand enter purchase orders received as email from that service. Sometimes it takes more than one service because none of them handles all forms for all retailers. Bosses, of course, have extrapolated the hype to believe their receiving clerks will be able to set up XML interfaces with their supply chain using Microsoft Office (an impression Microsoft has done nothing to discourage) and the shipping clerks can handle the customer interface. This is actually a good thing - because if bosses didn't believe this sort of crap, they'd never start the projects. [link\|http://www.aaxnet.com\|AAx]
Post #41,820 by orion 6/10/02 11:33:09 AM Reply	XML is a container for content which can be used to exchange information/data from one application or company to another. HTML is more for presentations, XML is more for content. Or so I think I know it as such? *I am free now, to choose my own destiny.*
Post #41,922 by dmarker2 6/11/02 9:33:05 AM 6/11/02 10:37:28 AM Reply	Re: XML is ... Some of the definitions (I was hoping it wouldn't come to this) a tag based meta-language for creating other languages. The use of a DTD or Schema allows derived languages to be defined. The DTD or Schema is used to define the TAGs that are permitted in the sub-language. XHTML is a classic implementation of an XML derive language. What is so great about XHTML - it can be modified (for different display devices) in flight, by XSL (another XML derived technology). XML allows the creation of self describing data. Self describing data offers significant benefit in being used to pass documents and messages among otherwise incompatible systems. XML Tags allow XML <ELEMENTS> to be better identified when a document is searched for its content. This is near to impossible with EDI documents in their transmitted form as it is with messages passed between CORBA, DCOM & RMI. The concept (like a cargo container) is incredibly simple but its simplicity doesn't mean the impact will not be dramatic (as was containerization). XML is the same. What is driving 'needs' for XML. It is the need for a simple but powerful mechanisim that can be integrated into existing systems (EAI & Legacy) but can also support entirely new concepts like Web Services, ebXML. XML Query etc: etc: etc: etc:. XML is human readable but XML derivative standards support the ability to handle encryption. XML can support encryption of <ELEMENTS> and it is entirely possible for each <ELEMENT> to use a different encryption approach. So, one might ask, what is the big about being human readable ? - this ability opens the pandora's box of discovery !. Discovery of content, one of the greatest inhibitors in analysing and exploiting data in information systems. Yes, there is a price, (lack of data compression) but already hardware vendors are developing intelligent routers capable of compressing XML in transit without losing its 'visibility'. XML has derivative standards that support non-repudiation. An essential ingredient for electronic document exchange. XML has a concept (Global DOCID) that supports a unique document ID for each any every document that chooses to employ it. This offers significant benefits in managing XML based documents that travel globally. And that need to be traced to their origins. Web Services is a concept derived from XML and thus harnesses the significant benefits already recognised in the technology. Web Services allows the concept of 'COLLABORATIVE COMPUTING' which is the next logical step in the evolution of computing use. In essence it is computung that spans computers and is technology agnostic. Web Services does this. CORBA DCOM & RMI (as methods of linking computing) arent & can't. Web Services can do one other extremely important trick that CORBA, DCOM & RMI can't. Becaues of XML and WSDL, They can be bound to in real time. The other middleware technologies have to be bound together at compile time (this seems to be so lost on many people who criticze the Web Service concept). This 'trick' gives Web Services its magic and like XML human readability, opens a pandora's box of potential that proprietary & non web scalable technologies (CORBA etc:) can never rise to. Web Services can be said to be the forunner of a 'plug and play' solutions capability. This is where the benefits can be passed to business. If businesses can create solutions by real-time & dynamic binding of services using business flow languages then the world of business & IT has move substantially forward. IN DEFENCE of CORBA etc: But there are applications where proprietary technologies like CORBA etc: offer value that Web Services can't (yet). Some today say the the next big Wave will be 'GRID' computing and for that to make sense, Web Services need to proceed as it will, down its evolutionary path. No doubt some people have no view whatsoever of computer evolution just as some shippers might never have grasped the benefits of containerization. Brings to mind the famous British story of when King Canute (11th century) sought to teach some of his aides how not even the King of Scandanavia and England could command the tide to turn back. Darwin taught us some powerful principles in his oragins of the species. XML standards are driven by the W3C (WWW Consortium) [link\|http://www.w3c.org/\|W3c web site] Its a damned shame the above web site is so academic and boring if it wasn't them maybe many more people would read the details. W3C has defined a \ufffdfamily\ufffd of XML related technologies ... (just a few here) XML, XHTML, DTD, XML Schema, XML Query, XSL, XSLT, XML Path, XLL, etc:, etc:, etc:. XSL is a topic in its own right. All and more can be read at the link provided. Cheers - Doug Marker #1 added more detail Edited by dmarker2 June 11, 2002, 10:21:57 AM EDT Edited by dmarker2 June 11, 2002, 10:25:52 AM EDT Edited by dmarker2 June 11, 2002, 10:37:28 AM EDT Expand All History
Post #42,021 by Ashton 6/11/02 8:48:46 PM Reply	Gracias. Or in the most recent Prince Valiant comic strip wherein, to pay back a debt, the 'Rus' are offered two choices: 1) Guidance to the (hardly molested) Lost City of Alexander the Great - an artifact (and other) mine of unimaginable value.. OR 2) Instruction in The Alphabet (even pitched positively as "the larger of the two Riches, for what it will mean for your culture" yada yada) Well.. we can guess Which was chosen. Kinda like Corporate next-quarter 'profits'. It's still Prince Valiant time in most-every MBA head-space. And for those exclusively surrounded by those.. Anyway, thanks for much clarification. I have upgraded my XML-lore to: seeing many more possibilities (as well as many more lateral arabesques) certainly aimed to screw up anything approaching danger to: My-My-My Proprietary Lock-in or Wet Dream Thereof\ufffd \ufffd \ufffd Y'know? Billy n'Bally have demonstrated starkly how EZ it was to screw Everyone and Still Be Loved by All Those Wannabes. So I deem that your vision (undeniably Sensible as it appears to this incompetent) may need to await a more mature world: post-Middle-East madness and its ummm er fallout ?? Maturity is sometimes galvanized by a Memorable recent-enough Spanking. OK: Clue-by-6. Ashton
Post #42,044 by dmarker2 6/12/02 12:40:15 AM Reply	Re: XML is ..., WebSvcs are ... (part 2) ... Actually the whole box & dice is very far reaching. If one looks at the bulk of standards being defined at W3C - most are now based on some XML derivative. I have hardly touched on the derived languages that have already been designed and the others in the 'mill'. There are XML derived languages for video streaming, voice data, image data etc: etc: (I don't know exactly what they do but someone saw fit to create them. Many of these 'languages' (which are nothing more that a set of TAGs & rules for their appearance in the language, and are defined in a schema) are being defined by industry groups seeking to simplify the exchange of data between partners - this is most noticable in the Supply-Chain-Management industry which was of course the industry the drove & benefitted from containerization. XML & Web Services specifically attempt to overcome the problems of EDI in an elegant manner that can be readily picked up by bulk of SMEs (small to medium enterprises) that today can't afford the complexity of EDI but must do business with the top 5-1-% who cannot run their business without EDI. (it pays to remember the Govts ran fastest ahd hardest with EDI & demand EDI protocols for government provisioning. This applies as much to US as to EU. One other bit of 'magic' that was built into XML is that of language version control. This is akin to the DLL Hell on windows. The issue is - ver 1.0 of a language appears (say it is dialect used for ordering auto-spare parts). Anyway along comes an upgrade - how does it get implemented without screwing all the apps that have linked to service providers delivering ver 1.0 formatted data. The XML approach is that the DTD or Schema (actually the DTD is doomed to extinction as it is a patheticly simplistic & non-XML compliant mechanism that has been eclipsed by the XML Schema). Any the Schema gets published so resides at one primary location (which is likely to be replicated) and all users of a document that rely on that Schema include a link to that schema (ver 1.0) in their Documents. To move to ver 2.0 - the schema creator only needs to create a new schema that contains the differences & link back to the original schma from the new one. This way we have two schemas published ver 1.0 & ver 2.0 & 2 only contains the changes from 1 thus any software that processes ver 2 documents will always validate against the ver 2 schema whilst any documents created with ver 1 can still refer to the version 1 schema rules. This is a bit like object oriented inheritance. Any new schema inherits the properties of its parent but can overide some definitions and add new ones but all the other stuff is as in the previos version. So XML offers an elegant and simple and effective version capability. This is a critical requirement for Web Services as it means a services provider can run the old and new service alongside each other. It is up to the servise requestors to determis which version or format that want to use. This means that changes don't have to break applications that are built on older versions of services. Cheers Doug Marker
Post #42,269 by CRConrad 6/13/02 5:29:11 PM 6/14/02 6:11:40 PM Reply	Not so analogous to containerization, then. Doug describes XML: a tag based meta-language [...] allows the creation of self describing data. So "XML" per se doesn't mean ready-made standardized "containers" (they're in the DTD/Schema), but more of a container-construction kit. If y[ou l]ook at it that way, are you still so sure it will "revolutionize" IT like containerization did shipping? Do you believe shipping would have been commoditized if there had only been a standard for how to build containers, but no actual standard for the resulting containers themselves? (Needless to say, since you already inferred it from my tone above, I don't think so.) `[EDIT: Typo; "you look" inadvertently contracted to "yook".]` Christian R. Conrad Of course, who am I to point fingers? I'm in the "Information Technology" business, prima facia evidence that there's bats in the bell tower. -- [link\|http://z.iwethey.org/forums/render/content/show?contentid=27764\|Andrew Grygus] Edited by CRConrad June 14, 2002, 06:11:40 PM EDT Expand All History
Post #42,288 by dmarker2 6/13/02 7:58:17 PM Reply	Re: Actually from several aspects I have just obtained an excellent article from Harvard Business review that describes in a good way the impact of XML / Web Services. When I can get the soft copy I will post a link or an extract. It puts the impact this way "End of proprietary computing as we know it" As regard containerization, there are many comparisons & aspects to an anology. I have been working on bring these together into a presentation. Cheers Doug
Post #41,806 by dmarker2 6/10/02 8:45:00 AM 6/10/02 8:57:38 AM Reply	Re: A couple of points you raise ... "As for the impact that XML will have on the world, I don't know what that will be like. But I suspect that it will be less than the hype has it. Why? Very simply because XML requires all parties involved to look at the same numbers, label them the same way, and think of them the same way. That works very well in a homogenous business, or if a small number of suppliers dominate a vertical market. But it stops working so well where different industries have to interface. And it runs counter to how competition in business proceeds." But this was why the XML Schema was intoduced & why the Schema is integral to Web Services. For this shebang to work both parties have to accept the published schema - not doing so is akin to a sender & receiver of a shipping container, both arguing over different bill of ladings for the one container. The Schema for a service gets published & subscribing to the service means you have adopted the common schema that defines the contents. I agree that for example, the auto industry has many factions & some may decide to adopt a different schema than another faction say for ordering spare vehicle parts (this is probably going to happen) but even if it does, XML provides the XSL family to make the job of bringing incompatible schema formats together. XML is extremely well thought out (as were the 2 main container sizes). There are bound to be orgs who want to ignore what becomes popular but as in the shipping container world, they may well get trampled in the standards compliant traffic. Also XML is actually a family of technologies - web services as a concept that extends XML and exploits many aspects of the XML family. POINT 2 ***************** "What this means is that attempts to homogenize how businesses interact with each other run counter to the businesses real need to each be different. Of course there are huge savings in transaction costs in being homogeneous, so businesses walk a fine line between what to be homogenous on, and what to not be. But the closer you get to the core business processes, the more they each need to be different. (Which is one of the fundamental reasons that most of the software development done in this world is in-house - and why that will remain the case.)" Yes, each business tends to adopt a unique set of processes that differentiates the services they offer. All XML & Web Services is likely to do is speed up the ability of businesses to define new & quicker adapting processes that provide a faster time-to-market. There are many analogies in manufacturing - the just-in-time ordering of raw materials replaced stockpiling raw materials - cut costs, provided better business cash-flow, reduced obsolesence etc: - all brought about by IT offering more reliable ordering capacity (such as EDI). Now EDI - that is what is going to be heavily impacted by web services - in effect WS is EDI for the masses & at the same time is a vastly more open & superior concept. But EDI is crucial the big buainess & supply-chain / logistics industries. Re EDI, it is UNCEFACT that is driving EDI/ebXML. Cheers Doug Edited by dmarker2 June 10, 2002, 08:48:52 AM EDT Edited by dmarker2 June 10, 2002, 08:57:38 AM EDT Expand All History

Welcome to IWETHEY!