In the News | December 11, 2023

Engineering the Future Webinar On-Demand

Engineering the Future: Interoperability for Technologists

Is your firm struggling with updating and modernizing your technologies? Are you curious how others in the industry tackle digital transformation? In this webinar recording, technology leaders at TD Securities, AllianceBernstein and North Rock Capital Management cover topics such as:

  • The adoption of micro front ends.
  • Challenges with legacy, monolithic apps.
  • Interoperability solutions for a unified user experience.
  • Use cases and successful implementations.
  • Future vision, such as AI in micro front ends.

Speakers include:

  • Tom Herren – VP – App Engineering & Design, TD Securities
  • Anil Yashavant – Head of Trading UI, North Rock Capital Management, LLC
  • John Lin – Head of Non-taxable Investment Product Development, Alliance Bernstein
  • Steve Grob – Founder, Vision57 (Moderator)

Moderator: Good afternoon, everyone. Thank you for tuning in today. My name is Steve Grob. I’m the founder of Vision 57 a consulting firm that helps fintechs of all sizes deliver on their business objectives. I’m delighted to have you all here. One of the things that connects the three of you is you’ve all gotten your feet wet with interop and have made lots of progress. Let’s dive in Anil, first with you. What is it that made you go from being sort of “interop curious” to then actually being ready to commit money, budget and time?

Anil Yeshavant: Thank you for giving me the opportunity to share our story. Northrock is a multi-manager hedge fund. Typically, the business model is that we onboard new portfolio managers who have worked at other firms. They come in with a very unique set of requirements. They typically come in saying, “Can you do this for me?” And it’s in our interest to onboard them because we go after the best portfolio managers.

So when I started at Northrock three years ago, we had a large monolithic application. I’m not implying that it was a legacy app. In fact, it was built on Electron and the latest technologies. We used React JS, all the latest stack, but it was built as a big, large application and a lot of the code was focused on making all these various components work together.

For example, there was a lot of code to work with Electron IPC, enterprise communication, because when these were built they were built as independent components, but they were still all housed under one large application. And our users had very basic requirements. Like, when I’m looking at my corporate actions, how do I look at positions associated with that corporate action? Or, if I’m looking at a summary, how do I look at a detailed position?

We certainly could do that, but then we realized that it was all connected. I couldn’t change something and expect to have it deployed the next morning. We’d have two-week cycles to deploy, and then everyone had to wait for those two weeks. So even though the tech stack was modern, there were challenges.

Additionally, there were UX requirements. Users were telling us, why can’t I see my orders and positions on the same screen? Why give them to me in separate tabs? Why can’t you do that? So we started facing all these requests and the time to market was very slow.

So this is what led us to start looking at other technologies. The obvious one was micro front ends. I had some experience with it at my previous employer. So we started looking at it, but then from a user perspective we realized we still need to make [the components] look like one big app. We can’t have separate apps, we need to have them all working as one app as well as shared data.

So there are two things. One is, how do I share data between these apps? Because, again, the user’s perspective is they have to look like one app. When we looked at solutions, you know, interop, Glue42, it was a sweet spot because they basically gave us those options.

Moderator: And so John, turning to you, Alliance Bernstein (like all the firms here) is a huge company with many different business lines. So what was the starting project where you said, “Yes, I’m going to put boots on the ground in this particular part of my organization in terms of next-gen front end.”

John Lin: Traditionally, our application was built on WinForm, a thick client, so most of our applications sit on the thick client shell. About five years ago, we made a decision to switch over to the web and start doing more web development.

At the same time, we realized there were a lot of good things that we had in the WinForm that we wanted to be able to do on the web. And one of them being the service bus that application users communicate with Shutter, where the web provides certain challenges. We also knew that we wanted some type of container, and we started venturing down the world developing our own containers and our own shell within the containers.

We also started to research buy versus build, researching if there was any out-of-the-box solution for it? Somehow, [interop.io] knew that we’re looking for it and contacted us, and that’s how the story started. And when we started doing research we realized [interop.io] pretty much had eighty percent of what we were looking for. So that’s how the conversation started. At that moment, we’re building a trading application, an EMS application for our muni business, and that was the first application that we built on the web. We wanted to be more portable and wanted to have some of the benefits of being on the web. So that’s when we started to venture down the idea of building all our applications in the web world.

The challenge was convincing the business that you need something like this. Not immediately, but down the road, you would need something like this to be able to build more applications and connect more applications and have them work a certain way.

I think about the future. What we need five years from now instead of what we need now.

[interop.io] had a really good demo, but the problem with that demo is that it looks too good and everything looks like one application. So it’s hard to demonstrate the capability of how you can manage multiple applications and use multiple applications as one. We had to do a few POC in-house using our own applications, putting on [interop.io] and having that being available for the users to play around with. Once you just got their hands on it, that’s when they start seeing some of the benefits and how they can benefit using this, not just technologists can benefit from using something like this, and how we can deliver the application to them on a different platform.

