 Hello everybody. My name is Frank Quinn. I am the current OpenMama maintainer and founder of Cascadia Unlimited where we focus on bridging proprietary and open source technologies. So I'm here to talk to you today about OpenMama and about how it is useful for both market data managers and software vendors who are trying to promote their software and their market data solutions into market data managers. So we're going to start off by showing the introduction to OpenMama and what it is and where it's used and then we're going to go into some of the applications for market data managers and then we're going to move on to some discussion around the applications for market data vendors and for application vendors and then we're going to go into a quick demonstration of consuming using OpenMama from both a proprietary data source and from an open platform data source and then we're going to finish off with some questions and answers. So we will just dive in here. So we'll start off by asking the question. What is what is OpenMama? So for those of you who don't know OpenMama is effectively an abstraction layer and it is the API that your application would write to and but behind that API it interfaces with the underlying proprietary technologies and Open Technologies. So an OpenMama application doesn't need to worry about which platform it's publishing on to or which platform it's consuming from and all that OpenMama application needs to do is subscribe to market data using a configuration transport and a bridge which is usually provided by the platform API. So for example, you can use OpenMama with the exact same application to consume data from one middleware or you can use it to consume from a completely different middleware and your application doesn't actually change. It's a runtime configuration and you drop in a different library, different configuration file and then you can start consuming or publishing on to a different market data platform without any changes at all to your application. So why is this so important? Well, the main benefit is that your application no longer needs to worry about the underlying technologies, supporting lots of different technologies. It means that in terms of choice the market data manager or the business can, for whatever reason, decide to switch between different market data technology providers without significant costs and overheads associated with actually making the switch and the development overheads and the support maintenance associated with that. It has flexibility. There's the same API. You can switch between open source and proprietary technologies and all people are building their own open source-based platforms in-house at the moment. That's why we'll completely support that. The other main advantage is that it can be extended. So there's a plug-in interface for OpenMama that allows you to get events fired in whenever certain things happen like subscriptions are created or messages are received and so you can control your auto trail in a standard way as well. We have bindings currently available for C++, C-sharp and Java including recent development, which was C-sharp on .NET Core. So you can use OpenMama with C-sharp on Linux, which is a bit of a big step for us, but it seems to work pretty well. So that's effectively what OpenMama is for. It provides that abstraction layer away from underlying technologies. So you don't need to be concerned about the underlying platforms that your data is publishing to or subscribing from and that's it. That's all it is. So if you have a look around you as to where it is and where it's deployed, it was first officially published in 2012. It comes from a long line of non-open source APIs, which have been in production for decades. So it's very much a mature offering that has a lot of production miles behind it. With the nature of the client base involved though, there's not a huge amount of publicly declared people who use it, but there are some out there. The most notable ones include J.P. Morgan and Deutsche Bank, who are members of the Station Committee and the NYFX who have recently published a zero MQ derived API as well for OpenMama to allow OpenMama to publish and subscribe on to a completely open source platform. So there are lots of products out there that belong and integrate with it. We get support requests a lot that come in from lots of different customers as well. So and there's a much bigger world out there. The integrations that we provide, or the integrations that are provided by the community, extend into wider technologies and wider platforms. It's not uncommon to use OpenMama purely as an abstraction layer to get data into a larger platform from perhaps a more niche provider that the market data manager may not want to go to the effort of writing an API for there either. And the other thing worth doing is that it's used to cross all asset classes, FX, options, futures, derivatives, they're all in use with OpenMama to varying degrees. It traditionally comes from the equity side, but it does have an awful lot of use outside of that and in different asset classes as well. So if we take a look inside the mindset of the market data manager and the problems and challenges that are facing them, there's always new functional pressures. There's always something that somebody wants. There's a new market data provider. There's a new way that they want to access historical data and there'll always be something that comes in and EDCs for in-house feed handlers. It's a very, very busy job being a market data manager and the general biggest recurring thing is that they need to continually support the variety of different little snowflake applications and platforms which all need to play nicely with each other. Against the backdrop of this, you have all the performance constraints that go with that. So you've got low latency, but you need to also support high bandwidth. The data needs to be very well normalized. It needs to look the same across different data sources. There's usually lots of tweaks required from the third party provider to try and get it to behave like that. It's basically a constant struggle to try and get things to look in a sort of regular way that is easier to manage and easier to maintain. On top of this, it tends to be one of the biggest cost centers in where they're deployed. So you have constant cost efficiency problems. They want to reduce footprint. They want to reuse data that they've paid for once. They want to make sure that the same data is reused elsewhere if they can and if the license allows them to. On top of that, you've got the regulatory requirements that come in from the side. So the result of all this is that market data managers generally don't build everything themselves. There will be a number of open source, proprietary, quite niche in-house technologies, and they all need to play nicely with each other. And that's really the challenge that they're facing today, trying to get all those to rein in and play nicely together. So we're going to walk through, this is a very simplified version of what a platform would look like. But the main thing that you need to take away from this is that the technologies here are effectively isolated. If you've got a market data vendor either who is publishing data onto their platform, it may also be an in-house messaging platform which may have been written or may have been maintained for previous reasons and has been too costly to move away from, or it has its own advantages to a unique use case for the target deployment. And that can't disappear either. So you end up having these redistribution layers to try and attempt to make sense of them and to try to publish data onto multiple data sources or to switch data sources or data platforms. So the requirement is that the API that we have here is deployed across all applications that need to consume from that platform. And it's not just messaging either, there's entitlements, there's compliance logging, there's drop copies, there's lots of things that need to be done outside of purely the market data stream. And that's where the plugin interface that I was talking about earlier on could come into play with Oklahoma. I'm going to try to put those across in a standardized way. But the applications, because their APIs are writing to these platforms directly, they're effectively locked into the underlying vendors. And this is a very simplified diagram where we have one application trading box there. But in the real world, there could be tens, hundreds, thousands of those deployed, and each of which are locked into the underlying technology vendor directly, where they're written directly to that API. And of course the alternative to this is that the market data monitors applications abstract themselves from the underlying API. But then of course you've effectively got an API that does what OpenMama does, deployed and maintained in-house without putting resource, without everything that comes associated with OpenMama. So the main takeaway from this is that whenever new technologies come along, whenever technologies go out of fashion, the cost of migrating to a new platform is quite high, because the APIs that are being used by each of these other applications, there's just so many of them, it's very difficult to switch them. So you end up picking third parties and technologies based on, okay, what's going to not make my life a misery whenever I go to deploy this, as opposed to what is actually the best product to solve the problem that I'm facing at the minute. So that's what the market data platform will collect the moment whenever there's no OpenMama involved anywhere. So what happens whenever you do involve OpenMama? Now, the main takeaway here is that OpenMama isn't a platform. I think of a lot of things that you may have seen in the past, OpenMama has been very much portrayed as a platform. It's an abstraction there away from an underlying platform. So there's nothing to stop an OpenMama application publishing and subscribing onto one vendor messaging platform or an in-house messaging platform or an in-house entitlement tracking system or a compliance logger. There's nothing to stop any of that. OpenMama is really just an API. It's a standard way to try and handle market data events. So it doesn't need to be used everywhere. And that's why purposefully in this diagram, you see the little boxes at the bottom, you don't need to do it in all applications. You don't need to do it even everywhere in the same application. You can just be used where it's appropriate to try and reduce the overhead associated with maintaining support for each of these third-party platforms. Because the OpenMama API itself is very stable. I don't think there has been any application interface changes since its launch. So this means that the OpenMama API can be used to trigger events in certain ways. It can be used to access data in the same way. And it can be used for both subscribing and publishing. It can effectively be used in place of a traditional feed handler to try and get data from a data source, a direct data source, and get it out into another platform elsewhere. Or it can be used fairly piecemeal, and just use it for connecting to an individual platform. But the main takeaway is that the underlying technology doesn't have to change. There's no major upheaval of underlying tech that you need to change. And if you do, then please let us know because that is not the goal of OpenMama. OpenMama is supposed to be pretty passive in the underlying platforms, and it's supposed to operate alongside it as opposed to pushing its opinions onto it. So if we move away from the market data managers just for a moment to discuss the application and the market data vendors who are trying to target these platforms. There's generally the opposite problem involved there in that platform migrations for them are very difficult because every customer's target platform is different and everybody's requirements are different. And if you want to introduce a new API that's a significant cost, a significant risk associated with the market data manager whenever they look at it. So a market data vendor can't just go into a market data manager and say, we want to replace your entire platform, and they may have a platform which they may want the market data manager to use, but they don't want it to be a core entry to requirement because it just lights up red lights in the market data manager whenever they see this coming on. Because it's a dangerous thing to try and add another new platform or form as they could often get known to try and handle another market data platform provider who wants to get the data onto your platform. So what happens if a market data vendor wants to target a non-OpenMama application? So the first thing I notice is that that non-OpenMama application probably already has other APIs. They might not be for market data or they might be for market data, but they're going to be there. There's already a cost of development associated with maintaining whatever it's already doing. So without OpenMama, if I could be introducing a new one, you're expecting the client to write to your application code. I mean, it's great that you've got an API that makes it easy to consume from the market data that you're providing, or maybe you've got a protocol specification that you're providing instead, but the expectation is still going to be on the customer to understand that API and to write their application to it. And part of the difficulty with opportunity cost as it goes down the timeline is that what might seem initially as quite a compelling prospect because you're only targeting a single application during a POC phase and you're receiving the market data and it's fine. Whenever it starts to roll out to a pilot and they start to try and target a real-world application or cluster of applications, it becomes increasingly complicated and then something, whenever it's deployed across the enterprise or hundreds of applications, the adoption cost increases with time and the complexity increases with time and the expectation and the burden on the customer increases with time. And the result of that is that the net value of the proposition that you're proposing is actually reduced because the customer needs to factor in the price of migrating all these applications to the market data provider. And because of that, there's not an awful lot of volatility in terms of technology used in the application space. So what happens whenever it's switched around and then OpenMama compatible apps are targeted or as an alternative, OpenMama is the chosen API that you tell clients to use whenever they're switching market data providers. So the core takeaway is the client code doesn't change. If you're consuming from an OpenMama data source coming down from transport A and you're moving to effectively transport B, bridge B the client software doesn't change. It doesn't even recompile. It's just a different configuration and a different runtime library dropped in. So it means that it does shift a bit of the expectation on to the vendor to develop the bridge for OpenMama. But that's what we developed once and once it's developed in our experience anyway there's very little maintenance associated with it particularly compared with an in-house API where you've got client opinions to contend with. And what effectively happens is that the adoption cost for clients is reduced because it's not being duplicated across every application that they have. And in the event that they don't have OpenMama yet and you're introducing OpenMama as the core API that you're suggesting that they use that's a much more compelling story for a customer to get on board with because they know, okay, so if I consume data from you and I decide to change my mind at a later point I'm no longer stuck to your platform. I don't have to go through this massive migration cost to try and move to yet another market data provider. So the risk is much lower there as well. And as well as that the ongoing development cost which is often overlooked for this from a client's point of view is much lower as well. And the support for the API that the client is writing to comes from the community. It comes from the OpenMama community. It doesn't necessarily go straight to the vendor unless there's a bug in the underlying vendor software. So that's the main value proposition from a market data vendor and an application vendor's point of view. It's worth noting as well that we've discussed market data providers here but the same thing applies to any application that's perhaps even consuming from different market data platforms and things like tick capture platforms and technologies like that can all benefit from using OpenMama to try and abstract itself away from the underlying technology that's in use. So whenever you break it down OpenMama really is all about choice and neutrality. It's not an encompassing platform that's going to come in and expect to make massive changes in your deployment. Its main core value from the start has always been that the selection of a market data vendor or an application vendor should be based on how good it is and how high a quality it is and how low the latency is. It's based on how sticky their API is or how inconvenient it is to choose anyone other than whatever incumbent is currently present on your platform. It also breaks down the silos between the platforms. It means that you can bridge between different technologies if you want to. You can migrate slowly away from other platforms if needs be without having to worry about going big bang and using OpenMama everywhere. And if you don't want to use it everywhere that's absolutely 100% fine. That's what it's for. It will consume and produce on to different platforms as and when required and if they can be used as an abstraction there for direct exchanges should it needs be. The applications if you're a market data application provider you can just benefit from connectivity to every OpenMama supported platform simply by writing to OpenMama instead of directly to the third party platform APIs themselves. There's a reduced risk for the customer and there's nothing to stop in-house technologies from moving to OpenMama as well. The bridge API is open. The OpenMama community will support you and create new bridges should it be required. There's actually been a lot of effort made in the last year to reduce the complexity that's required in building your own bridge. So it's much easier to build an OpenMama bridge than it has ever been and because the OpenMama API is public and it's free and it's open source there's nothing to stop an application development being outsourced with a nice firm specification and the API is public there is no licensing associated with using it so there's nothing to stop external parties from writing their own software. Okay so we're going to switch over here to an OpenMama demo here and we did pre-record it because we needed to record it during market hours over here and so we're going to demonstrate the OpenMama portable demo environment and switching between open source and proprietary technologies the proprietary technology being Vela's certified product without any recompilation and a simple reconfiguration and a new library installed. Okay so we're going to show a demo here of what we call the OpenMama portable demo environment. Now we do have some documentation about this on our website and the default format that we have here is an AWS AMI you're welcome to extend this we use the official CentOS images which means that you can extend them without any licensing fears and we have instructions there for how to build your own if you want to build it with Vagrant or if you want to set up a demo environment on a bare metal box so in the instance that we have here we have an AWS AMI that is already set up with a BS image and we're just going to log into it here now so the first thing that you see is that it tells you that OpenMama is installed up OpenMama it has the Cupid Bridgeby default and the binaries are all in the path so one of the binaries with OpenMama includes MamaListenC which is a test utility that allows you to connect to an OpenMama data source and print some data out from it so we're going to just go ahead and run it here the source is OM the middleware bridge which is the plug-in bridge that we were talking about is Cupid in this instance the transport name is sub and we have a nice currency mix symbol there so if we run this up we can see the instrument starts ticking we can see some data coming out of that which is great now that is connecting to CaptureDemon which is running locally and that's the fact that we're connecting to there is no external market data source involved here now that's great but what if we did want to include an external market data source well we do have a repository that third parties are free to contribute to which will give access to optional additional bridges that people can add as and when the Cupid has OpenMama Superfeed which was contributed by Vala so if we install that and have a look after OpenMama then we can see that some of the middleware bridges that if you were familiar with Vala you would have seen before will be available on the LD Labry path there for OpenMama to use so and if we want to get the same OpenMama command that we have before on this in C that provided us with alternative source name and middleware here is their data file by middleware the transport is the data which we just copy and pasting for another window here and the symbol name is another isoncarnic which is here now that's not going to work yet because we haven't configured the configuration of our properties to point to the new data source so bridges can pull in configuration from the standard OpenMama transport list to find out how to connect to the upstream data sources so we have Vala added here so we'll add those in and try the command again and you can see some data starting to tick in from the Superfeed the led data source that they've provided us with so what's involved with getting the same application to connect to multiple different data sources without any recompilation which is opened at runtime and a different configuration so if we go in there to the every demo kit that we have has a checkout of OpenMama's code and so we'll just go into the C++ tutorials that we've got here so that's an example quick start up that we've got and in our demo we'll show you how to get acquainted with OpenMama there are versions available for C, C++, C-Sharp and Java the C-Sharp one will actually go on .NET Core as well so you can run it on Linux so if we create a build directory here as is the standard for CMake we'll do a quick build this is a brand new application which doesn't know anything about Vala or any other it was built against OpenMama and OpenMama then decides which libraries to load so we will go ahead and run this little quick start application run this little quick start application and provide the same commands as what's provided to connect to Superfeed with the data and we can see we're starting to click there in our little example application too so we'll do an introduction to OpenMama and how we can switch between different data sources without any recombination being required or any co-changes required in the app okay so that concludes our presentation on OpenMama thanks everyone for their time we've provided some resources here to let you follow us on Twitter or LinkedIn if you like you can send us an email on the mailing list if you want to get some extensive support and we're also available on Gitter if anyone wants to have a chat with us or at least have some high level discussions around and how you like to use OpenMama in your organization thanks again and we'll leave it to the Q&A