Home
 > Research and Reports > TEC Blog > Commerce One Conducts Its Soul-Searching Metamorphosis

Commerce One Conducts Its Soul-Searching Metamorphosis

Written By: Predrag Jakovljevic
Published On: April 24 2003

Event Summary

One vendor that has lately had more than a fair share of troubles, and that is still reeling from the effects of plummeting market capitalization (with a tenfold reverse stock split), multiple severe rounds of layoffs, excruciatingly painful losses, and an eroding corporate image, has been also making notable strides to reform itself, or, at least, to sell its skin more dearly. On March 24, Commerce One (NASDAQ: CMRC), one of the pioneers in Internet-based software applications that once managed the world's largest e-commerce trading network, which has consistently strived to be at the forefront of delivering advanced technologies that help global businesses collaborate with their partners, customers and suppliers over the Internet, announced the general availability of Commerce One Conductor, its new composite application platform. Based on open industry standards, the Conductor platform's aimed charter is to transform and accelerate the way applications and business processes are deployed within and between enterprises, and it should supposedly allow organizations to more quickly and easily create, connect, and coordinate business processes between customers and trading partners without being limited by the constraints of existing applications or platforms.

Moreover, in an intensive pre-release program, Commerce One worked closely with both new and existing customers to deploy the Conductor platform to solve specific business problems. As a result, eleven customers including BOC Gases, Eastman Chemical, Open GIS Consortium, Enporion, Industrial Technology Research Institute (Taiwan), MSX, Siemens, and UCCNet have reportedly already deployed a pre-release version of Conductor to launch integrated business processes across both internal and external systems.

The vendor claims Conductor's unified architecture is designed to lower the time and cost of creating and deploying composite applications, as compared to the common alternative of using a combination of multiple point solutions like business process management (BPM), enterprise applications integration (EAI), portals, identity management and various design tools. Through a graphical user interface (GUI), business analysts can compose end-to-end business processes and add new application features and functions that complement customers' existing systems. Thus, these "composite" applications should supposedly transcend the limitations of traditional enterprise applications by enabling companies to gain new value from their existing systems and to bridge the gaps between disparate applications.

Commerce One Conductor is made up of a number of components, but the platform's brain is its central and shared Registry, which defines user and system interfaces as services. Conductor's Registry provides a possibly unique approach to centrally and dynamically managing process changes that are common in most business environments, which can improve flexibility and total cost of ownership (TCO). Accessible though a single, graphical design interface, and supported by a services-oriented architecture, the Conductor platform leverages software-based configuration engines that pull from a deep and modular registry of services and defined relationships. This approach should enable businesses to define disparate applications or services in a common fashion and dynamically bring them together to create new standards-based composite capabilities.

To dynamically execute these services in their correct context, the Registry also maintains full definitions of user roles and access, systems, business processes, data schemas, transformation maps, choreographies, rules and security requirements. All relationships, interactions, and attributes of every item defined in the platform can reportedly be maintained, modified, mixed and matched from the services and definitions held and shared in the Registry. This abstraction of key attributes of composite processes, users and services should allow for significantly lower TCO, since, through the Registry, the time-consuming and difficult work of creating and maintaining adapter connections and business relationships is hereby fully automated across the entire network of internal and external participants.

The Interoperability Engine, on its hand, provides document-level interoperability across applications participating in the business process. Working with the Registry, it dynamically determines the document formats, locations, security requirements, and various other required characteristics to connect to the applications, and it also performs transformation and versioning, message and document security, signatures, routing and transport needed for secure, reliable interoperation. In situations where a customer already has an EAI or business-to-business (B2B) infrastructure deployed, the Interoperability Engine can supposedly leverage these investments. Via gateways, the Interoperability Engine can also connect into existing electronic data interchange (EDI) infrastructures that a customer may have deployed.

Conductor also features a number of smaller components such as the Process Manager, a run-time engine where the business process is executed from the services accessed by the Interoperability Engine. When processes change, versions are upgraded, or new applications are added, the Process Manager leverages the Registry to dynamically make the changes. Also included are reporting and analysis tools and the ability to present services for manual user input through a GUI. The Graphical Process Builder (GPB) allows a business analyst to visually construct business processes from the resources listed and defined in the Registry. Processes can be reused or combined to create new functionality or to leverage differing registry resources inside the same process structure. The Design Suite provides tools required to create business processes and composite applications. These include the Graphical Process Builder, UI Framework, Common Object Framework, and XML tools. The Systems Management component handles end-to-end message tracking, component monitoring, topology management, installation, configuration, and initial data loading for participating services.

