Creating NASDAQ’s Cloud-Based Virtual Workflow

Before I get into the meat of this article, I need to preface with a couple of comments. First, this is a case study about my own company’s solution for one of our major clients. I rarely write in these pages about my own clients and solutions, but when I learned that this edition was focusing on cloud-based workflows, I wanted to break my own tradition. The story I am about to tell you has been one of the most interesting voyages I have undertaken in this industry, and it has direct relevance to this edition of the magazine.

Second, I wanted to comment on the term “cloud.” I appreciate that in the mass market the term “cloud” has become a generic buzzword for anything that works on the internet. At the same time, in the “innovators” circles, it is trendy at the moment to decry the word, opting instead for more specialized terms and definitions. I, too, have my own definition and understanding of the term. At the outset of this story, I thought cloud was a technical description. By the end of the 3 years this story spans, I have learned that in my estimation, cloud is really about the service and economic advantage that the chosen architecture can offer its eventual owners.

Now let me provide some backdrop: Webcasting is an evolved technology that has found traction in the financial markets since it first emerged. While most financial institutions are quite conservative and deliberate about their technology spends, the spend made by their marketing and public relations (PR) teams on their own IT to manage their corporate communications has typically been more autonomous; it is seen as something that operates outside of the corporate firewall, at least up to the point that the chair’s annual report is broadcast into the enterprise network infrastructure. This internal tension between the typical public company’s IT directors and the marketing directors has often led to debates over who has the right to use the corporate network, as well as for what reasons. The in-house AV teams are often thrown the ball to sort the problem out, and they often opt to outsource the webcast production service to their PR agencies, who subcontract professional webcast service providers.

No company has positioned itself so strongly in the middle of this pool of webcast service providers for the financial markets as NASDAQ OMX Corporate Solutions (NASDAQ; for reference, NASDAQ OMX acquired the IR, PR, and Multimedia Solutions businesses of Thomson Reuters, including its webcasting solution. With tens of thousands of live events held annually, NASDAQ OMX Corporate Solutions is the 800-pound gorilla in the financial service webcast sector that provides fair disclosure and investor relations services to its many Fortune 500 (and other) clients.

The Genesis of a Virtual Workflow

Three years ago, I was engaged in a late-night conversation at a Streaming Media Europe event with Andreas Heidoetting, global head of webcast technology, who has a range of responsibilities for the NASDAQ OMX Corporate Solutions webcasting infrastructure. We were discussing the various workflow aspects of operating its four global broadcast network operation centers, through which NASDAQ ran all its online events. We were thinking outside the box and focused on removing expensive, heavily manual third-party encoding call capture vendors (on which a great dependency had developed largely as a legacy from the acquisition of Corporate Communications Broadcast Network (CCBN) several years before). Such a change could yield a potentially significant efficiency saving if we could deliver it.

Essentially, the workflow was scaled to meet a peak demand, which NASDAQ hit on each quarterly reporting round, at which time there may be many hundreds of live events running at the same time across the platform. However, generally the systems were running an average load nearly an order of magnitude lower. For a year, this meant a whole lot of expensive kit on standby and skilled operators who needed occupying.

The brainstorming session developed into an initial consulting project where we isolated the key technologies that could not be emulated in software, which were relatively few, and started talking about developing an entirely virtual workflow. This had appeal, since you could launch such a workflow on a virtual platform, use it when you needed it, and then destroy it (getting rid of any maintenance and hosting cost).

Afterward, with my team at id3as (a professional services consultancy for streaming media), we put together a working proof of concept for NASDAQ OMX Corporate Solutions that removed the reliance on the audio capture interfaces that were historically deployed to dial into analyst briefing calls -- the lion’s share of their webcasts. With this removed, we had a workflow with internet protocol (IP) in and IP out; everything else was software-based.

We deployed this proof of concept on Amazon Elastic Compute Cloud (Amazon EC2), and while it was crude -- inasmuch as the entire process was manually driven via remote desktop -- it proved that we could build a workflow to complete the same task as the tens of thousands of audio-only analyst briefings that were operated from within its existing network operations center (NOC), without any requirement for physical servers, phone lines, or encoders.

Andreas had introduced Simon Ball, global head of webcast operations, NASDAQ OMX Corporate Solutions, who was very engaged by this stage. Ultimately, there were a number of seeds germinating, and it was clear that by the time they came to fruition, the opportunity here would be to decommission the NOCs and pay only for the compute time that they used, with little or no underutilization.

We ran some spreadsheets, and the business case looked extremely attractive. While it would be inappropriate for me to discuss my client’s inner financials in this article, the cost savings were predicted in orders of magnitude.

Having hundreds of encoders and management computers running in multiple webcast operations centers, ready and waiting for peak usage and yet normally operating at a small fraction of that capacity, meant underutilization was an expensive business. We subsequently changed that dynamic so that the only time any infrastructure was up, operating, and costing money was when it was directly in use for client delivery and directly earning money.

Regardless of how it was done -- I will look at some key aspects of the technology later -- this “cloud” of intangible systems is brought into action as soon as required, and it is destroyed (at least as far as any cost of ownership is concerned) the moment it is no longer directly making the business money. For me, this is what the cloud is all about: The cloud should really refer to dynamic economic and service models and not to anything technical at all. It’s all about what it offers, not how it does it. Anyone who leads with any technical advantage the cloud delivers misses the point if he or she doesn’t offer an economic/service advantage first and foremost. Now that I have belabored that point, let us look at the relevant technology involved.

The Technology Behind the Workflow

Those of you who are managing workflow infrastructures such as the ones that the NASDAQ OMX Corporate Solutions teams operate, and who are considering the cloud as a way forward, are probably itching to ask a few questions. While I can’t predict all of them and must be mindful of my client’s confidentialities, here are a few of the questions we have been asked at some of the Amazon developer and Streaming Media conference presentations we gave last year. I’ll use these as a base to dig a bit deeper into the infrastructure architecture that my company, id3as, delivered.

Why Amazon EC2?

In 2010, when we tested out the various public cloud operators that we were hoping to use, we had a mandate to ensure that the entire solution would be vendor-independent. The first important thing this meant was that we were limited to cloud providers offering infrastructure as a service (IaaS). In IaaS compute models, you pay for a virtual computer by the minute or hour and that’s it; it’s up to you to configure it to whatever application you require. This differs from what platform-as-a-service (PaaS) offerings such as Google apps or salesforce.com may offer, where you buy access to a range of applications that are all preconfigured and you fit into their workflow. IaaS also differs from software-as-a-service (SaaS) platforms such as Amazon CloudFront or simple storage service (S3) networks, which perform specific software functions that you can integrate into your own applications.