Moderator: Tom, my understanding is that you’ve almost built a sort of, software interop-based practice within TD. How is that going? How does it work? How do you get business buy-in? Are you seen as those guys over there in the corner doing their own crazy thing?

Tom Herren:  Throughout our interop journey, we’ve obviously had lots of ups and downs. But if I go back to the beginning, something that worked really well is this idea of establishing some shared principles. So we did this in two ways. For the early governance of the interop ecosystem, we published a checklist of features and requirements by which we could create any app. And then we released this app toolkit for developers and partners to easily meet the requirements of this checklist. So this was like a design system.

We had an app starter project, which included that design system as well as interop examples. This was super helpful to save devs, like, six weeks when starting a new app.

And then when we finally released our own interop platform, it was easy for teams to use that toolkit to pass the checklist and then push their apps out to users via the platform.

Something that didn’t work so well, on the heels of this is mistakenly we assumed that if we just built it and talked about it everyone would use it, and this wasn’t the case. So, in our org, we had a grassroots approach bottom up. We had to go out and convince people to use this tech. And I think a big thing with interop is you can shout the benefits from the rooftops, but until people can visually see for the first time those two windows sharing data, or some other use case that resonates, it can remain a very abstract concept.

And so lastly, what we did to solve for this, and this was a big breakthrough for us is we went out and found partners that we could actually work with in the org. So instead of waiting for teams to come and build we went out and found teams that had complementary skill sets. Like, maybe there’s a back end team that needs to build an app, our skills in UI and interop. Let’s work together and build those success stories and those case studies. And that’s arguably the best way you could evangelize this in your org is to build up those success stories.

We certainly demoed to business users, but, ultimately, it is our tech partners that are driving that road map internally. So we had to get them on board as well. Like, the business users can say they want it, but we ultimately need devs to build on the platform.

Moderator: Anil, coming to you, you mentioned you’d done some work with micro front ends. How does the world of micro front ends fit into all of this, and how does that enable you to accelerate what you can deliver to your internal customers?

Anil Yashavant: Micro front ends basically gives us the freedom to go out and build systems completely independent of each other. We have teams working in Serbia. We have a team in Mexico, a team here in the US, and we are all working on not completely different technologies, but quite independent of each other. We have apps that were built two years ago that don’t look anything like apps that we are working on now. So [micro front ends] gives us the flexibility to build these apps independently and then bring them together. And, also in terms of what they give us, some of the advantages are quite nontechnical.

An example. When we onboard the portfolio managers, we typically clone an existing app and entitle these users to those apps. So we might have three, four copies of the same app, but the production app is running as is, which is used by eighty, ninety percent of the users. But there’s ten percent of the users who are looking at the same app but it’s a different copy of it with some changes.

That gives us the opportunity to get feedback from the users and then we start to upgrade these features into the main branch.

The interop model or the micro front end model gives us lots of opportunities to do things separate from what’s already running, what’s already working well for us. So we can experiment very quickly in production.

As far as control and authorization, it’s been fairly straightforward. We are able to entitle users on the launchpad, which is like the app library. So we entitle users, and we tell them that this is experimental and we are trying to bring these features into the main application. So there’s quite a clear line of communication, and no one else sees these apps, it’s just those users. We work very closely with them. So in terms of who authorizes these, we have a very active user community that works very closely with us who tells us who should get what.

Tom Herren: When thinking about a project, I feel like there’s two ways you can deliver quickly. You have the beginning of the project where you’re racing to deliver this product out to your users for the first time. And then during the project, you need to release these features on a consistent basis.

I’d argue one of the best ways to achieve quicker results in both cases is to reduce the number of features and the complexity but still try to find a way to deliver a product with value. And so this may seem obvious and trivial, like, just make a simple app. Right?

But I think the real difficulty here lies in you need to understand this problem deep enough where you can take this laundry list of features that our users all need and determine which features are actually going to make a difference. It’s kinda like that quote: “In the beginner’s mind, there’s many possibilities, but in the experts, there’s only a few.” So something I think that pairs nicely with this approach is a new paradigm we’ve been pushing.

You guys call it micro front ends. We call it Micro UIs. Where we’re taking one feature out of the page, and we’re turning that into a bite sized widget.

John Lin: It’s rolled back to every aspect of our investment process because, everyone from portfolio manager to our middle office to trading to PMs, everyone of them is on the platform because we have a very complicated investment process that requires users to utilize multiple application, multiple screens.

So [interop.io] has given us the ability to give them mini widgets. Building more widgets where they can piece them together and do the workflow that they need to do to accomplish what they need to do throughout the day because they do different things at different times of the day.

Traditionally, building them one big application makes it very difficult for them to do their jobs from the morning to the evening. But giving them more widgets, let them decide what to use. So you make their life a lot simpler. They don’t get the interface of the stuff they don’t want. It makes their workflow clean.

As far as feedback, they love it. It allows them to configure the things that they want to configure and not something that we preconfigure for them. Now they can configure it the way they want to use it. And as far as the trading application, some of the traders have three of them loading at the same time, but each one has a different filter aligned to it. Now they can do a different part of the business quickly without doing filtering. It’s just that much more efficient.

