Let's Share

The Dark side of the RFP Process

We recently received a Request for Proposal (RFP) from a small, startup energy trading company. They are soliciting proposals from "established" firms to provide energy trading and risk management (ETRM) software and will select a vendor based on several different factors. As seems to be standard practice in the energy trading technology industry, I have limited clues on what will win this proposal for us.

To be honest, we were damn surprised when we received the RFP. I have a hard time with the term "established vendor", and the client provided a laundry list of requirements -- many of which our software does not have a (current) way of handling. The RFP goes on to state that the selected vendor will provide "turnkey access" without any further development before implementation.

I applaud the ambition, I really do. I'm even starting to believe this is a client after my Molecule heart. A turnkey, ready-to-go solution would be a dream come true in any situation, had it not been for 45+ other technical, functional and reporting needs the client "must have" on Day 1, in order to make an affirmative decision.

At this point, my mind starts to think and wonder, and ask why?

  • Why have RFPs crippled this industry and the decision marking process that follows?
  • Why on earth would anyone need all of this software capability on Day 1? At that point, a startup has 2.5 employees, and no trades. Thinking 5+ years out is ambitious, but can cripple your sense of understanding what you need Day 1, and the software flexibility and features you might want for down the road as your needs evolve.

I can think of a few reasons.

  1. It is very easy to follow the pack.
    If every ETRM-buying firm is putting out an RFP, why can't we? It becomes really easy for firms in this industry -- big and small -- to keep the status quo. It is the easy answer. Why veer off course and try to do something on your own when you know a dozen (or more) vendors are panting to respond to your wish list of ridiculous requirements?

    You might as well test them to see how high they jump, or how quickly they will lower their price to win your business.

  2. Locking in Price looks awfully like locking out Risk.
    As the client, you have the ultimate say. And if you're wanting a commitment several years out, why not push hard on price? The problem is, when scope is murky, getting someone to commit to a lump-sum price is simply amplifying the risk that things will go badly wrong.

    At Molecule, we have long offered month-to-month pricing. However, the market often dictates long-term deals. We see 3- and 5-year commitment requests come across our desk all the time. That's not a bad thing in an ETRM software industry long known for its bad behavior. But locking in a price when scope is wide open, will not end well for anyone. In fact, it incentivizes vendors to be misleading.

  3. Shoot for the Moon. Even if you miss, you'll Land with the Stars.
    There seems to be a sentiment that if you ask for every feature you might ever need, you'll end up getting more than you would have otherwise. Sadly, that's not how good software works. In good software, unused features get removed--so that developers can focus on making the things you do use, stellar.

    As hard as it is to figure out what you need on Day 1, it is really important. Why pay for more? And if you don't know, it's OK to be vulnerable and share what you are trying to figure out. The absolute wrong answer is to revert back to point #1 and undergo a process that will only make the decision murky, the process prolonged, and ultimately, have you stuck in a marriage that you committed to based on the prettiest (and longest) PowerPoint, all for the sake of optics.

    If you're running the process at a supermajor, we totally get it (though we disagree) -- you have many bosses and can't leave a single stone unturned. But if not, there really is no excuse.

Nasdaq NFX: Why is it so Hard?

In the last year, we've had customers interested in trading on Nasdaq's new NFX exchange. From what I can gather, NFX has been a price leader on super-liquid contracts, and traded volumes have been growing regularly.

But we don't connect to Nasdaq currently -- either for market data or for trade downloads. The reason is simple: it's way too expensive. Last I checked, connecting to NFX for drop copy requires:

  • A physical server sitting in Carteret, NJ, or
  • A hardware VPN connection using a physical Cisco-branded box.

Getting end-of-day market data requires something similar. (edit: not anymore!) This is hard for a number of reasons, not least of which is cost. Buying a Cisco-brand VPN box costs money. Getting a service contract for it costs more. Finding a specialized engineer for Cisco hardware adds to that price, and renting space at a server farm willing to house your little Cisco box costs even more than that. All of this, of course, is far less expensive than leasing a slot in Carteret.

This is all ridiculous, because:

  • End-of-day market data is not anything secret. In fact, according to our friends at ICE, it's public information under the Commodity Exchange Act.
  • Trade data is secret, but both ICE and CME provide adequate security through their FIX APIs. The CME even has an awesome new API that we've made an open-source adapter for.
  • Requiring a hardware VPN completely rules out the use of services like Amazon's AWS, which is the virtual data center that pretty much every tech startup I know, uses. Doing so requires tech companies to build out a whole set of server infrastructure, just to connect to Nasdaq NFX.

I'm not sure why all this is the case. The most apparent reason is that Nasdaq relied on legacy, proprietary, low-latency equities infrastructure when they launched NFX.

That's massive overkill for most of the customers we've seen in energy. We hope the guys at Nasdaq will make their services easier to connect to -- ditching the hardware VPN requirement for drop copy, and making end-of-day market data public, the way ICE and CME do. We'd love to add seamless NFX reporting for all of our customers. Making it easier to do, would help us do that.

Update, October 20, 2016:
Nasdaq has now made their end-of-day market data public. Thank you!

Reporting in SaaS

Some of the key benefits of true, multi-tenant SaaS rely on the fact that all users run the same version of the software. As a result, they:

  • Are always on the latest version
  • See fewer bugs
  • Get bugs fixed quickly
  • Pay less, because their software isn't customized

That's something that's always been very important to us as an enterprise software vendor. We were warned about this when we started Molecule -- that people in the ETRM industry all want different things. What we found was slightly different from that sentiment. ETRM buyers generally want the same functionality. They do, however, want bespoke reporting.

So, in Molecule, we've spent a lot of time making sure our reporting customizes (even though our code doesn't). To that end, we make pretty much everything in Molecule available in three different ways:

  • On Screen (Standard). Users see a report whose X and Y axes are standard, but that has lots of sorting, filtering, bookmarking, and drill-down capabilities.
  • Dashboard (Customizable). We've integrated a business intelligence (BI) solution into our app. That enables us to build custom, screen-based and e-mailable dashboards for just about any data our app holds. These are customized for each customer. Thanks, Looker!
  • API (Bespoke). Technical users can access just about any data for their account, through our JSON and CSV APIs. These are easily integrated into Excel, as well as downstream systems.

Because our reporting is customizable, we can make sure the core logic in Molecule is sound, tested, and updated frequently--while our users get exactly what they want.