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.