Once certain users start using it it’s kind of word-of-mouth that I can easily do this with this workspace. I think the workspace concept works great for us. It allows them to configure it the way that they want to configure it and they get stuff a lot quicker, and we don’t have to go back and redesign or redevelop certain things.

The planning becomes more important in the beginning. When you plan your application and how to build your application, now you have to keep in mind that with the users on [interop.io] you must build it to be reusable.

Moderator: All three of you, what is your advice in a sentence or two on how to continue innovation but maintain stability and quality?

Tom Herren: You have your day to day development, which is very quick, and then that leads up in the monthly or quarterly releases, and then you have your project, your overarching project timelines or years. I’d argue innovation should be implemented at the highest level where things are slower moving, there’s less risk but we have a big opportunity for impact. One example of that would be every year we update our toolkit right around the holiday season so that next year when apps are starting to be developed they’re built on a higher baseline than the year before.

That’s a place where there is not a lot of risk, no app is waiting on this, but each new app has better features, so high impact.

John Lin: So we can separate the infrastructure part of it and then the application part. For us, infrastructure continues to evolve throughout the year. They run at their own pace, and the application runs at its own pace. We don’t have the same team working on the infrastructure and the applications. This way we keep things stable with the infrastructure team testing out everything that’s on their end. The infrastructure is being taken care of.

So separation is how we kinda deal with stability. We can allow people to create what they need to create, but not worry about the infrastructure part of the applications.

Moderator: One last question that’s come in is have you used interop.io to deliver third party data to users? If so, what types of data, and how has that aspect worked?

Tom Herren: So something we’re actually looking at right now that is quite interesting, is with Bloomberg chat, we’re trying to push the boundaries of trade automation internally. So let’s say when an RFQ comes in we could have the order entry widget up on their screen and just automatically feed the information and almost populate the trade ticket for them.

Moderator: Where do you see yourselves in five years regarding interop?

John Lin: We want to build workflows as part of [interop.io] utilizing the capability of all the features [interop.io] provides. For example, linking Excel, and how to use interop.io as a platform to be able to glue all these applications together. So we want to use it as part of a workflow, like the notifications and building stuff out on the notification where they don’t need to load an app. Just use a notification to do a certain type of work. So that’s how we plan to use it or how we see it going forward.

Moderator: One final question, are any of the panelists using micro front ends to integrate with AI or bot platforms?

Tom Herren: I think it’s a really fun question. And maybe the pie in the sky answer including AI would be I know there’s two ways you could use it. You could use it to predict what the user wants on their screen, which micro UI they wanna see next.

And then the crazier one is you could use AI to almost build the micro front end on the fly for them. Removing this bottleneck of needing to populate your app store. Some things like a contact form widget, does a human need to make that in the future? I don’t know. Maybe AI can just generate that on the fly. I think that’s further leaning, but something fun to think about.

Speaker Bios

Tom Herren – VP – App Engineering & Design, TD Securities

Tom Herren is a technology leader within TD Securities, operating at the forefront of app development, design and interoperability. Founding a technology practice known as The Factory in 2020, Tom introduced the concept of Interoperability to TD Securities and has helped shape the organization’s desktop strategy in the time since. When he’s not obsessing over every pixel in an app, you might find him climbing mountains around the world.

Anil Yashavant – Head of Trading UI, North Rock Capital Management, LLC

Anil has strong experience in building Trading and Financial UI systems, spanning various desktop, web and mobile technologies. He has led UI development teams at Alliance Bernstein, JP Morgan, Millennium and North Rock. He is currently leading a team that is building a state-of-the-art Trading UI for North Rock Capital Management.

John Lin – Head of Non-taxable Investment Product Development, Alliance Bernstein

With over 20 years of experience in product development within the finance industry, I embarked on my career at Merrill Lynch, contributing to the enhancement of their credit card and security lending platforms. For the past 13 years, I’ve been part of the Fixed Income Technology team at Alliance Bernstein. My expertise lies in spearheading the development of cutting-edge portfolio management, order management, and order execution platforms, playing a pivotal role in shaping the technological landscape of Alliance Bernstein’s Fixed Income business.

Steve Grob – Founder, Vision57 (Moderator)

Steve Grob is founder of the consulting firm Vision57 and an industry veteran focused on market technology, market structure and strategy. He is the former director of group strategy for Fidessa Group plc, which was acquired by ION in 2018. At ION, he served as Chief Marketing Officer. He announced his departure from ION in June 2019. In addition, Grob writes regular commentaries about market-related issues, and moderates and participates in panels at the most popular financial services events.

Next Article
Branding the Desktop Superapp: More Than Just a Name
Branding the Desktop Superapp: More Than Just a Name

In the evolving landscape of software design, one trend stands out: the rise of the desktop superapp. To effectively market the superapp, it is essential to give it an identity that makes it stand out from other applications by creating a unique image for it, conveyed by a name, tagline, and logo — in other words, through branding.