is now the time for open source in ctrm

IS NOW THE TIME FOROPEN SOURCE IN CTRM?

WHITE PAPER

© Commodity Technology Advisory LLC, 2014

Introduction IN THIS COMTECH ADVISORY WHITE PAPER, WE TAKE A LOOK AT THE CONCEPT OF OPEN SOURCE SOFTWARE IN COMMODITY TRADING. IN DOING SO, WE ARE ASKING THE QUESTION, WHY HAS THIS APPROACH NOT YET BEEN TRIED? AND IF IT WERE TO BE TRIED, WOULD IT HELP? THE WHITE PAPER IS REALLY DESIGNED TO FOSTER DEBATE AROUND THE TOPIC AS OPPOSED TO TAKE A STANCE ON THE ISSUE ONE WAY OR THE OTHER. ACUTELY AWARE OF THE MANY CHALLENGES FACING BOTH USERS AND VENDORS IN THIS FAST MOVING AND COMPLEX BUSINESS, COMTECH ADVISORY IS ALWAYS INTERESTED IN PURSUING RESEARCH INTO HOW TECHNOLOGY ADOPTION MIGHT BE IMPROVED. THE QUESTION POSED BY THIS WHITE PAPER IS SIMPLY THIS – IS NOW THE TIME FOR OPEN SOURCE CTRM?


A ComTech Advisory WhitepaperIs Now the Time for Open Source in CTRM?

IS NOW THE TIME FOR OPEN SOURCE CTRM?

It’s also true that as the software category has grown – and we estimate it’s a $1.6bn industry this year – some vendors have thrived and now have triple or double digit million dollar revenues. Vendors such as OLF, Triple Point (acquired it-self by ION last year), Allegro, SunGard Energy, Brady and EKA are all reasonably sizable com-panies but there remains a whole raft of smaller niche vendors happily serving specific needs, ge-ographies, or commodities, both small and large, across the breadth of the market.New or old, every one of these vendors initially set out to do something unique. Each markets them-selves as being somehow different and better than those that have gone before – cheaper, faster, more sophisticated, more reliable, faster to implement…and the list goes on. In fact, by building on the latest available technologies, they may indeed be an ad-vancement of the state of the art in CTRM technolo-gy. However, at their core, each and every new prod-uct that comes to the market starts by defining and modeling the same basic components of commodity

trading. For example, to simply capture a deal in a CTRM system, the following information (and more) must be defined in the code and input by the user:

Here we are in 2014, almost 20-years after the ETRM and later, the CTRM, software categories were ‘invented’ and in some ways, very little has actually changed. Yes, there has been some vendor consolidation, but for every vendor and solution that has been acquired or gone out of business, at least one new supplier has consequently emerged. We seem to have been writing that ‘there are over 70 vendors of E/CTRM software’ for the last 10-years at least and it’s true – there really are that many in the CTRMCenter software directory. In fact, we have found and added 3-4 new ones this year alone!

/ commodity

/ counterparty

/ contract

/ deal

/ term

/ deal type

/ price

/ volume

/ location

/ facility, such as a pipe, wire, truck, train, vessel; each with a number of other attributes that have to be defined and coded…

Every new system that is brought to market starts out with a database that is that actually the vendor’s interpretation of very common attri-butes and “sub-attributes” such as names, phones numbers, email ad-dresses, physical addresses, currencies, and the list go on. So why are vendors constantly “recreating the wheel” of commodity trading every time a new product is launched?



NO COMMON LEXICON

Anyone that has tried to integrate two different sys-tems from different vendors, or has tried to move data from a system from Vendor “A” that is being replaced to a new system from Vendor “B” will have encountered the impact of these different views; and if a system was actually found to move transaction-al data across, it will almost certainly have required hundreds or thousands of hours of human interven-tion to reconcile the differences between the two systems. This is why it is exceedingly rare for any software customer to move historical transactions from one vendor’s system into another. Given this lack of a common lexicon for commodity trading systems, every system in use to-day reflects the definitions that their developers un-derstood based upon their specific experiences; or that they otherwise believe will be either easiest to code or will best reflect what their prospective cus-tomers may want to see. This means that is unlikely that any two systems will reflect a singular common understanding of the market. The result is that every system, though they may use similar languages and terms, reflects a unique way of capturing very basic and fundamental information that is otherwise com-mon to the industry.

Part of the reason is that while you can find dictionary definitions for each of these attributes, there is no common lexicon across the commodity trading industries. For example, a deal can mean buying or selling, to a counterparty, a specific volume of a specific commodity on a specific day, and at a specific point; or it could mean a buying or sell-ing to a counterparty, a specific commodity at multiple locations, each with a different price across multiple days, weeks or years. This difference, while not appearing on the surface to be consequential, actually has fundamental implications on the way the deal is priced, tracked, valued and settled within a software system.

This lack of a common lexicon reflected in the underlying data structures leads to wasted time and resources by both the soft-ware vendors and the users of these systems. The vendors recreate what has been previously built by their competitors as they build-out this code, and the customers are forced to learn the unique methods and data structures used by the vendor in order to build and maintain complex integration infrastructures to move data in and out of the sys-tem, or to even develop reports that detail the deals and transactions in the system.



SO, IS THERE A BETTER WAY?

WHAT WOULD OPEN SOURCE IN CTRM LOOK LIKE?

Each company would contribute their interfaces and other improvements into the product (inci-dentally, you can still find the code for EnyWare here: www.sourceforge.net/projects/enyware). TradeWell would make money by selling support, much like Redhat maintains a supported version of Linux. While the company ultimately wasn’t success-ful due to limited funding, the vision of open source in ETRM/CTRM is probably even more intriguing today. Just what would happen if one of the new or existing ETRM/CTRM vendors decided to throw their product, in a stripped-down or basic version, out into the market for free as open source code? Certainly, most trading companies, regardless of whether or not they are currently using some other vendor’s product, would want to see what it’s about

At most, we would expect any CTRM packaged solution to be only a 70% to 80% fit to any individ-ual company’s requirements. This means that every installation has, by necessity, a high proportion of

and would probably bring it into their shop to take a look at it. If the open sourced “product” was able to address the fundamental needs (like con-tract and deal capture) of enough market participants, and had a clear and easily extendable architecture, then it is certainly conceivable that more than one would think about what they could do with it…even per-haps up to replacing their expensive vendor supplied systems. Others, including those that didn’t have a system or were looking to replace their existing system, would be remiss if they didn’t at least take a look at how they could use it, and in the process, save a significant amount of money on the front-end by avoiding the license fees that normally come with such systems. Should such a scenario play out, it would certainly disrupt the CTRM software industry. Instead of building new products from the ground up, software vendors would need to concentrate on developing the tools and capabilities that ultimately distinguish one vendor from another – things like sophisticated analytics, regulatory reporting and complex multimodal logistics models.

custom add-ons, components and other functionality. Vendors have to target a large enough portion of the available market to sustain them-selves by building in significant configurability and personalization in or-der to avoid a good deal of specific client customization but, at the end

Several years ago, a company called TradeWell Systems sought to launch an open source version of their ETRM integration product, called Enyware. The vision of the company’s president, Andrew Bruce, was to provide an open source product that, once interfaces were developed to the various ETRM/CTRM products commercially available at the time, the market would quickly adopt as a standard integration hub for the industry.

The idea that each market participant’s needs and therefore their installation, is essentially different and hence, this can’t be seen as a true package market, is an idea we have expressed on many occasions over the years.

http://www.sourceforge.net/projects/enyware



of the day, it still is less than a 100% fit to require-ments. In following this approach, vendors struggle to build out, on top of their own version of their indus-try model, a complete multi-commodity, multi-geog-raphy E/CTRM solution; and as they build out this ‘blob’ of functionality on that unique interpretation of the industry, it becomes harder and harder to main-tain and support. We have seen this so many times in the past that it is “old news”. Eventually, legacy vendors and products lose their agility to react and adapt to market changes or developments, and in so doing, an opportunity emerges for ‘five guys in a ga-rage’ to build a new solution on the latest technical platform and off we go again.

So to revisit and rephrase the question posed earlier, “What would happen if someone started giving away their source code in the same way that operating systems like Linux, DBMS technologies like MongoDB and even predictive analytical tools like ‘R’, are given away?” There’s no question that a disruption in the ETRM/CTRM software market would occur and that some vendors might not be able to react quickly enough or appropriately. However, as proven by RedHat and others, there are other ways to make money with open source software. Late last year, for example, MongoDB Inc. raised $231 million, and be-came the first billion-dollar open source startup. For the existing CTRM vendors caught up in a wave of open source adoption, quickly accepting and becoming expert in the new standard would be key. This would allow them to rapidly produce and implement new components that would reach and capture a very large and emerging market.

NEW SOFTWARE APPROACHES IN CTRM

We’ve previously noted that true SaaS CTRM is actually a very rare thing; even for those customers with only the most basic functional needs, as very few companies are comfortable having their data in-termingled in the same instance as one of their com-petitors no matter how secure the environment is, or how many checks and balances have been built in. Rather, we see CTRM adopted as hosted in the cloud (meaning that rather than all clients use the

same software, each client is using a different instance) and almost cer-tainly utilizing some degree of customized functionality. After all is said and done, this type of deployment hasn’t really changed the dynamic of the industry, as much as it has changed the way that companies pay for their software and receive support. That’s not say that the model isn’t working, it certainly is and for a variety of other reasons, cloud-delivered software will grow. It’s just that it doesn’t actually solve the myriad of fundamental issues around E/CTRM soft-ware that we’ve discussed above.

