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.
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' promiseto 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.
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.
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 businesses1) 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 platformwas 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 platfform 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.
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.
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' promiseto 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.
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.
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 businesses1) 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 platformwas 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 platfform 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.
No comments:
Post a Comment