I've been "in cloud" for the best part of ten years all in the Capital Markets industry, although only really got my hands dirty in the last six years and really opened up the bonnet/hood in the last four. Looking back through the history books, it looks as though 2017’ish was the point of inflection where those that knew, we’re helping those that needed, and adoption accelerated.

My career started off working as a civilian for the armed forces, submarine tracking. We were using a mainframe that, to be honest, was ahead of its time. It was called (Honeywell) Multics, pre-dated Unix, and was a thing of beauty. It had flashing lights, magnetic tape drives, a massive 2MB memory, spinning platters for storage, electricity consumption approaching that of a small town, and you'd need a multi-million dollar budget to acquire one.

In the old days (been there, done that), if you were part of team responsible for building and deploying an application, it was more than likely that you had to deal with the infrastructure team so that you could get some compute real-estate to run the darn thing on. Depending on the size of your application, whether you needed a cold/warm/hot standby duplicate, whether you needed some headroom for scaling, and then how many locations/offices, the amount of bare metal compute you needed was probably not insignificant.

Resilience and disaster recovery are critical components in the context of the Digital Operational Resilience Act (DORA), which is a European regulation designed to ensure the robustness of the financial sector’s information and communication technology (ICT) systems. The regulation recognises that the blast radius of an incident today is much wider than previously and can not only take out the system and/or entity when the incident occurs, but can also affect down/up-stream entities.

The Bloomberg Professional Services Terminal (aka Bloomberg Terminal) was released in the early 80’s and has been evolving and thriving ever since. Anyone who used the Terminal back in the early days would certainly recognise it in its current modern form. Bloomberg even create/brand their own keyboards and screens, and there's a great article about the keyboard history.

I remember my first few days at Bloomberg where, like many others, life included sending and receiving many emails. Muscle memory told me to click on Outlook and away we go. Although we had Outlook in those days (and bloomberg.com email addresses), it was severely frowned upon. In fact, so much so, that even though I sent colleagues email communication, there was nothing coming back. My managers (you know who you are Brad/Tricia) constantly reminded me, "just say no to Outlook".

Life in Bloomberg was anything but static, no day the same as any other day, but, the focus was always the customer. This customer-centric approach always created trust and good will. In fact, one mantra was "always do the right thing" and that's tough sometimes when the inevitable revenue vs no-revenue conflict occurs. That spirit though, meant that I always invested time ensuring I understood the pain points and remained open-minded about solutions to avoid hammering round pegs into square holes every time.

A couple of weeks ago I was at a FinTech event with numerous other like-minded individuals. The setting was rather formal and we were basically sat in the same room and seats all day. I had a stranger to my right, and like any good neighbour introduced myself and we had an exchange about experiences, places we work(ed) and soon we were talking tech. We talked the controversy about this programming language vs another one and in some respects I tried to bait him (sorry!) with the ".NET is far superior", but he didn't bite and just gave me a very pragmatic response of "We use whatever is the right tool for the problem at hand".

Up until the late 80’s, most market data was presented on screens (terminals) by vendors such as Bloomberg and Reuters. Only those vendors had the engineering capacity to support feeds and the pace of change that went alongside connecting to venues. They also connected to multiple venues, so then had to start normalising the data from the venues. At this point they became known as ‘aggregators’ for the role they play. Today, these two vendors individually cover all the listed venues (exchanges, MTFs, OTFs), markets, OTC, cross-asset, broker-dealers, and, even crypto exchanges. The number of sources extends into the thousands and each of these sources mostly want to monetise and control its stream of data.

In a previous article we discussed the beauty that is wrapped up in the Bloomberg API (BLP API). As a recap, this API allows you to connect to micro-services within the Bloomberg ecosystem. The micro-services deliver content and capability in a ‘real-time’ manner. What do we mean by real-time?

Why do the majority of procurement and market data teams struggle to understand Bloomberg licensing? There’s probably a couple of reasons, i) Bloomberg’s origins as a Desktop (Terminal) company , ii) Most procurement and market data teams with a long time exposure to enterprise data licensing from LSEG/Refinitiv. These two factors have led to a large confusion in the industry understanding Bloomberg’s licensing, how best to use their content and a misperception that the licensing is challenging, mysterious and expensive.

Deriving data can be done simply in excel or via an in-house calculator written in a programming language such as java or python. However, another easy way to derive an output is by leveraging industry standard calculations from Bloomberg. The next time you sit in a meeting and consider building vs. buying it would be prudent to think about whether your in-house calculation will ultimately add that much value?

Sounds kind of cool doesn’t it? We’ve got everything else available as a service, anything from compute, storage, email, databases, software, platforms.. You name it, it’s available as a service, all except.. Market Data. But then, what do we mean by Market Data, certainly it’s not the generic reference to static market data, which is available across the board from various vendors, including aggregators like Bloomberg, Snowflake, SIX, ICE, LSEG, etc but let’s focus on the Real-Time (“I need it now”) access to financial content. Yes, typically this is a reference to streaming, ticking data, but it doesn’t always need to be, but the pattern helps understand the need.

Previously, we spoke about the possibilities of supplementing the Bloomberg Terminal with added value. This was achieved through applications and Excel leveraging the Bloomberg API (BLP API). Although we considered just a Bloomberg Terminal with the Desktop API, and, looked at a Client/Server approach through Server API (SAPI), essentially, it’s still all the Bloomberg Terminal. If you’ve explored these options in your organisation, it’s about as far as you can take the Bloomberg Terminal ecosystem in supporting applications.

While working with a small OMS/IBOR start-up provider out of the Nordics there was a philosophical discussion with the CEO and founder of the company. The discussion talked about the pros/cons of building functionality, acknowledging that similar capability was already well developed within the Bloomberg terminal. We examined the business opportunity and return on investment for two options; go ahead and build the capability into the OMS/IBOR product, or, integrate with the Bloomberg terminal and leverage the existing functionality. Ultimately, an investment was made in adopting the Bloomberg integration technology, and developing tight integration between the two offerings.

The Bloomberg Terminal.. thousands of functions, across all asset classes, more technical analysis than you know what to do with, a vast wealth of static reference data, artificial intelligence built in, messaging, sentiment analysis on news. It doesn’t get much better .. or does it? As I mentioned in my last article, Bloomberg supplemented the Terminal with a point of integration, a means of programmatically getting at the power of the Terminal. They created what we call the Desktop API (DAPI), or more formally, the Bloomberg API (BLP API).