[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-dev] Re: Addendum to Automating execution of Biz Processes(& BPSS)....
At 08:25 PM 6/25/02, Klaus-Dieter Naujok wrote a brilliant piece ... thus stimulating mental midgets like me to challenge him! :-) >Conclusion > >The question is will the current supplies of shrink-wrap solutions integrate >ebXML into their offerings? For now these application vendors don't see the >need for such an interface, or don't have the know-how to develop it. This >opens the door for someone who knows the data interchange business to create >the front end to those applications and to import a particular model in >order to engage in the exchange with other partners that are ebXML >compliant. The 1000 largest Enterprises won't genuinely support global standardisation. Oh, they get up early in the morning and work all day long, to make their *own* software more efficient, even if that means driving adoption of software in their whole supply chain. BUT! They must ensure that whatever they design, build, support etc. does not make their competitor more efficient to an equal degree. If the whole industry becomes more efficient only consumers win. Producers just work harder. ERP vendors knowing this, have bagged the Global 1000 firms with applications they can endlessly configure and play with, and EAI industry creates more. Now we're seeing the CRM industry and BI etc. From SME's viewpoint this is a disgusting spectacle that translates into nothing but an advantage of the large over the small, as only the largest corps can afford software and their systems become entirely incompatible with SME and midrange platforms (which have not improved substantially since the early 1990s when we got GUIs, 32bit applications, and microsoft killed all the other multitasking and networking choices.) The SMEs having different behaviors, are captured by their own vendors with plain old file and data lock-in. This has long ago run its course and collapsed into near monopoly among a few packages owned by Intuit, CA, and Sage (including Peachtree, business works etc.). >There are many opportunities for such software front-ends. In addition to >being able to execute more than one (if not all) business model(s), the >application could use agents to query on-line repositories to identify >potential trading partners for a specific requirement (order). In addition >to just being the front end to a popular business application, one could add >the capability for the system to be configured to in-house applications that >were custom developed. Further, the in-house business process could also be >stored in a business process model allowing agents to not only identify >potential customers based on a static in-house process, but possibly >extending the number of potential partners by modifying (adopting) the >internal processes based on the knowledge of both models. The technology is >there, we have the know-how; all it takes is for us to harness it. > >In closing, the success of any new way to exchange data among businesses >depends not only on the adoption by the Fortune 1000 companies of standard >agreements, but as well as on the utilization of the other 25,000,000 SMEs >in the world. Without an economic incentive for the SMEs, any new method of >accomplishing e-Business is just another pointless effort. ebXML is >currently the global solution that uses business process and information >modeling and object oriented technology to allow the software vendors to >create the "volks data interchange" solution. The time is right for someone >to do it, now. No, there's not much business opportunity building addons to Intuit Quickbooks, Sage Peachtree etc. They're just waiting, to play that game. Right now they're making millions from fees, from starry-eyed developers and VAR wannabes. Isn't it mysterious to you that the oligopolistic SME software vendors, who could have long ago implemented "state alignment" among a whole lot of obvious exchanges such as list data, purchases, sales, have not done so? They could have done it back in the days of DOS and modems and BBS's. The reason is that without data capture and lock-in, there is no above-normal return in SME software. All these vendors have some ASCII interfaces, some APIs. But these interfaces are *crooked as a thumb.* You cannot build applications that rely on those interfaces because there is invariably something missing, something that corrupts, or something that has a runtime royalty, platform churn etc. Many of them still use btrieve database layer. e.g. Peachtree. You know the history of btrieve-- the database can't get a decent grip on the disk, constantly undercut by changes in the hardware layers under DOS or Windows. It's a miracle Quickbooks' proprietary database still runs, on Microsoft's ever changing platform. The likelihood that anybody's Addon software to these platforms will find a dependable API, that reliably commit transactions over the amortization period of the addon software, is not high. The maintenance and support will kill you. You'll be up there at $3000 or $5000. A startup could deliver a whole new SME package for less than that--or buy/partner with one of the dozens of 2nd tier products. Klaus- you said, somebody who knows the data interface business should build addons to Quickbooks. I say, no, they should buy or partner with a 2nd tier product or build from scratch. You need something you can walk away from and it keeps running a couple of years. SMEs will continue with Quickbooks basically forever, until there is a damned good reason to buy a entirely different software packages from an entirely new generation of software vendors. Existing dominant vendors would have to be crazy to start opening up an honest API anyway, with well defined semantics. Sheesh. never happen. The applications would have to be changed anyway. All of the terms on the user interface are intentionally general and vague. They are not core componentish. The whole mode of operation is basically manual. Again think of what you know about Enterprise vendors. They have no freedom really. They can only sell what Enterprise is ready to buy and what maximizes their revenue. That in turn must maximize Enterprise' lock on their customers and suppliers, and that often means, being a bad actor and not sharing data. SMEs today have no reason to change. OK, there might be a few good reasons in future. 1) access to substantially better markets or new customers or stronger prices for what they sell. and, access to lower cost suppliers, better terms of trade, etc. This is the siren song of B2B isn't it? But they're mutually contradictory. How can everybody on ebXML get higher revenue, while everybody has lower costs? heh heh! But even so, SMEs are supposed to get better customers and suppliers, by deeper process integration with Enterprise.. Well maybe. SMEs will have to observe, who turns out to be the winner. Suppliers apparently have been the lusers. (That's SMEs.) (Remember I'm talking about the smaller, millions of SMEs not the real demand-signal types of companies. ebxML or EDI for that matter, is great, for them.) 2) Another d'good reason: major convenience for some significant fraction of their business dealings. Only Microsoft can provide this today, without requiring a mass adoption as precondition. They can make whole categories of transactions almost secure enough for daily use, because they are the only people who have sufficient control over the security of Windows itself. In other words, Microsoft can put a new gizmo on the desktop that sends and receives a particular document within a particular choreography and just the existence of that, would cause some broad adoption. What if it was a signing Icon where you could drag and drop any arbitrary XML document and signed and encrypted the document and sent it to the address inside? Mickey can do anything like that. But nobody else can do it. Odds are, Mickey will win. Time is on their side. They can keep hiring thousands and thousands of guys like Jim Clark who then go silent. My whole neighborhood here is full of Indian, Chinese, Brits, Japanese, Koreans as well as Compaqians, Dellians, Ciscoeans, and now GreatPlainsians. Lots of others have already been ploughed under, you know, the DEC people, 3+Open people before that, etc. In fact there is tall grass in front of my neighbor, the Compaquian who must have been reloc.d back to Houston. I read somewhere, they have 500 million desktops. That is a lot of desktops, where you cannot install eCommerce because they are too insecure. Isn't that an odd circumstance? 3) another possible driver for ebXML never mentioned here in ebXML is the escape from regulation and taxation long recognized as a possibility with digital cash and ebusiness exchanges. The explosion of wholesale looting of music by 50 million people the last couple years shows, there can be very very rapid adoption of things that give a sudden economic windfall, and that people are disgusting and lawless. If you have the stomach for the consequences, then, build ebXML business choreography into a headless P2P application with its own mini-RegRep. Skip the CPPAs and build in something like Webfunds client for digital cash. That has been out there for years and works fine. There are already numerous mints for that, and there are other competing mints and clients, and a lot of brokerages between them all. However, sad to say there are break-ins and theft of digital cash, and other disasters on a weekly basis on the digital gold lists. Why? Because users are too clueless and Windows is insecure. If this is happening among technically savvy, early adopters of digital gold, then what will happen when ebXML is widespread, on Windows? No doubt, crooks will come in and fsck with your numbers in order to steal inventory or tweak their payable/receivable balances in your system. Or just to nuke your system. OK, these risks are mitigated if there's no digital cash and there is an orthodox bank-based settlement, B2B intermediaries, audit trail, etc.! That's fine, but then, there is less of a payoff for I/SMEs to adopt it. We already know what SMEs think of B2B portals: they ignore them, with prejudice! :-) Any serious ebXML needs to happen on Linux or BSD and the accounting or business software on those platforms is quite primitive and unsuitable for modification for ebXML. Green fields. Truly, green fields. That's where ebXML will happen for SMEs and probably outside the United States. Not from the mature Windows vendors. >=============== > >BTW, the full article is available on my web site. > >Regards, >Klaus I agreed with just about everything in your article! Well said. In particular -- SMEs need content, at this point. They need a library of Core Components elements and aggregates, the sooner the better, and they need basic set of Business Processes. Neither of these needs to be rocket science because no vendors are going to adopt the technical specifications anyway. They will pluck some of the semantic content and smurf it all up within some kind of a strategic game, to allow some partners to integrate a few selected things just like they are doing with "web services". They're just trying to immobilize customers and churn everything. ebXML is the "end of history" for all the basic business choreography and severely constrains the differentiation possible in whatever specialization remains. LAMP (LinuxApacheMySQL/PHP) developers will have a field day, with these globally standard data dictionaries. Give them the content! Todd
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC