Question: In conversations with several global scale commodities traders over the last few months, ComTech has noted an increasing interest in pursuing internal builds of CTRM systems. The question is why any company, and particularly these top tier players, would build functionality that is readily available in existing vendor solutions, even if it’s not a 100% fit. What are your thoughts and comments on this emerging trend and what would you propose as an alternative approach?
Chris Strickland – There are probably a number of things going on here:
- Too many people have been ‘stung’ by the length and cost of the implementation process for the big C/ETRM’s and are looking to avoid that. For some people moving to an ‘off the shelf’, cloud-based solution might be an answer, but I really do believe that a lot of businesses (or business requirements) are just too complicated to fit in with this.
- Is this something that you are seeing across a wide range of industry players or mainly just global-scale commodity traders? The thing about global-scale commodity traders is that they trade everything and so they need to be able to handle the physical logistics of power & gas & oil & metals & ags & etc., etc. We know that – even though the majority of C/ETRM’s sell themselves as ‘multi-commodity’ – these systems are good at the area where they started, but very average at the things they branch out into. The global commodity players obviously know this as well and so the only real alternative is between multiple different systems or a build your own.
- In our own niche – valuation & risk analytics – we have always seen this internal build model, and it is our biggest competitor by far. Although the reasons are probably slightly different from the above. Anyone with any analytics capability knows that the risk management in all the C/ETRM’s is poor and so many have voted with their feet and built lovely robust… spreadsheets…
- Again in our area, people tend to think risk & valuation is where their ‘IP’ resides – this is probably the number one reason given to me as justification for in-house developed applications and, for the vast majority of organizations, this is where the biggest difference exists between the ‘myth’ and the ‘reality’. There is a perception that by internally developing risk and valuation functionality, IP is retained within the organization and models are built to bespoke requirements. It’s a fact that very smart people almost always build risk functionality. It is also almost always a fact that hardly anybody else in the organization knows what these very smart people are doing – just because they are smart, and you don’t know what they are doing, doesn’t necessarily mean that they are developing IP…
- I believe that there is a complete disconnect between how much in-house development (and subsequent support) costs and how much people think that it costs. The costs of ‘bought’ software though are very ‘transparent’ – and normally quite large, and the in-house extreme is that ‘we already have these IT folks working for us and so doesn’t cost us anything’.
The alternative approach – and this is probably more relevant for our own niche – is a hybrid approach. In the vast majority of cases, it is quantitative analysts alone that are tasked to undertake internal build valuation & risk projects. With such a responsibility, these analysts are unfairly expected to be the “master of all trades” and, as a consequence, the scope of functionalities for risk and valuation tends to have a narrow focus and is often not useable for other groups in the organization. For a successful internal build, an energy organization needs to employ a diverse range of separate skill sets to successfully specify, build, test, and maintain on an on-going basis, a comprehensive risk and valuation application. Individuals with specialist knowledge on pricing assets and valuation algorithms, financial engineering, database management skills and user interface programming are all required. It is rare for all these skill sets to be available with one organization, let alone 1 or 2 individuals. Such a scenario seriously hinders the ability to develop successful applications in the appropriate context.
In my experience, the typical profile of the in-house build team for most energy organizations (again, just focusing on valuation and risk engines here…) is an individual, or two, with an advanced technical degree (maybe a Ph.D) in an area like physics, or some kind of engineering discipline. They are typically a few years out of university, don’t have a background in financial engineering, or stochastic optimization, have never developed a commercial software application and have no prior experience of developing user interfaces (outside of Excel) or linking to databases. They rarely – if ever – socialize their models and algorithms outside of the organization, and their only knowledge of financial contracts and physical assets is what has been picked up ‘on the job’. As a consequence, when I think back to the development of our own application, the level of IP developed ‘in-house’ is often akin to where Les Clewlow & I were over 15 years ago… Anyway, the skills that they do have might be more around individual asset modeling or portfolio modeling for the particular asset operator – they should concentrate on that and leave Lacima to handle all the securities, control’s, audit functions, documentation, etc., and the modeling bits that they plan to get too in 6 months but it will actually take 3 years.
Henry Bonner – OpenLink is seeing that some companies may pursue building their own systems if they feel their business is sufficiently different from what the available C/ETRM solutions offer. The reality is that they are choosing to embark on a multi-year project with multiple man-decades of development required.
Companies in the market for a solution need to consider that a company like OpenLink may have hundreds of developers who can add hundreds of man-years of development to a vendor product annually, significantly reducing the ramp time associated with a “from scratch” development project that a new team could achieve.
Perhaps a better, less risky strategy would be to build their specific requirements onto an existing platform, either themselves, through a robust API, or via the vendor as a product enhancement project (a 3rd party consultant could assist as well). Factoring in time to value, this is a better approach for those who simply must build a solution. In our experience, companies who choose to build their own systems are typically tier one with very deep pockets. We see that emerging players prefer to leverage packaged solutions and best market practices for IT.
Michael W. Hinton – The long answer is, building your own CTRM software sounds great, until you consider that writing software distracts from your core business. Staff requirements and the specialized skill sets it takes to actually write the code, drive the development and maintain the solution are different than trading or business skills. Should any of these key people leave the company, part of your product knowledge leaves with them. By the time the investment ever sees the light of day, some of the technology may have changed. The programming language may be on the way out. Your original scope of needs may have evolved. Next thing you know, you’re on a treadmill going nowhere good and stuck with a solution that is obsolete and you don’t have the budget to make it current.
Partner with a proven solution provider. 80 percent of what you need to manage your business is probably there out of the box. Leverage the expertise of a technology focused company to share the risk of development investment. Technology companies today utilize agile development processes and hosted hardware solutions to deal with the shorten half-lives of software. This brings you flexibility and faster time to market to support a constantly evolving business.
Jan van den Brom – My belief is that there is a combination of reasons for this approach; the most important ones in my opinion are:
- Control – CTRM in general touches the core operations of a trading organization and buyers are concerned about that and often the size of the vendor and prefer to gain full control by self-building,
- The current technology state of many CTRM vendors – Many CTRM solutions are still based on relatively older technologies or non-scalable architectures like client-server. These organizations see CTRM as a strategic asset to move back office work outside their operations; self-build allows them to take the latest technology.
- Disappointments in the past – Many of these organizations tried to implement CTRM solutions off the shelf in the past. There are examples known where it has been tried more than 3 times by the same buyer. Obviously the failure rate has been high, causing a move to self-build.
- Opportunism – Building CTRM is complex, by nature. Maybe even one of the most complex business administration systems to build. A decision for self-build is made when no disappointments have yet been encountered and the future is still bright; until the moment one finds out that the budget is not enough and the time to deliver increases multifold – but, when deciding to self build, that moment is still far away.
The alternative approach here is multifold; component-based CTRM is a solution where CTRM vendors with new technology have an advantage. Partnerships between top-tier trading companies and CTRM vendors leverage existing builds and knowledge. Experience and time is a factor, which eventually will become important, as self-builds do have a high risk profile.
Manav Garg – Although there seems to be a trend of moving away from large E/CTRM vendors, what we’re seeing in the market could be described as ‘old vendor fatigue.’ Some of the large, global companies that have tried one or two E/CTRM solutions from very large, established vendors have had disappointing results with cost overruns and lengthy implementations. In some cases, the project is never completed. Additionally, people hired into a global company from a previous commodities business may have their own horror stories to share of failed E/CTRM projects with their previous employer using a large vendor.
Instead of these global companies pursuing homegrown systems, Eka is being invited in to consult and bid on many of these projects. When companies are evaluating E/CTRM software solutions, they are tired of the same old solutions from the same old vendors. There seems to be a perception that the largest vendors have stale solutions and that the smaller startups can be risky to work with. This provides tremendous opportunity for Eka as we fall in between. As a result, we are finding a lot of interest in our solutions.
The CTRM Thought Leaders can be found on the CTRM Center