As an extension to the Conductor platform, Commerce One also plans to release Process Accelerators that will provide ready-to-run business processes that can be implemented easily within the Conductor platform. These accelerators will supposedly address common business processes within the Commerce One's expertise, such as supply and demand planning and management, invoice handling and commonly accepted best practices. The accelerators will be developed both internally by Commerce One and externally by its business and integrations partners to help customers running on Conductor to deploy more quickly and execute with greater certainty. Similar to the process accelerators, the Conductor platform will leverage the library of existing Commerce One Supplier Relationship Management (SRM) applications to provide specific business process functionality to complement the platform. To support the SRM applications, Conductor might offer a valuable resource to enhance, extend and expand their functionality.

This is Part One of a two-part note.

Part Two will cover Challenges and make User Recommendations.

Market Impact

Commerce One's odyssey continues, with many siren songs still lying ahead. The vendor might even be compared to a feature character of a tragic stage play, given it has often gone ahead of its times, which has only proven adversarial to the company, but often beneficial to others. While enterprises may still be leveraging Commerce One's earlier applications to collaborate over the Internet, the way in which they conduct e-Business has quite evolved from what Commerce One initially envisioned a few years ago. Namely, instead of running Internet-based trading exchanges (marketplaces) for entire or even multiple industries, Commerce One customers now rather focus on streamlining e-procurement and strategic sourcing processes within their individual enterprises.

Thus, the most recent benefactor from Commerce One' technology could be eScout, an e-procurement marketplace provider, to whom Commerce One recently (in December 2002) sold off its former Commerce One.net exchange-related businesses. Indeed, the combination of eScout's content and transaction handling services savvy with recently acquired Commerce One.net's network trading infrastructure may finally fulfill a venerable vision of the procurement exchanges' promise to match buyers and sellers within an industry via a virtual marketplace, facilitate their consummation of trade and transactions, and charge a small fee for the service. To that end, it might even be ironic that eScout could actually deliver soon on what Commerce One aspired to a few years ago with its former Global Trading Web idea, which had not materialized then.

In addition to eScout's up-sell potential due to the inherited Commerce One.net's customer base, the acquisition may also create one of the world's most comprehensive exchanges, possibly showing a viable value proposition to many companies flirting with the idea of finally handling their procurement and sourcing tasks online. The offering might also lessen the difficulties of dealing with multiple procurement exchanges and suppliers, since the combination of eScout and Commerce One.net also seemingly espouses a buyer-system agnostic architecture that should allow different e-procurement on-ramps to connect to the exchange. Enter some group buying contracts (featuring aggregation optimization) and native e-procurement functionality, bundled with the growing volume of transactions and participation of buyers and suppliers -- the value proposition of e-procurement could finally move down to the mid-market, particularly given the recent move toward indirect materials procurement outsourcing.

Historical Perspective

One cannot omit mentioning the once highly-touted and now extinct partnership with SAP either, which began in June 2000 and was at the time touted by SAP as a proof of its new approach to true partnerships (see SAP Gives Up, Declares Victory. Again.), and which was formed to target the online e-procurement and then booming electronic business-to-business (B2B) marketplaces. As a part of the deal Commerce One and SAP combined their on-line marketplace efforts into a single offering called MarketSet and pledged to jointly sell each other's e-procurement software.

In June 2001, SAP even increased its stake in Commerce One to little over 20% by injecting up to $250 million in new investment capital into the company. Inevitable speculation over whether SAP would then acquire the partner, has, however, meanwhile been proven utterly unfounded. It appeared, in the pure numbers, with 20% ownership of Commerce One, SAP's results would often get indirectly affected with Commerce One's ballooning losses. SAP finally realized at the end of 2002 that, to just acquire the part of Commerce One it might still need, would not be worth the trouble of possible liabilities.

While SAP benefited from the relationship owing to the fact that the exchange infrastructure of its recent NetWeaver/ESA platform (formerly mySAP Technology, see SAP Weaves Microsoft .NET And IBM WebSphere Into Its ESA Tapestry) still likely incorporates B2B integration capabilities from Commerce One, as even pointed out by SAP during its launch of mySAP SRM product (SAP To Take Care Of All Suppliers), the general feeling has been that the partnership is what allowed Commerce One to survive to this point given almost 95% of its license revenues have long been coming from SAP royalties. Many still believe that only a buy-out by SAP will ensure Commerce One's long-term survival. Given it has now become a moot argument, many are speculating about other potential buyers, while a rare few are indicating that Commerce One might still make it on its own.

Surviving With an Independent Product

Indeed, the vendor has so far shown its ability to have a few lives like a cat, by a series of subsequent chameleon-like transitions and brand recognition making anew within the exchanges, e-procurement and supply relationship management (SRM) respective markets. Following up on the collapse of the public (and, to a degree, even private) trading exchanges concept, and having seen the writing on the wall regarding SAP's affair ending, in December 2001, Commerce One, announced Commerce One 5.0 that included Buy, Source and the Collaborative Platform, its online sourcing application which it developed independently of SAP and which is the first product to have been developed solely by Commerce One since they initiated their partnership. This new suite of collaborative sourcing and procurement solutions was aimed at automation of enterprise source-to-pay processes, while also enabling deep connections between an organization and its trading partners.