The CTRM space is already seeing the advent of fresh ways of delivering software to this market…in particular, via the cloud. However, we are not totally convinced the cloud will do much to fundamentally change the nature of this market when it comes to addressing the shortfall in capabilities experienced by software users.



HOMEGROWN SOFTWARE MAKING A COME BACK?

BUT OPEN SOURCE?

The trend has been confirmed by head hunters who tell us there is a great job market developing among the companies that have turned to in-house develop-ment to meet their specific needs. While these com-panies can find specific point solutions to address individual commodities or classes of commodities, they have little confidence that a vendor supplied solutions will meet their requirements. To some extent, this trend can be seen as a step backwards, swapping lower cost and increased

In effect, the industry has at times, perhaps unwit-tingly, flirted with this model via industry consortia such as EFETnet in Europe and GISB in the USA. However, none of these efforts actually resulted in open source applications being developed. While an open source CTRM may seem un-likely at least in the near-term, we suspect that such a model could result in a number of positive devel-opments for users, including faster development of

convenience for a better fit to requirements. Certainly, it is not an option open to the vast majority of companies that in one way or another trade commodities and require a solution. Arguably, the market is growing as regulations in particular net increasingly smaller commodity traders who in the past may have been more than happy to rely on spread-sheets or some other cost effective, but difficult to audit, approach. In this regard, cloud-based and other non-traditional deployment options are likely to be very attractive.

new and richer functionality, the ability to better interface and integrate with other applications and potentially the development of new, indus-try-wide capabilities such as standardized and efficient networks for deal exchange, confirmations, scheduling and settlements. The most agile and forward thinking vendors would continue to thrive by assem-bling branded applications that build upon the open source core capa-bilities, and could better differentiate themselves from their competition by focusing on delivery of sophisticated tools and analytics.

As buyers realize that perhaps there simply isn’t a packaged solution that will fit the majority of their complex requirements, homegrown development is once more gaining in popularity; especially among larger companies in areas like agriculture and softs where there are a plethora of niche solutions but few that can meet the specific requirements of a shop that trades a broad range of commodities.

So what would happen if we all simply recognized that every customer is different? What if the “industry”, both users and developers, launched an open source library that everyone contributed to? Would this work? Would it spell the death knell of the vendors in the space?



OF COURSE, IT MIGHT NOT WORK

As we’ve noted many times before, there is no one size fits all solution in the CTRM markets. If large number of companies, spanning different markets and commodities, starting pushing additional func-tionality back into an open source product to meet their specific needs, the product may become too bloated and complex for those companies seeking a cheap and easy solution to address their limited re-quirements. As these smaller or even mid-sized com-panies turn away from adopting open source CTRM, the product could lose support; Without constant improvement and continuing adoption, open source products can simply fade away, abandoned in repos-

itories such as SourceForge and forgotten by almost everyone except those that were the early adopters. And for those early adopters, should that happen, the once promising vision of a shared solution would be-come the reality of just another custom developed software program. Open source software is also not without its own set of admin-istrative and support issues, including availability of quality technical support, code quality, documentation and licensing terms. All of these potential issues would need to be addressed very visibly and with a guarantee of some sort of governance by the open source community in order for the industry to even look at such an initiative. Plainly, open source may not be a panacea of good things for the industry but the question remains – is now the time to give it a try?

It could also be argued that an open source strategy in this market is destined to fail, either by not achieving enough adoption (companies with regulatory or shareholder exposure are historically suspicious of freeware, particularly for critical systems), or perhaps even falling victim to its own success if there were widespread adoption of the opensource product.

ABOUT

Commodity Technology Advisory LLCCommodity Technology Advisory is the leading analyst organization covering the ETRM and CTRM markets. We provide the invaluable insights into the issues and trends affecting the users and providers of the technologies that are crucial for success in the constantly evolving global commodities markets.

Patrick Reames and Gary Vasey head our team, who’s combined 60-plus years in the energy and commodities markets, provides depth of understanding of the market and its issues that is unmatched and unrivaled by any analyst group.

For more information, please visit:

ComTech Advisory also hosts the CTRMCenter, your online portal with news and views about commodity markets and technology as well as a comprehensive online directory of software and services providers. Please visit the CTRMCente at:

19901 Southwest FreewaySugar Land TX 77479+1 281 207 5412

Prague, Czech Republic+420 775 718 112

ComTechAdvisory.comEmail : [email protected]

www.comtechadvisory.com

www.ctrmcenter.com

http://www.comtechadvisory.com

http://www.ctrmcenter.com

is now the time for open source in ctrm

Software