Community - Blog

Ten years ago I took on a design and deliver role as the architect of the B2B system for the about to be privatised Victorian gas market. About ten minutes into my work - well maybe a little more - the Program Manager came and said ‘so what message transport mechanism are we going to use’. I hedged. I wasn’t ready to answer that question yet, I had some ideas but I didn’t have the right arguments. It was a hard problem. Still is.

I had ebXML in mind as the market solution, but I was uncertain of the reception it would receive - the market participants (the utilities) were split between wanting a refinement of the mind numbingly awful FTP system in use in the electricity market, and a bespoke Web Services system based on addressing elements embedded in aseXML (the industry standard XML schema). Both ideas loomed as software disaster stories waiting to be written. Then the Program Manager asked ‘Have you considered ebXML’. I was startled - firstly he knew about it, secondly the door was ajar - the possibility was there that I could get Management support in specifiying ebXML.

I seized the moment, management backed me. Along the way there were management waverers and heated arguments with participants - but today history records the decision as a complete success. Energy markets throughout Australia have adopted the specification as is - it has provided a very low friction technology enabler to market communications. It has let the market participants concentrate on developing their business efficiencies in the retail contestable markets and not have to devote excessive resources to maintaining cumbersome partly manual systems while arguing with each other about who sent what to whom and when they did that. With the enormous volume of transactions across this B2B system this is absolutely paramount.

Fast forward to late 2010, with the introduction of the National Broadband Network to Australia. I was engaged as a consultant to devise a B2B strategy for the interchange of data between NBN Co and the Retail Service Providers (a RSP is a full service ISP). As far as the interaction scenarios go between participants here, this is a much simpler problem than the ‘many-to-many plus market operator’ interaction scenarios present in the utilities market. Here the NBN is the single wholesaler dealing with many RSP’s. Nonetheless the need for bullet proof reliability against massive message numbers, and the need to have unarguable message outcomes is paramount when you have marketplace competitors participating as trading partners on the same B2B system.

Eight years had passed since the gas market went live and I think any technology that runs for 10 years must just about be ready for generational change. But I was wrong. A small group of us really challenged the idea that ebXML could still be the right framework for this. We had discussions internally and then looked internationally at similar domains in different jusrisdictions. The most complelling validation came from the the 2009 work of the Network Interoperability Consultative Committee (NICC) in the UK. The NICC (http://www.niccstandards.org.uk/files/current/nd1622_2007.pdf) is the standards body that among other things, put in place the specifcations for these B2B interactions in the UK broadband rollout. More than anything I suppose the fact that ebXML remains the right solution highlights the maturing of the ICT industry. The reality is that there are some things that there is just no reason to change. TCP/IP is a good example. This foundation specification is the rock that our whole internet and telecommunications fabric is now built on.

In the intervening ten years we have of course had the total acceptance of and demand for enterprise open source products. And ten years in the making, the ebXML specification is seeing an adoption renaissance. Suddenly the ebXML transport is becoming ubiquitous. But there is a vacuum in the provision of a supported open source implementation of the ebXML MSH 2.0 specification. Hence the base2Services work on SciDom. Effectively this commodifies the ebXML gateway business. Not many want to foot the bill for a black box proprietary offering from IBM or Software AG or similar, and this in part has been one of the great obstacles to the growth of ebXML. An open source product that has an enterprise support model like JBoss or FuseSource is what most of the world needs. Organisations need to be able to put a toe in the water, and then grow that into their enterprise solution. It shoud be that an ebXML gateway can be a straightforward commodity, like JMS on Apache MQ, or ORM on JBoss Hibernate, search from Lucidworks SOLR-Lucene, and so on… That is precisely what the supported open source SciDom offers. ebXML has come into the daylight.