Tackling ISOs and FTRs

From a development roadmap point of view, Molecule's decision to connect with ISOs and value FTRs was a bit of an outlier. We tend to have a solid understanding of what our customers want, and we use this insight to build features with wild-eyed speed and focused precision. ISO connectivity and valuing FTRs came about in a different fashion, however.

As Sameer, our CEO, and I sat in a room (OR at the table with eight execs representing one of the largest European utilities), the conversation unfolded in an unpredictable way. Deal capture and risk is our bread and butter, so we demonstrated how Molecule automates as much as possible. We believed we had nailed everything around what they could possibly need from a risk management platform, and we felt we had won the room. Our free implementation and implementation time frame (typically 90 days or less) was the icing on the cake. It was a great meeting.

Then someone asked about ISOs and FTRs. At the time, we did not have this feature. The challenge was laid out. Could we add that in the 90 day implementation for a deal to happen? As Sameer considered the industry's need for features around congestion, I held my breath. As you can surely guess, the answer came swiftly: yes.

Our in-house Development Team started banging out code before the ink could dry on the deal. Starting with SPP and PJM, we dived deep into valuing FTRs.

During the implementation process, Molecule aimed to provide support for FTRs, Virtuals, & day ahead power. The challenge landed on the lap of our SVP of Engineering, Paul Kaisharis. Speaking with Paul, he was quick to discuss the challenges around delivering our new solution: "understanding the domain terms and normalizing those terms as well as the implementation across the various ISOs." He was equally quick to discuss what he was most proud of: "creating a standard implementation that allows us to add support for a new ISO in just a few days."

Kyle McRoberts, a key member of our Customer Success team, chimed in as well, "I’d say the most challenging and rewarding part of the FTR implementation was simply the volume. Right now we have close to 7,000 paths available in Molecule, each with a peak and off peak product. The other challenge is that we simply don’t know when new paths are needed until the auction results are posted. We’ve got a process in place now to create new paths when needed (for example, over 500 today) mostly without the customer knowing they needed to be created."

Joe, our VP of Customer Success, was another integral piece in the FTR puzzle. He said, "the challenge: the large number of moving parts involved in this implementation and putting them all together working with multiple vendors as well as divisions within the client organization. What we are most proud of: implementing FTRs with a large number of paths with multiple ISOs for a big multinational company in a short period of time."

We are by no means a custom shop. Molecule builds modern deal capture and risk for everyone. Every customer benefits from our two-week release cycle with free updates and support. Paying for 'future code' is absurd to us. We love our customers. And we listen to them. We take their suggestions and look at the industry with the future of commodity trading in mind. Then we build kickass tech.

What's next? Physical scheduling. Stay tuned.

Molecule's Software Release Process

One of the (many) reasons why true cloud technology is currently the best software platform for enterprises is that providers can regularly push updates and improvements to the software without the customer having to do anything on their end.

One of the (many) reasons why Molecule stands out for energy traders is that we release new versions of our software roughly every two weeks. Our customers don’t have to take any action to get the latest version nor do they pay any extra fees to get new software that frequently.

I recently sat down with our VP of Software Engineering, Paul Kasharis, who we hired in part to ensure that we lead the industry in testing rigor. Here are the highlights of our testing process.

Our testing process is comprehensive, intensive, and automated.

About 90% of our code is tested automatically, every time a change is made (at both the method-level and whole-application-level). Static analysis tests (for security) are run at the same time. Our developers also peer-review every change for approach, performance, and security. Then the team who requested the change, acceptance-tests it. After that, our CS team sanity-checks the whole of Molecule, for security and functionality.

Finally, we back-test a year’s worth of data to make sure that positions and P&Ls don’t change — to make sure we didn’t change something that can affect users’ numbers. We test use cases and business scenarios to make this as robust a process as possible.

We do this, over and over again. Every. Two. Weeks.

Development might be faster in the short term, if we didn’t take this heavy of an approach. But, we value quality extremely highly. We want to release software that delivers the right numbers, right out of the box, every time. Our goal is Zero Customer-Discovered Surprises.

Many competing software companies don’t use such a rigorous process. They rely on people to spot errors. To make development faster (and cheaper), they don’t use unit- or feature tests. Nobody, but nobody we know backtests old data for quality purposes.

Why is this important to us?

Not only are we offended by the ridiculous implementation and upgrade fees that some legacy providers charge, but we also believe that enterprise software should be just as beautiful and fun to use as the apps on our phones. We also believe that software hosted in the cloud is the best technical solution for enterprise customers — from enhanced security to not having to live with bugs that can be easily fixed.

We truly believe that beautiful cloud software is the right thing to provide to our customers. You can read more about our core values here.

Counting Down to ComRisk 2018

