Multimedia
Webinar: Achieving Interoperability in Risk Management
Watch the video to discover best practices for integrating risk management systems and improving data flow between ETRMs, market risk, and credit risk platforms.
February 4th, 2025 | 47:51
Summary KeywordsInteroperability, ETRM integration, risk management systems, market risk, credit risk, data flow, ETRM connectivity, system integration, data interoperability, trading platforms, energy market technology, risk data integration, decision-making tools, cross-platform integration, cloud-based risk management, data automation, tech-driven trading, digital transformation, trading system optimization, ETRM best practices.
Transcript
Gary M. VaseyPhD, Owner, ComTech Advisory/CTRM Center
Steven BroadHead of Product and Solutions, cQuant.io
Ben LafleurHead of Professional Services, CubeLogic
Sameer SolejaFounder & CEO, Molecule
Kari FosterVP of Marketing, Molecule
Kari Foster Well, hello, everyone. Thank you all for joining us today. Wherever you're joining us from, wherever in the world you are. In fact, if you'd like, you can pop that into the chat and you can tell us where you're joining us from today. My name is Kari Foster. I'm the VP of Marketing at Molecule. And today we will be talking about the subject of interoperability of your risk systems, which is indeed a very popular topic because while one could argue that it's a fundamental need, it's still very much a challenge within many trading organizations, and you're probably using a plethora of systems across your trading operations, with even a handful of those dedicated to risk management.
We have a lot to talk about today, so I'll introduce our esteemed panelists and our moderator. Gary Vasey is the owner of ComTech Advisory, and you may be familiar with CTRM Center and the CTRM Market Reports that they produce every year, and he'll be moderating the discussion today; Steven Broad, who is Head of Product and Solutions at cQuant; Ben Lafleur, who is Head of Professional Services at CubeLogic; and last but certainly not least, Sameer Soleja, the CEO and founder of Molecule. Welcome everyone, and I'll pass the baton to Gary.
Gary Vasey Hello, welcome everybody to this, what I'm sure will be a fascinating webinar. And in the 25 years that I've been involved with CTRM and risk management software in the commodities space, this has been one of those questions where people are looking for the holy grail. We've gone from single supplier to best of breed type discussions, and these days because of advances in technology in the cloud and software as a service, we've gone to the monolith to the ecosystem in the cloud discussion. And I think that today we'll touch on some of those points. And to get started, I think what I'd like to do is go to Ben and ask for you, Ben, what are the benefits of a multiple cooperative, of multiple cooperative systems versus a single system?
Ben Lafleur Specialization, mostly, right? So it's kind of a pretty ambitious goal to be the best of breed of just one thing. Anyone who's ever tried to use a Swiss Army Knife for more than cutting things understands this, right? It's much better to have a good knife and a good pair of pliers and a good screwdriver than to try to have one tool that just does them all okay. So the best solutions that we've seen kind of involve you know, systems that are especially good at the one thing. Working together well with good integrations. So it's a hard, like you were saying, it's a hard holy grail to chase after, but when you get it, it's worth it.
Gary Vasey And so, Sameer, if interoperability is as complex as people seem to find it, what do you see that enterprises are doing to combine the data they need and get the full view of things like positions, for example?
Sameer Soleja Yeah, so in cases where enterprise doesn't have one system to rule them all, which is almost everyone, we see people building their own data ecosystems, typically data lakes, extracting as much raw data as they can from each of the related systems and then sort of mashing it together to get a full position view. It's actually a pretty good way to get it done.
Ben Lafleur One system to rule them all. And you can just say Excel.
Sameer Soleja Yes, exactly.
Gary Vasey Moving on to Steven, how does portfolio analytics provide better insights than project analytics?
Steven Broad That's a great question. And, you know, Sameer was just describing a thing that people try to do to come up with the analytics that they need. But one of the kinds of things that they often miss or don't ever get to in the process of doing that, if they've taken this sort of self-service approach, is getting to the portfolio analytics solution. What's valuable about it is that there are a lot of risks and variabilities that we see in energy markets today, maybe even more magnified than they had been in the past, and constructing a well-crafted portfolio is difficult, especially if you're trying to analyze and do analytics on each individual asset, one by one. The portfolio solution allows you to see when assets that are in your portfolio are de-risking each other, maybe through a diversification benefit, or perhaps through a hedging strategy that was intentional, but still very difficult to measure without a portfolio level view.
And so if you're doing the thing that Sameer was mentioning just a minute ago, you might do analytics on a project-by-project basis and try to roll them all up, but the risks aren't, they don't add together like that. Sometimes you can have two projects that, maybe two, maybe wind generators in different locations. The wind doesn't blow the same in both places, so sometimes they can even have a little bit of a de-risking effect. So that's a thing that we like to talk about when we think about portfolio analytics is just that there are, there's extra value that's in there that may never surface if you don't have strong portfolio analytics.
Gary Vasey Right. At this point, I'll just remind people listening in that if they want to ask a question, please do go to the appropriate location and ask the question. I'm monitoring that. I want to just switch quickly to asking all three of you, and we'll start with Ben. In terms of a coalition of best of breed vendors, why do you think a coalition of best of breed vendors is better than a monolithic system? Why do we think that these days?
Ben Lafleur Yeah, it's again, kind of, so it's back to specialization, right? Like as a company, it's a pretty ambitious goal just to be the best in breed at the one thing, right? And most companies that start up fail at that. So, you won't find any, I haven't found any that are, you know, best in breed at multiple things, especially kind of across all the, you know, all the different kind of diverse skill sets that we have represented here on this panel, right? Analytics, CTRM, credit risk, market risk, trade surveillance.
So the best solutions that I've seen come from all of those types of systems that are the best in their particular areas working together well, that's hard to get to, right. Because you know, building those integrations particularly if you're starting with a customer implementation, right. And you just happen to have the set of systems together that you need to talk. There's a lot of communication barriers to overcome, right? Everyone who's ever done a software implementation knows that, you know, you spend the first part of the project just learning to kind of speak the language, you know, so it's, you know, a coalition of vendors kind of implies to me that it's something that's set up, you know, ahead of time. And so you can skip over that, you know, pain in the beginning of the project of getting these people to work together well.
Gary Vasey Sameer, what's your view on that?
Sameer Soleja Yeah, I mean, I think there's a, there are a lot of vendors in our ecosystem with vastly different technology platforms and like, you know, almost at a concept level. And so getting multiple vendors to speak the same language is one thing, getting them to speak the same language from the same place is yet another. There's a number of hurdles there.
Ben Lafleur Just thinking about like, you know, how do you take, like in our space, it's a lot about the logistical differences between the way that physical commodities trade, right? So you can kind of model power as gas that moves instantaneously. But then when you start talking about truck businesses, it's wildly different. So overcoming those differences and finding a common way to talk up front could be a really powerful thing in terms of speeding up implementations and making them more reliable.
Gary Vasey Yeah. Steven, what do you have to add to that?
Steven Broad So, I think that there's another interesting piece to this, which is that what each of these types of solutions do with the data and what the data means may be a little bit different. An ETRM system is oftentimes very focused on being a single source of truth, whereas an analytics system might allow for hypothetical variations on that, and very often those hypothetical variations are extremely important because a person wants to know, yes, there is one system where the truth is recorded, but then there's another system where they can imagine some other kind of alternative outcome and that's what analytics are for.
So, you're going to take your current position, but then you're going to say, well, what if I had this hedge, or what if I had this long term contract, or what if I add this battery storage device? What does that do to the portfolio that I have today? Or even ask a question like, would I have achieved a better outcome in the past if I had some of those things? And a single source of truth is not really usually set up for that kind of hypothetical analytics. So the meaning of the data can be quite different between these different kinds of systems.
Ben Lafleur Yeah, exactly. You could think of it like an ETRM system telling you exactly where you are, an analytic system telling you where you might go, and risk systems, making sure that you can get from one place to the other.
Gary Vasey In terms of having a coalition of vendors, I assume that part of that is each of you guys getting to know the others and pre-preparing for being integrated at a customer site. Steven?
Steven Broad So, I mean, if you were to just look around and find the, you know, a set of vendors that you identified as being highly acceptable. They may or may not have a relationship with each other. And then, you know, your data remains siloed in, in the activities that they were until those barriers are brought down. One of the advantages here is that the team that you see assembled before you, we want to work together and we are working together and we have a history of doing that sort of thing. So we're ready for the challenges and helping people navigate through that interoperability framework. And that's actually quite an important addition to the framework.
Sameer Soleja To be sure, even… Oh, sorry. Go ahead.
Gary Vasey Sorry, Sameer, but just before we move on to you, there's an interesting question, actually targeted at Steve, which is where is the greater value: single source of truth or hypothetical futures?
Steven Broad I think that the great value, the greatest value, is actually being able to do both nimbly. And so, you always have to, it's sort of like the metaphor we were describing a minute ago, you always have to know where you are on the map, but where you are doesn't tell you where you're going. You always got to be able to try to think about directions you could go and destinations you could get to but just knowing the destination by itself isn't the answer either. The combination of the two is really the powerful thing that allows a company, an energy company, to express a vision and to go after that vision without having to worry that some risk is un-, you're unaware of some risk having a holistic view of both your current position and the trajectory you're on to get to your destination. That's really the valuable thing in my opinion.
Gary Vasey And Sameer, you were going to say, sorry before I interrupted.
Sameer Soleja No, I mean, I think the value, I agree with Steven, and I think the value of each of the types of systems comes from a different perspective, right? The value of an ETRM is not in being able to poke at it, it's in that it's always right. And that it models things correctly, and that it's, you know, fast enough, and it gets you the answers you need very easily. That's very different from the value of, of another type of system.
What I was gonna say, Gary, is that even when vendors of complementary products want to work together, as Steven can probably attest, it's hard. You've got to get entire organizations aligned. Because I think there's been a lack of discipline in our industry where everybody wants to claim to do everything.
Gary Vasey Yeah. And it seems to me that what the three of you were suggesting is that integrating a set of applications, even if it's in the cloud and open APIs and all of that good language, it's still more than a technical issue. It's an issue of understanding the strengths and weaknesses and the purposes of the different applications that are involved. Ben, do you have any thoughts on that?
Ben Lafleur The technical barriers are coming down, right? I mean, that's the benefit of a lot of these newer technologies that we're seeing that the hard part is not the tech stuff anymore. I mean, it's almost not even, I mean, it's there, but it's not worth mentioning almost. It's the, figuring out what data needs to come out of what system and what format at what granularity, right, and getting all that correct, that's the hard part.
Gary Vasey So that leads me on actually to, to what technologies then exist currently that are making it easier to accomplish the end goal of integration then.
Ben Lafleur There's, I mean, there's all kinds of stuff, Databricks, Boomi. I mean, we could give lots of companies free advertising, I guess. But the point of it is that the, there's many different products that exist now that are, you know, essentially not eliminating, I don't want to discount the effort, but pretty much bringing down those barriers between the systems. It comes down to whether or not the groups who are in charge of those systems will let you do direct queries out of them, right? That's a big thing. Don't mess with my batch speeds.
And then, you know, just figuring out what each of the different parties needs, and like we were kind of getting out earlier, having those conversations up front before projects start really can save a lot of time in the project because you spend some time just learning the common language, how to talk to each other. I mean, just something as simple as which people to talk to, which company for what you need. And then the actual, you know, queries, whatever, to get the extraction logic rather, to get the data out in the format that your partners can consume.
Gary Vasey To what extent does business process come into it, not just data, but what about where you've got a situation where you've got a back and forth and the business process that requires some iteration between two solutions, any thoughts on that.
Steven Broad My first thought about that is that, yeah, my first thought about that is that there's some difficulties there and one of them is that if you have two products that are not built to interoperate or don't, haven't pre-considered interoperating, a lot of times there's a significant IT project on site where a bespoke integration between the two vendors is being undertaken, and the number of times that I've seen that happen almost always the integration project goes over budget, and the analysts don't actually get the information that they originally wanted, not because of anything other than it's really hard to do this. And if you're an IT specialist at an energy company, you don't know the inner workings of platform A and platform B, whatever they might be. And so you're constantly in communication with both of those groups. They may or may not understand your broader vision for integration. So they, they're, they have a difficult time helping you. And so, you know, that's one of the great values of having vendors that have actually got some agreement between them because they are planning for that.
Gary Vasey Yeah. I think I told you guys earlier that I've had a direct experience even 20-odd years ago of the problem where I was working for a vendor at that time and a customer bought our solution, which was an ETRM, and they bought a risk system from a different vendor and they got really good bargains for the two pieces of software. I don't think it's more than a quarter of a million dollars. And I was called in after about six months, and it was explained to me that they'd already spent $1.5 million trying to make the two systems work together. So this is a problem that has a long history in the industry. But I do feel, as an analyst, that the technology advancements that we've seen are really helping us get to the bottom of it.
And I thought, Sameer, you know, are there any companies that you're aware of that are trying to bridge the gap either with a product or by building or advocating for a standard? Because that's the other way of doing things, I suppose.
Sameer Soleja I mean, there's certainly the ones on this call have done a number of bits of work together trying to advance that and, you know, run into successes and run into challenges as well along the way. And then there's some really good, you know, talking about how technology has driven the cost of this and the complexity of this down, there's some really good integration platform as a service providers as well, there's things like Workato and two or three others whose names escaped me at the moment. But like, integration, they're sort of commoditized at this point. And so the technical cost can be, is probably approaching zero.
Gary Vasey And I see, we've got another question come in and it seems applicable to the, this stage of the conversation. So I'll ask the panel as well. What are your thoughts on integration/interoperability through a peer-to-peer integration versus a centralized integration service layer.
Sameer Soleja Centralized is probably cleaner, but a lot more expensive.
Gary Vasey And why would it be more expensive.
Sameer Soleja Well, because the integration service layer would be hosted at the, at the company organization. So you'd be using, I don't know what people use these days, TIBCO or something like that, to build a whole service bus. That alone is probably a multi-million dollar project.
Gary Vasey Yeah, absolutely. In fact, that was one of the almost solutions for the Holy Grail back about 20 years ago. I recall one of the, one of the times when people started moving in that direction and figuring out that it wasn't the right way to go. I want to ask Steven a little bit more of a specific question around analytics. Why does analytics cadence matter.
Steven Broad Yeah, actually, I was just hoping that we would talk about analytics velocity. And so one of the challenges of today's energy industry is that executives are getting addicted to analytics, and they want more of it. They want it faster. And the pipe from where the data comes from to where the analytics happen is getting maybe not quite so long, but certainly it was not originally conceived of to, to move that data that fast. And so, achieving the kind of velocity, if an executive team is looking for really deep and insightful analytics on a daily or hourly basis, it's a challenge to accomplish that. And it's very difficult if you don't have a coordinated interoperability framework, like the one that we're describing here, to achieve those kinds of, that kind of velocity. I've talked with some energy companies recently who have told me things like, well, they have the data, but it doesn't make its way through the system with all the valid checks for X number of days, and my management team wants a report on this, but it hasn't even been finalized in this other system over here. So, you know, making sure that you are not sequestering that data to one piece of the overall chain or another ends up being crucially important in order to make sure that you end up with the analytics cadence that you want for good decision making.
Ben Lafleur And the appetite for complexity too is also an interesting challenge, right. So we've gotten requests from everything from, you know, executives who want to see full transparency, show your work, everything, to ones that just want to see a green thumbs up or a red thumbs down. So, so the finding the right balance for your audience is also a challenge that we've had.
Steven Broad Well, and to your point, sometimes the same executive wants to just see thumbs up, thumbs down, but then in a different topic, they want to see something quite detailed.
Ben Lafleur Yeah, exactly. Particularly when things are going wrong.
Gary Vasey Well, one thing that we've been seeing is it's not, you know, this breaking down of silos is an organizational thing as well as a systems thing. So, the industry is changing, I mean, we're seeing traders become more quant guys and programmers, and we're seeing some of the barriers within organizations or some of the silos breaking down in order to optimize, streamline, reduce inefficiencies and reduce operational, you know, risk. And so that's also being reflected in this push to, to try to build ecosystems and support the supply chain you know, from beginning to end involving all the players so that you can start to really optimize and break down some of these traditional barriers.
So that means two things. We're seeing a new breed of people coming into the industry. And we're also seeing this push to try to deploy, sometimes augment, legacy systems with newer systems. And, of course, that always brings up the same problem of this integration. So, if you were one of these organizations that was going through this, and let's face it, most are at this point in time, what would be your sort of advice, maybe the top one or two tips that you would give people listening in today to try to achieve some level of interoperability to support streamlined business processes, whether it be risk management or the broader supply chain? Any ideas? Should we talk to Steven.
Steven Broad Yeah, so I have some things that I can say about this. So one of the things is that for people who have already got a fairly rich analytics practice, but what they're struggling with is either velocity or organizing their data, a lot of times they feel like they have to give up what they've got in order to adopt something, adopt a framework that is going to get them the kind of velocity or analytics that they want in other areas. That's actually one of the reasons that we built cQuant to be an extensible analytics platform, so our customers are actually able to bring and lift maybe some more of their own internal analytics models that they've built to our SaaS platform, and then they can run as part of our analytic chain. We really value that kind of extensibility. So, you know, if you're worried that you've got analytics that you're going to have to give up, that's not necessarily the case. You can move to these kinds of platforms that are built for interoperability with my colleagues here. And not have to give up as much as maybe you think you are. I think that's one perspective I would take on it. Extensibility matters.
Gary Vasey Ben, Sameer, any thoughts.
Ben Lafleur I don't really have much to add to what Steven said. I think that covers it.
Gary Vasey Another question popped in, so I'm gonna hit that one right now. Sameer, how is quantum computing expected to impact ETRM? And I'm all ears. Because it's a topic I'm interested in too.
Ben Lafleur Batch speed I guess.
Sameer Soleja Yeah, I guess so. I think for ETRM it would just make it faster, but I think for an analytic system it would be transformational, right.
Steven Broad Yeah. This is something that we're exploring right now. Of course the technology is at a very early stage, but there are some kinds of optimization in particular. Optimization efforts that are, can be drastically sped up by quantum computing. But it's still early stages and it's still quite expensive also.
Gary Vasey So, Ben, the, what's the importance in collaboration and cultural shifts in overcoming barriers for cooperative integration.
Ben Lafleur I think we kind of covered it earlier. Just in it's the, those initial talks around when you're doing integrations on, you know, everyone speaking the same language, learning who the right people are at the right companies, you know, overcoming any kind of time zone, cultural language differences, you know, moving to a kind of a, an existing kind of best of breed coalition of vendors gets you past all that, right. So we, people have done it already. You don't have to pay for it in your project.
Gary Vasey Good. That's, yeah, good. And I guess in terms of next question, I want to bring in the concept of standards. You know, we, I've been around in the energy and broader commodities industry for quite a long time now, probably too long to be honest. And I've seen many attempts at cross-industry standards, which if they could be GISB, for example, POSC on the upstream side. If people could get to agree standards, that would certainly aid in interoperability and streamlining business processes. But I kind of want to ask how, to what extent are standards important in interoperability? And Sameer, what would it take to incentivize companies in energy, for example, to build and stick to a standard?
Sameer Soleja I mean, I think standards would make it a lot easier. I mean, I think the incentive would have to be something like what makes a network effect work. Which is everybody else is already on the standard. So really get, it would be, the challenge would be getting the first few off the ground.
Ben Lafleur First pebble in the avalanche.
Sameer Soleja Yeah. That's right.
Gary Vasey Why do you, I mean, I think I have my views, but why are standards so hard to achieve in our industry.
Ben Lafleur Because there's no incentive, right? It's like everyone's, you said it earlier, right, Gary? It's like, everyone's claiming they do everything. So why would I need to talk to anybody else?
Gary Vasey Isn’t the incentive though, what we're talking about? You know, easier, cheaper interoperability and more streamlined business processes.
Sameer Soleja I mean, it's like telling equity investors that they should invest for the long term as opposed to the next quarter.
Gary Vasey I tend to think that many in the industry believe that the way they do things is strategic or somehow gives them a competitive advantage, and they don't really want to, they don't really want to move to a standard that might eliminate that. And I think, you know, commodity trading is particularly one where it's those little different ways of doing business that often generate the most margin.So there's a resistance to it. And since there's a resistance to standards, you're back to technology and you're back to how do you bring all these solutions together? So, you know, any more comments on the technology or the approach, if you're one of the people listening in today? And you're facing this issue of how do I make system A work with system B? Any more advice for these people.
Ben Lafleur Well, it's interesting about the standards. So, I mean, think about this. Like, it makes products less sticky, right? So, who are you dependent on to build the standards? Vendors, right? Because vendors have to use them to talk to each other. If I build a standard that makes it easy to replace my system with somebody else, then everyone has to compete on execution. And I'm fine with that. I'd like that actually, but a lot of people aren't, right. So it's, there's multiple barriers there. I mean, it's multiple barriers.
Steven Broad So I think in thinking about standards, one of the interesting cases in point is the Common Information Model, the CIM, that was introduced for data communications in Europe a few years ago. I've spoken to some of the folks that were instrumental in building this standard, and they'll tell you that it was quite valuable for a number of different kinds of communication, but a challenge of these kinds of standards is that initially that, you know, they have a particular goal and then maybe the people who adopt the standard want to use that standard for something that was not really originally the goal or well, I'll get to that in just a second.
So, you know, when I spoke to the people who originated the CIM, what they were telling me is that they designed it so that data could be communicated from party to party in a relatively neutral way that was relatively low cost. But once the data started being communicated that way, people wanted to store it that way, and it wasn't really a protocol that was designed for storage. This is coming back to what I was talking about earlier, where, you know, you have an ETRM deal capture system that wants a data structure that gives them a record of the truth with vintaging and auditability and some of these other things. And then you have another world where people want sort of hypothetical analytics capability. Is there a data structure that bridges that gap? And usually what happened, well, what happened in the case of CIM was, well, I don't want to be, claim to be an authority on that, but what I saw happen in, in, in that process was a protocol that was pretty good at communicating particular information between counterparties.
Say, for example, a transmission owner and an ISO or something like that, right? The same model that was good for that wasn't very good being the primary source of data storage for everything. And so people tried to extend CIM to make it a repository for everything. And the moment that they started doing that, they ended up customizing it in strange ways that were consistent with the original vision for CIM but particular to themselves instead of being somehow universal, and that's where these kinds of standards break down. They usually are pretty good for the purpose that they were built. But one ring to rule them all, that's an elusive thing. And once you have it, you probably wish you didn't because it can also, it can also end up really eroding agility.
Gary Vasey And I guess that brings us to another question for you, Steven, which is why do I need a specialized energy and risk analytical software application in the first place? I think we've touched on many of the points, but you know, if you can summarize.
Steven Broad I'll try to summarize real quick. So a number one is you want to be able to study hypothetical futures that aren't your current reality. And you want to be able to do that with a lot of agility. Number two is you want specialized analytics to help you identify things like hedges or things like portfolio additions that are going to matter and solve problems for you and be economically efficient. Number three is that you, in an analytics framework, you very often want a highly collaborative environment where people are bouncing ideas off of each other and trying things and identifying a process that works in addition to what I would call a productionalized analytics. Where you do the same thing basically every day, but you want both this sort of ad hoc world where you're, maybe somebody's just trying to solve a problem trying to figure out how to do that, and you also want the proceduralized world where every day I get my risk report on my executive's desk at the same time. And that's a place where a platform like cQuant plays really well because it's designed specifically for that kind of intellectual agility on portfolios.
Gary Vasey And I guess that really takes me to asking each of you in turn, you know, if you are parties that are working together to provide interoperability solutions, then perhaps I should ask each of you to describe what it is you actually do as part of that interoperable solution. So let's start with Ben on that one.
Ben Lafleur So credit risk monitoring simply is kind of our main bread and butter. We also have some other side businesses, not side businesses exactly, but we're best known for credit risk. And we have trade surveillance is probably our number two thing. So those are the things that we think that we do really well.
Gary Vasey Yeah, Sameer.
Sameer Soleja System of record and the ability to do reporting out of it.
Gary Vasey And Steven.
Steven Broad The more hypothetical analytics and the productionalized analytics that I was just describing and making sure that people understand the medium and long-term impact of deals that they add to their overall portfolio. And, you know what the risk implications of those are as well.
Gary Vasey So, in fact, the three of you present quite a nice little solution kit from traditional risk and modeling and analytics through to credit and all of the ETRM type functionality in between. So you've seen, I mean, firsthand the issues of, you know, matching together an ETRM like Molecule with a risk system like cQuant and what those issues are.
There's another question come in here. So what are the expectations when — it’s a good one — what are the expectations when multiple vendors are involved? RFPs will discuss support, but not as a collective. So this really relates to procuring and procurement. And this is another area that we don't see as moved that much, because it's still a very much a traditional RFP, RFI driven. You know, three to two, five-year type process, and there are other ways to do it, like proof of concepts and or, you know, other ways to do it. But this is a great question, because if I am trying to procure solutions from different vendors in an ecosystem and make them work together, then yeah how, what are the expectations that I should have about multiple vendors and how they will support the collective offering.
Sameer Soleja Well, it really depends on how you contract the deal. Like if you want to assemble it yourself as a set of multiple vendors, then you probably won't get the accountability that way. But if you put one of the vendors in the lead, that one. really ought to be accountable for the first line support of everything. I know we do that when we have integrations with the folks behind the scenes we'll be first line support and we'll be the throat to choke.
Steven Broad I think added to that, it's important to understand the preexisting partnership that might exist between vendors. It's not an uncommon claim that a platform would do that. But if the party that is claiming the lead on those kinds of support issues doesn't have a well-established relationship with their counterparts, you may end up in a situation where those things are less than smooth in the actual execution when support or needs arise. And I think that's a worthwhile consideration. I think that you know, I rarely see RFP questions that say things like what brands are you partnered with? That meant they wouldn't phrase it exactly like that, but that's the general idea, right? Do you have a partner in X category? Do you have a partner in Y category? They tend to be very functional about you know, my products, what they do, and then also what is the, where's the boundary between what you do and what you don't do, but they don't talk about preexisting relationships, even if they exist.
Gary Vasey It’s correct, yeah. I’ve seen that too.
Ben Lafleur I think with user training, I think that a lot of those support questions can be overcome. I mean, if they're on a Molecule UI and they have a problem, like they're not going to call me hopefully about it, right. And vice versa. The questions come on the integrations, I think. And again, it's a benefit of taking advantage of prebuilt integrations that whoever builds those integrations thinks about the error handling models, right? Where do we, we have a, we should have a, you know, a central repository kind of errors, one, one place to check for interface problems that are occurring between the systems that are integrated.
Gary Vasey This has raised a little interest. So there's another question here, curious how integrated the three companies' back ends are. Trouble ticketing, for example, upgrade cycles, training, bug fixes, testing, that kind of thing. Any comments on that.
Sameer Soleja I mean, I think those are things you would expect from a single organization. It would certainly be helpful to have some level of integration there or some level of understanding. But, you know, I think in our case, the touch point is often a person and a process as opposed to a system.
Ben Lafleur Yeah. I mean, when you build interfaces, you create contracts between systems, right? And as long as you're not breaking those contracts, it doesn't really matter what the behind the scenes versions are.
Steven Broad But we can align the expectations that customers have prior to onboarding them so that they understand who does what, when, and that's actually the more important part and having a consistent story amongst the vendors about who does what is, sometimes that's actually more valuable than having a single vendor solution where three different departments that don't really talk to each other very often are trying to, I mean, you'd be amazed how difficult it can be to get a single vendor to handle these things when there's three sub teams that are not really coordinated with each other very much. They're trying to handle these things. It can actually be more difficult than three different vendors.
Ben Lafleur So the first person in comment on the other side is the CEO.
Steven Broad Yeah, yeah. You don't want, you don't want every every support ticket to rise to the CEO or the COO. And that is not uncommon in that kind of larger landscape and a single vendor solution for these things.
Ben Lafleur That's true.
Gary Vasey Okay, so there's another question here. What strategies have you found most effective for driving adoption and ensuring teams get full value from a complex tool, particularly in environments where interoperability across multiple data sources is critical? We'll take that. There's a second part of the question. We'll take the first part first. Anybody want to address that.
Ben Lafleur I mean, you find a range of personality types, right? Between early adopters who are excited about things. These are guys who are getting some benefit from the new integration to people who it's just a headache for, right? So your strategies there are different. The early adopters will mostly do it themselves. You just want to empower them to give them the tools they need to make the transition from their current state to their future state, and generally they're excited about it. The people who are, you know, resistant, mostly it becomes a matter of political will on the customer side. You know, we can give advice, but you know, if people really feel strongly, if they don't want to move, don't want to learn new stuff besides just the normal, trying to get them a little excited about it, but again, that's hard if they're not reaping any benefit.
Gary Vasey Anybody else.
Steven Broad Yeah, I think that's a good comment back. And I think that you know, there is, there's a context to this, but not being sure, well, I don't want to try to say something universal that fits every situation. But what I would say is that in interoperability, there are going to be some people that really benefit a lot from it, and there's going to be others that don't as much, but articulating what the value and the vision for this change or this broadening is, I think, always helps because, you know, if I'm the analyst who's primarily responsible for load forecasting, and what I do is I do my load forecasting and then I give it to everybody else, the benefit of interoperability may not seem very valuable to me until I learned that my load forecast is now incorporated in some downstream analysis that has this extra value that it's bringing to the company.
So I would say that at a leadership level, leaders should be really excited about the prospect of interoperability because it buys them a lot more insight, it buys them a lot more velocity. It buys them a lot more, you know, ability to make business decisions, but a lot of times that value doesn't necessarily trickle down to the folks who are pushing the buttons on a day-to-day basis. And, but they're going to, they should be able to get some benefit as well.
Gary Vasey Sameer, anything to add on that.
Sameer Soleja No, I mean, I think the reverse is true as well. The person who is, for example, doing load forecasting may be handed a set of input data that they don't realize has come through three systems before them. And is the product of that.
Steven Broad That's a great point.
Gary Vasey The second part to that question is also interesting, which is how do we address compliance and maintain trust in the system while managing such complexity? Any thoughts on that one.
Ben Lafleur Yeah, I think good error reporting like I talked about earlier, right? So, I mean, obviously everyone's going to go through whatever level of UAT is appropriate for the complexity of the thing that you're doing. So coming out of it, right, the projects, there's going to be a high level of trust. Maintaining that trust by providing consistently good, you know, reliable results is probably the harder thing, you know, you get a year or two years down the road, people get more complacent, so you need really good kind of error reporting frameworks. And then also when things change, you know, you start trading new types of trades or whatever, the new types of instruments that the process should be just as rigorous as it was during that UAT. And that's something that we see a lot that kind of falls down. You know, we'll spend three years on a project getting everything exactly right, then you start trading, you know, unicorn rainbow options or whatever, and they just sort of add the trade type and move on. Right. And without that kind of rigor of analysis. So that's the big thing to me is the, is the follow through.
Gary Vasey Okay, we have another question here as well. Is there alignment in implementation approach e.g., a cookie cutter to begin with which to begin timeline data testing, et cetera, or is this a case of each entity implementing itself.
Steven Broad I think that there, there is, you know, what exactly that is, I think, we’ll, probably not go into those details, necessarily, but I mean, when we have three parties like ourselves that each know what our responsibility is, what our deal is, it does make it quite easy for us to work together to implement. And, you know, when we've done some pre-work on integration, that also makes it easier as well. So I think that there is. The places where it's, I'm going to focus on some places where it's not cookie cutter, because, you know, any energy company that I go to is going to have a slightly different mix of assets or slightly different volume of assets.
We serve some vendors that have, you know, maybe less than 100 things that would go into their deal capture and asset sort of system and then we've got others that have more than a half a million. It ranges all over the shop and the way that we would integrate or implement somebody who has this massive portfolio versus a much smaller portfolio is different sometimes because the folks that have the truly massive portfolio already have some sort of system. It's just a matter of transitioning it from some sort of system to a robust system, whereas the folks on the other end of the spectrum, they may, I mean, I've seen cases where they had all their contracts written down in paper form and they had to transition from paper to digitalizing in order to do that.
It's not, I'm not saying that any given one of them might be that case, but you first have to understand where their data presently is and how you're going to get it into our combined platform. So there is, I mean, there's, that part can be quite bespoke, but then once we've got it into a platform, then how it interacts is much more cookie cutter.
Gary Vasey Anybody else on that? Well, I think one of the things I've learned from this listening to the three of you has been fascinating is in terms of, you know, why go for pre-built? Built interoperability and integration, and it seems to me that what you're all saying is that, yeah, it's feasible to, to, you know, soft in the cloud ecosystems in the cloud picks and different apps and they work together.
But if they've already, if the company's involved, the vendors involved are already working together and cooperating. Then you get some incremental benefit, and it seems to me those incremental benefits you've suggested are in the areas of the support processes and even on the implementation side, to some extent, certainly in terms of understanding the functional scope, where the right place for things to happen from a functional point of view actually lie and also in terms of the sort of technical integration as well, which can be pre planned and pre-done. Have I missed anything? Is there any other benefits that you can think of in terms of this pre-integrated solution set.
Ben Lafleur Well, they get to work with us. We're pretty great.
Gary Vasey It's a good one.
Steven Broad Good point, Ben.
Ben Lafleur Thank you.
Gary Vasey Okay, well, I think we're coming to the end and there are no questions from the audience that I've got. And I think I kind of summed up some of the things that I've learned and I've been fascinated by some of the answers and I've learned some things myself this afternoon, so I'll hand it back to Kari now to take us to the end of the webinar.
Kari Foster Thank you, Gary. And wow, what a great discussion. Thank you all for the excellent questions. I just hope this webinar has been enlightening and helpful for you. I'd like to thank all of our panelists today for the insightful discussion: Gary, Steven, Ben, and Sameer, and an especially big thanks to all of you for joining us for, from wherever you are today. Have a great rest of your day.