De-Centralization in B2B and Collaborative Commerce
The last few years have seen a series of attempts to build B2B systems that are fundamentally centralized. The belief was that B2B could be handled most effectively by imitating eBay and building a single central marketplace site that brought buying and selling organizations together in one place. This became known as the "Fat Butterfly" model; wings of buyers and sellers linked by a fat market in the middle. At the same time, the principal vendors were also producing e-procurement systems aimed at the internal needs of large corporations. At the core of both of these types of systems is an aggregated catalogue of products, suppliers and prices. While this has been happening, the suppliers have been putting their stall out on the web with storefront systems, that also hold a catalogue of product information.
The competition between these different approaches and the many implementations of each, have led some observers to predict a major shake out in which only one market remains in each major industrial sector. But the reality is actually increasing fragmentation as more and more players implement one of the systems. This is beginning to expose some fundamental flaws in the approaches as the buying led systems find it impossible to sign up suppliers and as the suppliers find themselves expected to hand over their data to multiple buying hubs whether they be public markets or private buying systems. Even in the most commoditized products, where a true Exchange could be expected to work, we find that there is often only a handful of traders who actually transact between one another. Then there are the scalability and reliability issues involved in running a single hub for a large number of companies. If the hub goes down the entire trade through the hub stops, where as in a decentralized system, if one node fails only trading with that node stops.
If we stand back for a moment from the immediate past and look at the relationships involved this begins to look less like a hub and spoke model and more like a web of more or less temporary point to point links between organizations. These links maybe the result of an initial approach between buyer and seller, or they maybe a long standing relationship. The underlying product data is generated and maintained by the supplier and needs to be linked with the supplier's own back office whether it's their engineering, stock control, manufacturing control, marketing or accounting departments. Solutions to these problems have been suggested such as "punch out" to allow searching of a supplier's catalogue from within marketplace software or links between hubs to offload requests to another market if they cannot be satisfied within the current one. But these begin to look like band aids that don't really address the real problem.
All this suggests that we should be creating systems that leave the data where it is and support trading from business peer to business peer. With all the publicity surrounding the music and file sharing systems such as Napster, it is tempting to compare this with them and call it P2P but this is likely to just confuse the issue. Any business critical trading system is unlikely to be allowed direct desktop to desktop connections and in any case there are technical problems with firewalls and security which work against this. But business peer to business peer systems that talk server to server may be possible.
This sort of approach is going to require widely supported and implemented standards if a critical mass of companies are going to take advantage of it. It is essential that systems from many vendors and implemented by many companies can interoperate if this is going to work. Thankfully there are two families of standards that are nearing completion and beginning to be supported by the software vendors. The first is the UN/CEFACT, OASIS, UDDI and ebXML family. This is an all encompassing set largely based on XML. It includes standards for product descriptions, standard transactions, a protocol for server to server communication and a searchable index of services or functions exposed by servers. This is most of what we need to build our web of servers and organizations. This family of standards has the support of most of the major vendors including IBM, Microsoft, Ariba and so stands a good chance of succeeding. The second is the CPFR, VICS and BPMI initiatives, again XML based, but focussed on collaboration between companies in the areas of planning, forecasting and business process links.
Collaborative Commerce is not just about transactions. There are numerous cases where an employee in one company needs to collaborate with an employee of another company. Of course, the killer application for this is email and we now think nothing of communicating outside our organization with this tool. In recent months, a number of decentralized systems have begun to appear that address collaboration between small groups of people who are geographically spread and in different organizations. Perhaps the most well known is Groove that provides something like Notes, but companies like Jabber and Consilient are also working in this area. These systems provide more structure than email but still with the ease of installation and lightweight of a desktop application. If any of these really take off then we can expect them to appear in organizations via the back door, regardless of what central IT would like!
In summary, centralized systems have some inherent problems that are working against wide spread adoption of B2B. They make it hard for the suppliers, without whom there is no trade. They are large and heavy weight with the attendant high costs of implementation. They force the system operators to be involved in collating, updating and maintaining catalogue data that is actually owned by someone else. And they have limitations in scalability and reliability. By contrast, a de-centralized system supports the real world of constantly shifting relationships between companies. It leaves the responsibility of maintaining the data with the source of that data. And it distributes the points of failure so that the impact of the inevitable system downtime, are limited. The standards required to support all this are maturing fast and almost ready for prime time. The end result is that in the next 2 years we could see a complete paradigm shift in our approach to B2B.
Key Technologies:
UDDI www.uddi.org
EbXML www.ebxml.org
UN/CEFACT www.uncefact.org
Netrana www.netrana.com
Jabber www.jabber.com
Groove www.groove.net
Consilient www.consilient.com
[ << One, Few, Many Analysis ] [ Weblogs for Business >> ]
[ 0 comments ] [ G ] [ # ]
The last few years have seen a series of attempts to build B2B systems that are fundamentally centralized. The belief was that B2B could be handled most effectively by imitating eBay and building a single central marketplace site that brought buying and selling organizations together in one place. This became known as the "Fat Butterfly" model; wings of buyers and sellers linked by a fat market in the middle. At the same time, the principal vendors were also producing e-procurement systems aimed at the internal needs of large corporations. At the core of both of these types of systems is an aggregated catalogue of products, suppliers and prices. While this has been happening, the suppliers have been putting their stall out on the web with storefront systems, that also hold a catalogue of product information.
The competition between these different approaches and the many implementations of each, have led some observers to predict a major shake out in which only one market remains in each major industrial sector. But the reality is actually increasing fragmentation as more and more players implement one of the systems. This is beginning to expose some fundamental flaws in the approaches as the buying led systems find it impossible to sign up suppliers and as the suppliers find themselves expected to hand over their data to multiple buying hubs whether they be public markets or private buying systems. Even in the most commoditized products, where a true Exchange could be expected to work, we find that there is often only a handful of traders who actually transact between one another. Then there are the scalability and reliability issues involved in running a single hub for a large number of companies. If the hub goes down the entire trade through the hub stops, where as in a decentralized system, if one node fails only trading with that node stops.
If we stand back for a moment from the immediate past and look at the relationships involved this begins to look less like a hub and spoke model and more like a web of more or less temporary point to point links between organizations. These links maybe the result of an initial approach between buyer and seller, or they maybe a long standing relationship. The underlying product data is generated and maintained by the supplier and needs to be linked with the supplier's own back office whether it's their engineering, stock control, manufacturing control, marketing or accounting departments. Solutions to these problems have been suggested such as "punch out" to allow searching of a supplier's catalogue from within marketplace software or links between hubs to offload requests to another market if they cannot be satisfied within the current one. But these begin to look like band aids that don't really address the real problem.
All this suggests that we should be creating systems that leave the data where it is and support trading from business peer to business peer. With all the publicity surrounding the music and file sharing systems such as Napster, it is tempting to compare this with them and call it P2P but this is likely to just confuse the issue. Any business critical trading system is unlikely to be allowed direct desktop to desktop connections and in any case there are technical problems with firewalls and security which work against this. But business peer to business peer systems that talk server to server may be possible.
This sort of approach is going to require widely supported and implemented standards if a critical mass of companies are going to take advantage of it. It is essential that systems from many vendors and implemented by many companies can interoperate if this is going to work. Thankfully there are two families of standards that are nearing completion and beginning to be supported by the software vendors. The first is the UN/CEFACT, OASIS, UDDI and ebXML family. This is an all encompassing set largely based on XML. It includes standards for product descriptions, standard transactions, a protocol for server to server communication and a searchable index of services or functions exposed by servers. This is most of what we need to build our web of servers and organizations. This family of standards has the support of most of the major vendors including IBM, Microsoft, Ariba and so stands a good chance of succeeding. The second is the CPFR, VICS and BPMI initiatives, again XML based, but focussed on collaboration between companies in the areas of planning, forecasting and business process links.
Collaborative Commerce is not just about transactions. There are numerous cases where an employee in one company needs to collaborate with an employee of another company. Of course, the killer application for this is email and we now think nothing of communicating outside our organization with this tool. In recent months, a number of decentralized systems have begun to appear that address collaboration between small groups of people who are geographically spread and in different organizations. Perhaps the most well known is Groove that provides something like Notes, but companies like Jabber and Consilient are also working in this area. These systems provide more structure than email but still with the ease of installation and lightweight of a desktop application. If any of these really take off then we can expect them to appear in organizations via the back door, regardless of what central IT would like!
In summary, centralized systems have some inherent problems that are working against wide spread adoption of B2B. They make it hard for the suppliers, without whom there is no trade. They are large and heavy weight with the attendant high costs of implementation. They force the system operators to be involved in collating, updating and maintaining catalogue data that is actually owned by someone else. And they have limitations in scalability and reliability. By contrast, a de-centralized system supports the real world of constantly shifting relationships between companies. It leaves the responsibility of maintaining the data with the source of that data. And it distributes the points of failure so that the impact of the inevitable system downtime, are limited. The standards required to support all this are maturing fast and almost ready for prime time. The end result is that in the next 2 years we could see a complete paradigm shift in our approach to B2B.
Key Technologies:
UDDI www.uddi.org
EbXML www.ebxml.org
UN/CEFACT www.uncefact.org
Netrana www.netrana.com
Jabber www.jabber.com
Groove www.groove.net
Consilient www.consilient.com
[ << One, Few, Many Analysis ] [ Weblogs for Business >> ]
[ 0 comments ] [ G ] [ # ]