However, gaining traction in strategic sourcing has not been an easy feat for Commerce One thus far, in great part because the market had in the meantime got used to the idea of its success only via piggy-backing on SAP and by being eventually acquired by the giant. The fact indeed remains that the lion's share of Commerce One's revenue comes from SAP's customer base, given Commerce One's newcomer status in the SRM arena and its relative lack of experience within more prosperous direct materials sourcing.

This predicament has been unfortunate for Commerce One, given the recent attractiveness of SRM solutions, since customers have recently been focused on saving money and, particularly in today's buyers' market, they are utilizing competitive bidding into as many categories as possible. Often, the expenditures pertaining to suppliers relationship can even exceed 30% of revenue, and customers will likely embrace any software that is able to restrict this expense and/or concurrently create a more effective and successful relationship between customers and their suppliers. The direct materials e-sourcing wave thus seems to be overtaking the procure-to-pay market for indirect materials. Given direct materials procurement execution also has much more laborious nature, the e-sourcing opportunity has presented itself, especially with ERP vendors like SAP, Oracle and PeopleSoft entering the market in earnest.

Consequently, the escalating competition, depleting revenues, crippling losses and numerous restructuring moves, have resulted with many Commerce One's business plan changes, Conductor being the last order of the day'. Since Commerce One had long struggled to cost-effectively manage its former three distinct businesses 1) a UCCnet consulting and implementation services (stemming mainly from the AppNet acquisition in 2000), 2) a Web services-based Conductor platform, and 3) a set of procurement, sourcing and infrastructure (the platform was MarketSite, Collaborative Platform) exchange business applications -- selling one of them to eScout to bolster cash reserve and further narrow focus was justifiable. Commerce One has since turned its attention almost exclusively to Web services with the Conductor set of applications aimed at supply chain visibility and facilitating automated processes between trading partners.

By devising Conductor, a hybrid between an integration platform and a platform for building composite applications or business processes, Commerce One seemingly made yet another bet-the-company' move mid-2002 by turning to harnessing Web services and thereby turning itself into a standard-based, application-agnostic integrator. It is a hub-based back-office integration functionality based on the Web services technology acquired through Commerce One's earlier purchase of Exterprise.

Longer term, this vision could theoretically become the foundation for Commerce One's brighter future, since its focus on integration, coupled with its other core skills in BPM and content management, should serve the company well in a diverse enterprise applications environment, where exchanges in particular are faced with the challenge of integration of technologies and processes between multiple back-end systems. Commerce One claims it might in fact be easier to integrate its system to two different versions of the same ERP system than it would be for any ERP vendor itself, given there are many Commerce One customers resident on SAP, Oracle, or PeopleSoft enterprise systems.

A blessing in disguise has at least been that the vendor has learned in the process that a major weakness in many exchange-based approaches was the intricacy to integrate all the systems involved running on disparate hardware and software, and particularly to connect all the parties at a business process level. Not to mention its injudicious and harmful "build it and they will come" approach at the end of 1990s, without grasping all the ramifications for all the participating parties. For suppliers, participating meant adding layers of complex integration atop an already overtaxed infrastructure, with little if any benefit to them other than to remain a supplier (often with a negative aspect of being pressed to cut their prices and margins due to open auctions' nature of trading).

For the holder of the exchange, the pain also included managing a wide variety of community members, creating and controlling new workflows, maintaining and administering business rules, and making sure that participants only receive information that they are entitled to see. Thus, from its work in pioneering marketplaces and managing complex supply chain relationships, Commerce One has learned the hard way the challenges of executing business processes across the differing technologies of numerous trading partners.

To that end, Commerce One's idea of its Conductor as one the first unified, technology- neutral platform's that enables businesses to execute and share processes easily across disparate applications and systems seems innovative and should help the needs of the higher-end of the market, whose paramount concerns have been the enormous costs of integration and the general lack of responsiveness by enterprise application vendors to address this issue. The vendor's embracing of standards-based Web services as a technology enabler may appeal to customers that are keen on preempting dependencies on proprietary Application Programming Interfaces (APIs). Conductor tries to deliver the above requirements of building, managing and orchestrating composite processes, bundled with an easy maintenance of the generated system afterwards, which could finally make up for missing pieces of its erstwhile failed exchanges' value proposition.

This concludes Part One of a two-part note.

Part Two continues the discussion of the Market Impact, covers Challenges and makes User Recommendations.

 
comments powered by Disqus

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.