Post #41,802
6/10/02 7:57:15 AM
|
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
6/10/02 8:33:20 AM
|
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
6/10/02 11:13:02 AM
|
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
6/10/02 11:33:09 AM
|
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
6/11/02 9:33:05 AM
6/11/02 10:37:28 AM
|
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
|
Post #42,021
6/11/02 8:48:46 PM
|
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
6/12/02 12:40:15 AM
|
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
6/13/02 5:29:11 PM
6/14/02 6:11:40 PM
|
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
|
Post #42,288
6/13/02 7:58:17 PM
|
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
6/10/02 8:45:00 AM
6/10/02 8:57:38 AM
|
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
|
