Commerce One (NASDAQ: CMRC), one of the pioneers in Internet-based software applications and once powered 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.
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.
Although Commerce One would not be the only one to go in this direction given, e.g., SAP's NetWeaver, Siebel's UAN (Universal Application Network), PeopleSoft's AppConnect, and J.D. Edwards' eXternal Process Integration (XPI) composite applications approach through Web services and business process integration, Commerce One might be going a step ahead by providing a non application-centric integration platform, allowing customers to rather focus on acquiring most appropriate applications rather than the integration platform. The product is particularly tuned to Web services infrastructure including choreographies, routing and transformation, with an idea to separate data and processes from hard-coding within applications.
Although integration or applications servers may reduce that complexity to a degree because all the applications plug into a central hub, the EAI servers themselves tend to be proprietary and non-standard. Customers are increasingly desiring to do away with point-to-point integration approaches at that data level (with extensive lists of custom APIs and connectors/adapters) and to replace it with more inter-enterprise ranging integrations, based on business processes that extend beyond the traditional definitional boundaries of a single application suite.
Conductor's architecture is also in keeping with the current trend of making multiple applications viewable through a single GUI. Empowered business analysts, rather than nerdy programmers, should thereby be able to compose whole business processes and add new application features and functions that complement customers' existing systems through the intuitive GUI.
Therefore, Commerce One's strive for standards-based business processes to plug into industry-standard servers, may raise the least common denominator of interoperability, as it should add another agnostic layer of connectivity, providing BPM and workflow on top of integration framework per se. Conductor also supports Web services standards, including many of those that have yet to reach maturity and true acceptance, with an idea to be open to changes reflected by an evolving market niche. It is important to realize that Commerce One's long commitment to eXtensible Markup Language (XML) has been far reaching and represents a real technical strength. For example, the vendor has long incorporated data field validation (i.e., strong typing') into its XML schema language, given the standard XML is technically neutral to the values passed into fields, often resulting with systems inability to talk' to each other and recognize the document.
While XML can be used to define data for interchange between applications, workflows are much more difficult to document, and the market has discovered the need to separate rules, processes and data. To that end, in the connectivity layer, the Conductor's Registry supports UDDI (Universal Description, Discovery, and Integration) standard, and in the semantics level, XML Common Business Library (XCBL). As for the layer for business processes, Conductor supports Business Process Execution Language for Web Services, Version 1.0 (BPEL4WS). Commerce One had no better option to pursue given the lack of its own back-office offering and its adoption by a diverse population of ERP users. Furthermore, the move will help Commerce One further componentize its upcoming Commerce One 6.0 sourcing an procurement products, as standards like XML and eXtensible Stylesheet Language (XSL) make it possible to share data and have a common look-and-feel across an application, without necessarily digging in the source code. The latest release will likely exhibit some intra-suite rationalization and process integration, which has lacked in previous monolithic incarnations.
However, while Commerce One might have hereby given some homework to many composite applications integration aspirants, the vendor is nonetheless burdened with many challenges which are both of internal and external nature. It is unfortunate for the vendor that it is entering the highly contested integration & infrastructure market, while still suffering from the collapse of its sales & marketing capabilities and customer mindshare in its native SRM and exchange markets.
The firm is seemingly stuck with yet another identity crisis being a novice provider of a Web services-based integration platform and being a still fledgling provider of business application suite built on top of that platform, and which has not yet successfully competed in the SRM arena. The problem also stems from the fact that these two markets are very different, and focusing on one dilutes the effort of focusing on the other.
Deep functionality and domain expertise characterize SRM products coming from pure players like FreeMarkets, Ariba or Entomo, which are sold to very discerning procurement and supply chain managers within the customer's organization. A Web services strategy, on the other hand, is dependent on selling the platform into the IT department and also cultivating an ecosystem of enterprise solutions to build on top of the platform. Having a cuckoo in the nest' strategy to sell one with the up- and cross-sell value of the other has not apparently been working out so far, and Commerce One might not have enough resource to sustain both businesses without the appropriate revenue level.
Further, the Conductor approach might not be embraced easily and quickly either, since Web services have a ways to go before they are secure and reliable, both being key features of BPM attractiveness. One other issue will also be whether Commerce One will convince customers to rely on it for extended enterprise business processes integration, given Tier 1 ERP vendors' strides in that regard. This challenge may not be that insurmountable in some instances given Commerce One's expertise of extending supplier-centric business processes within its industries of focus (e.g., retail, consumer packaged good (CPG), etc.). But, the vendor will have to emphasize business benefit rather than technology advantage, given the current market's aversion to unproven innovation.
Another obvious challenge is a mere volume of the imminent work that is ahead of Commerce One and its partners to offer almost out-of-the-box' integrated functionality in shape of a pre-built library of business processes. Commerce One has reportedly brought in Baltimore Technologies and VeriSign for security, Sonic Software for messaging, Actional for integration, Contivo for data mapping, Cognos for analytics and Satyam for systems integration, to bolster its massive Web services endeavor. Now, at least by the above mind boggling announcement and description of Conductor, it may be clearer how complex SRM integration is. SRM integration requires that a client can obtain an enterprise wide view of suppliers and share it accurately across all channels and divisions. One should imagine how humongous the job of delivering plug-and-play packaged middleware components for a number of disparate applications, particularly outside Commerce One's expert domain like CRM, or product lifecycle management (PLM) will be. It would not be surprising to see customers opting for the expert vendors in case, even if there was no a viability concern for Commerce One.
Although Commerce One's due diligence in terms of providing a number of customer benefit examples as proofs of concept was commendable, it may still not be enough for much needed traction. It currently has 11 early adopter Conductor users that are boasting factual benefits, including BOC Gases (using Conductor to speed its ordering processes by exposing internal product codes and specifications directly to its customers), Eastman Chemicals (to streamline financial reporting errors), or Enporion (to enhance spend analysis). While Conductor could prove to be very attractive to Commerce One's existing customer base, the customer base has nonetheless lately shrunk, particularly after fallout with SAP and sellout to eScout, which additionally reduces the maneuvering space. The company is in a sort of a vicious circle it needs to expand its Source to Pay/SRM customer base into which it can further sell Conductor platform, but with currently all but stalled new license revenue, it has rather to resort to cash-saving rationalization and limited SRM product enhancements and marketing. That, in turn, creates viability issue and poor market perception, which means more difficult and impaired new sales effort.
Commerce One thus needs many more new customer wins, such as the very recent one, Hitachi Europe, which will be using the buy-side vendor's products within its procurement and sourcing group. The win may again indicate that, despite Commerce One's remaking as a Web services infrastructure provider, it is still primarily perceived, and paid, as a provider of sourcing technology. However, Commerce One's messaging is becoming ever less about sourcing and procurement. Hitachi will reportedly deploy Commerce One to source goods and materials to be used by its European manufacturing facilities for computer products, home electronics, automotive, semiconductor, and air conditioning products.
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.
Although Commerce One would not be the only one to go in this direction given, e.g., SAP's NetWeaver, Siebel's UAN (Universal Application Network), PeopleSoft's AppConnect, and J.D. Edwards' eXternal Process Integration (XPI) composite applications approach through Web services and business process integration, Commerce One might be going a step ahead by providing a non application-centric integration platform, allowing customers to rather focus on acquiring most appropriate applications rather than the integration platform. The product is particularly tuned to Web services infrastructure including choreographies, routing and transformation, with an idea to separate data and processes from hard-coding within applications.
Although integration or applications servers may reduce that complexity to a degree because all the applications plug into a central hub, the EAI servers themselves tend to be proprietary and non-standard. Customers are increasingly desiring to do away with point-to-point integration approaches at that data level (with extensive lists of custom APIs and connectors/adapters) and to replace it with more inter-enterprise ranging integrations, based on business processes that extend beyond the traditional definitional boundaries of a single application suite.
Conductor's architecture is also in keeping with the current trend of making multiple applications viewable through a single GUI. Empowered business analysts, rather than nerdy programmers, should thereby be able to compose whole business processes and add new application features and functions that complement customers' existing systems through the intuitive GUI.
Therefore, Commerce One's strive for standards-based business processes to plug into industry-standard servers, may raise the least common denominator of interoperability, as it should add another agnostic layer of connectivity, providing BPM and workflow on top of integration framework per se. Conductor also supports Web services standards, including many of those that have yet to reach maturity and true acceptance, with an idea to be open to changes reflected by an evolving market niche. It is important to realize that Commerce One's long commitment to eXtensible Markup Language (XML) has been far reaching and represents a real technical strength. For example, the vendor has long incorporated data field validation (i.e., strong typing') into its XML schema language, given the standard XML is technically neutral to the values passed into fields, often resulting with systems inability to talk' to each other and recognize the document.
While XML can be used to define data for interchange between applications, workflows are much more difficult to document, and the market has discovered the need to separate rules, processes and data. To that end, in the connectivity layer, the Conductor's Registry supports UDDI (Universal Description, Discovery, and Integration) standard, and in the semantics level, XML Common Business Library (XCBL). As for the layer for business processes, Conductor supports Business Process Execution Language for Web Services, Version 1.0 (BPEL4WS). Commerce One had no better option to pursue given the lack of its own back-office offering and its adoption by a diverse population of ERP users. Furthermore, the move will help Commerce One further componentize its upcoming Commerce One 6.0 sourcing an procurement products, as standards like XML and eXtensible Stylesheet Language (XSL) make it possible to share data and have a common look-and-feel across an application, without necessarily digging in the source code. The latest release will likely exhibit some intra-suite rationalization and process integration, which has lacked in previous monolithic incarnations.
However, while Commerce One might have hereby given some homework to many composite applications integration aspirants, the vendor is nonetheless burdened with many challenges which are both of internal and external nature. It is unfortunate for the vendor that it is entering the highly contested integration & infrastructure market, while still suffering from the collapse of its sales & marketing capabilities and customer mindshare in its native SRM and exchange markets.
The firm is seemingly stuck with yet another identity crisis being a novice provider of a Web services-based integration platform and being a still fledgling provider of business application suite built on top of that platform, and which has not yet successfully competed in the SRM arena. The problem also stems from the fact that these two markets are very different, and focusing on one dilutes the effort of focusing on the other.
Deep functionality and domain expertise characterize SRM products coming from pure players like FreeMarkets, Ariba or Entomo, which are sold to very discerning procurement and supply chain managers within the customer's organization. A Web services strategy, on the other hand, is dependent on selling the platform into the IT department and also cultivating an ecosystem of enterprise solutions to build on top of the platform. Having a cuckoo in the nest' strategy to sell one with the up- and cross-sell value of the other has not apparently been working out so far, and Commerce One might not have enough resource to sustain both businesses without the appropriate revenue level.
Further, the Conductor approach might not be embraced easily and quickly either, since Web services have a ways to go before they are secure and reliable, both being key features of BPM attractiveness. One other issue will also be whether Commerce One will convince customers to rely on it for extended enterprise business processes integration, given Tier 1 ERP vendors' strides in that regard. This challenge may not be that insurmountable in some instances given Commerce One's expertise of extending supplier-centric business processes within its industries of focus (e.g., retail, consumer packaged good (CPG), etc.). But, the vendor will have to emphasize business benefit rather than technology advantage, given the current market's aversion to unproven innovation.
Another obvious challenge is a mere volume of the imminent work that is ahead of Commerce One and its partners to offer almost out-of-the-box' integrated functionality in shape of a pre-built library of business processes. Commerce One has reportedly brought in Baltimore Technologies and VeriSign for security, Sonic Software for messaging, Actional for integration, Contivo for data mapping, Cognos for analytics and Satyam for systems integration, to bolster its massive Web services endeavor. Now, at least by the above mind boggling announcement and description of Conductor, it may be clearer how complex SRM integration is. SRM integration requires that a client can obtain an enterprise wide view of suppliers and share it accurately across all channels and divisions. One should imagine how humongous the job of delivering plug-and-play packaged middleware components for a number of disparate applications, particularly outside Commerce One's expert domain like CRM, or product lifecycle management (PLM) will be. It would not be surprising to see customers opting for the expert vendors in case, even if there was no a viability concern for Commerce One.
Although Commerce One's due diligence in terms of providing a number of customer benefit examples as proofs of concept was commendable, it may still not be enough for much needed traction. It currently has 11 early adopter Conductor users that are boasting factual benefits, including BOC Gases (using Conductor to speed its ordering processes by exposing internal product codes and specifications directly to its customers), Eastman Chemicals (to streamline financial reporting errors), or Enporion (to enhance spend analysis). While Conductor could prove to be very attractive to Commerce One's existing customer base, the customer base has nonetheless lately shrunk, particularly after fallout with SAP and sellout to eScout, which additionally reduces the maneuvering space. The company is in a sort of a vicious circle it needs to expand its Source to Pay/SRM customer base into which it can further sell Conductor platform, but with currently all but stalled new license revenue, it has rather to resort to cash-saving rationalization and limited SRM product enhancements and marketing. That, in turn, creates viability issue and poor market perception, which means more difficult and impaired new sales effort.
Commerce One thus needs many more new customer wins, such as the very recent one, Hitachi Europe, which will be using the buy-side vendor's products within its procurement and sourcing group. The win may again indicate that, despite Commerce One's remaking as a Web services infrastructure provider, it is still primarily perceived, and paid, as a provider of sourcing technology. However, Commerce One's messaging is becoming ever less about sourcing and procurement. Hitachi will reportedly deploy Commerce One to source goods and materials to be used by its European manufacturing facilities for computer products, home electronics, automotive, semiconductor, and air conditioning products.
No comments:
Post a Comment