London’s calling. Again. Sameer and I are heading over to England for ComRisk 2018 at the end of the month. This is Molecule’s second year to attend and sponsor, and we’re excited to be back!

Commodities People organizes a series of events that are fantastic, educational, and networking opportunities for people working in commodities trading and risk.

You’ll have two opportunities to hear from Sameer at the event:

A panel discussion on the first day: CTRM technology – Adapting to a changing trading environment
Synopsis:

  • System implementation project management: Who is involved
  • Establishing clear objectives: What do you expect from the system? What sort of timelines are you looking at?
  • Critical steps of development, whether in-house or off-shelf products
  • Integration with the existing systems: Challenges
  • Examples of successful implementations: What were the key success factors?

A workshop on the third day: Market risk: Best practices

  • Evaluating Market Risk
    • What ingredients do you need?
    • What does it take to assemble those ingredients?
    • What does your company look like, when those ingredients are assembled?
  • Risk Metrics
    • What do people ask for?
    • What's trendy?
    • What are people actually using, and how?
  • How do people use a VaR?

We’re also always up for grabbing a bite and/or a pint, so let us know if you want to catch up. Email me at sales@molecule.io to set up a time to meet. Look forward to seeing you there!

Welcome, Paul Kaisharis

Paul-Kaisharis Buy me some peanuts and crackerjacks because 2018 continues to be a whirlwind year for the Molecule team. One of the coolest additions to our disruptive talent line-up is our new SVP Software Engineering, Paul Kaisharis.

Earlier this year, Molecule welcomed Paul, and we are delighted that he hopped on board to run our development team.

Remember when the Astros brought on Justin Verlander? Okay… we’re not approaching the end of a sports season and there was no impending trade deadline, but we’re still pretty pumped about Paul joining our team.

Both Molecule’s CEO and VP of Design worked with Paul in previous positions. Jay, VP of Design, was quick to endorse Paul as a candidate by simply stating, “he’s good people.” Sameer, our CEO, added, “Paul has an uncanny ability to spot hot companies in our industry and join them just as they are about to blow up.”

That’s right. Molecule is about to dominate in all divisions. In the most awesome ways imaginable. Paul’s addition to our line-up brings more home run hitting power to a team that is consistently beating its nearest competitors in every inning.

Plus, the guy has one heck of a batting average. In 2006 Paul joined SolArc and helped shape the software that was eventually sold to OpenLink. Paul’s next stop was SunGard where he managed massive product development teams. Most recently, he was the Global Head, Product Development for Energy with Fidelity Information Services.

Pedigree aside, Paul brings a disciplined development process to complement our bleeding edge tech. He has a tech-agnostic view that fits our open source core values. And for those keeping score, we are dead serious about our VALUES.

We see good things on the horizon with Paul on the team. 2018 is the year Molecule swings for the fences and takes the pennant. Now, about Kate Upton...

CTRM Radio Episode 2 - CTRM In The Cloud

Sameer, Founder and CEO of Molecule Software, recently joined Patrick Reames and the Commodity Technology Advisory team in their latest podcast to talk about the adoption of cloud technology in the energy trading and risk management industry. As co-host, Dr. Gary Vasey, points out at the beginning of the episode, there are differences in what some vendors mean when they use the term "cloud."

Check out the podcast here.

While the entire podcast is worth listening to, if you want to skip ahead to Sameer's section, start playing at about 7m25s.

Here is what was said in case you prefer to read:

To us, what cloud means is software that works like the other really great software you find on the internet, like Gmail. So, under the hood, that’s a multi-tenant delivery model, that is easy sign up and integration, and that is somebody else monitoring uptime and guaranteeing throughput and really reaping all the benefits of a multi-tenant solution.

Do you find that multi-tenancy capability or delivery model to be an advantage in a sales process?

It depends on the person. If the person is simply wanting to no longer pay for physical servers at their premises, well that’s a hard conversation. However, if the person gets the nuance of what other cloud solutions that are good software on the market do, it’s a much easier conversation. We’ll talk about things like the support that we can provide because we are a cloud solution that’s over-and-above what any single-tenant cloud vendor could do.

A great example is: our support team here in Houston has an automated report that runs every morning that shows them if something didn’t mark. That would be much harder to do with a single-tenant solution hosted on… hosted anywhere. For us, it’s as easy as whipping up a report. We can find out what didn’t mark and potentially fix the problem before our customer even sees it. Or, call them and say “hey, we noticed something weird about your portfolio. Think it might be because of this. Think you might want to fix that.

Many thanks to the ComTech Advisory folks for talking to us about cloud technology. We could talk for weeks on the subject, so look forward to joining you for another episode soon!

ComTech-Podcast-Cloud-CTRM