Cart
[Home] [By Thread] [By Date] [Recent Entries]
Sorry if this all sounds like a marketing plug, but I thought some detail on what we do might be helpful in conveying our real-world, mission-critical use of XML technology. We use XML pervasively in our software. I'm not sure where our product suite fits into your categories. It's sort of in both the "commerce" and "information" sectors, but probably leans more toward the "information" sector, at present. We are in a nascent software category called Partner Relationship Management (PRM). PRM is founded on two key notions: * The Internet will not wipe out traditional business models. It can be a very effective tool, though, for improving business processes. (The bursting of the dot-com bubble is finally driving this point home for most people.) * Most commerce occurs through indirect channels, and often involves the collaboration of multiple partners to sell a solution. The Internet will not change this; not everyone is going to sell everything direct to the consumer. Our software is all about enabling a vendor to create an online community for collaboration and interaction with their partners, and for supporting a business strategy of forging and leveraging strong partner relationships for competitive advantage. All of our current customers license our software on a hosted model (i.e. an ASP model). However, our system is typically used as part of a larger solution. They are synchronizing information between our system and offline tools. They are integrating our system with CRM, ERP, and other backoffice systems, often in real-time with a high level of interaction between systems. They are integrating our solution into larger portals that employ single sign-on and provide a seamless user experience for their partners. And this is being done between systems that span the internet. We use XML for the following: * Defining the data model and other relevant metadata in a custom XML-based schema. This schema supports a rich data model (basically an ER model extended with the notion of inheritance) that can then be used at run time to create or modify a relational database schema to support the data model, and to actually create the relevant entities (in the ER sense of the term) at runtime (i.e. without hand-coding a bunch of classes). This supports very rapid development and customization of our solution. (Our deployment timelines are typically a fraction of our competitors', even with considerable customization.) This data model also supports a rich, dynamic, rules-based security model that manages security down to the record and field level (and which can be queried by the UI to appropriately customize application views). * Providing transparent mappings between hierarchical query and record structures and XML. These hierachical query and record structures are inferred from the schema, and provide hierarchical views into our data model (which is essentially a lattice). * Defining a rich, adaptable integration API that is completely XML-based and suitable for use over the internet (via S-HTTP). This is not just for synchronizing data, but also for invoking arbitrary business logic and incorporating our system into a larger workflow. Our customers run the gamut from those who are eager to exploit XML technologies, to those who are quite wary of XML and need some hand-holding. For the latter, we provide toolkits and code samples to guide any implementation effort on their part. Some of the latter are resistant to the use of XML initially. Once they've successfully completed an integration at low cost and in a short timeline (with a little help from us), they typically become converts and are happy using XML. We are not too concerned about the lack of vertical industry standards. We and our customers are doing just fine without them, and we are certainly not going to sit on our hands and wait for them. However, if there are such standards that gain widespread adoption which we can leverage to reduce implementation efforts -- and which don't constrain us to a rigid, non-extensible vocabulary that cannot adequately address business need -- we will support them. We'll do what makes sense to make it easy for customers and partners to integrate our solution into larger solutions that match their business processes. I can see the SAML initiative that OASIS is undertaking as something we will probably leverage, for instance, since so many of our deployments involve single sign-on and security that must span multiple systems across the internet. -----Original Message----- From: Michael Champion [mailto:mike.champion@s...] Sent: Friday, June 29, 2001 8:49 AM To: xml-dev Subject: XML and the Real World This came up in the Blueberry debate, but didn't get much discussion: How many real-world, mission-critical, money-making applications currently depend on XML technology? My semi-educated guess is: In "internet commerce" broadly defined, XML is a widely used, perhaps even dominant technology. In more traditional business to business transactions, traditional EDI rules, and there are numerous pilot projects to *supplement* EDI with XML B2B technology so that the benefits of EDI can be extended to small shops. In the "information" industry broadly defined (publishing, web sites, portals), a fair amount is really done today. I suspect that most of us are using or selling XML solutions in this sector. In manufacturing, XML is being used in prototypes, proof of concept applications, and lots of vertical industry standards discussions, but relatively little day-to-day business depends on it now. Even the electronics industry, where RosettaNet was an early XML effort, I get the impression that RosettaNet-based processes are just starting to come into production, with significant but modest "real world" milestones set for later this year. In general, I get the impression that the prototypical response of a real-world Chief Information Officer to XML is something like "Very interesting stuff; we're keeping an eye on it and doing some pilot projects. When our industry standardizes on a small set of XML vocabularies, we plan to incorporate it into our business processes." Anybody with hands-on experience care to comment, pro or con, on my semi-educated guesses? A reference to any articles on this subject would also be appreciated.
|
