Front office digitization in wealth and asset management

Adam Gugliciello (00:08):
Hello. I'm Adam Gugliciello, a Solution Engineer at MuleSoft. And today I'm going to take you through how the Mythical Bank asset management has accelerated their digital transformation using MuleSoft and API-led connectivity. Mythical Bank is launching an exciting new digital initiative called MyPortfolio. It's targeting mobile and web portal users as they plan for this to be the new face of their customer's experiences with the bank. From the discussions with the business, this is the wire-frame of what's been required. Their challenge is that the data to serve this wire frame is scattered across the organization, not only in a wide variety of systems, but accessible through varied communication protocols and functional behavior, messaging, file-based delivery, code STKs for things like Bloomberg or web services for things like Reuters, proprietary protocols, and data formats, and so on. More importantly, this landscape has different teams with different domain knowledge and different skills.

Adam Gugliciello (01:12):
We need to fulfill a business service capability that enables us to expose these data assets to our different audiences in a timely fashion, something Mythical Bank has historically not been great at. So Mythical, working with MuleSoft, has developed a layered API-led connectivity approach, which asserts that we'll design our interfaces first and proposes to break this capability down into an organized, layered composition of independent, self-contained, lightweight, and reusable building blocks or APIs, each of which is responsible for some portion of the data delivery that we've seen earlier. And let's see how we can do this with the Anypoint Platform.

Adam Gugliciello (01:52):
Engagement and reuse lies at the heart of MuleSoft's value proposition, discovering what's been built already and composing new functionality from existing, which all starts in Exchange. Here in Exchange, developers and business users alike can discover what assets have already been built in Exchange. Here they can discover both what MuleSoft has published as connectors, templates, and examples and best practices to get you started on a variety of common integration tasks, larger integration examples and templates, and just generally accelerate your development.

Adam Gugliciello (02:29):
Moreover, this is where the Mythical Bank will publish to itself. So here they can see all of the assets that they've published, can drill into any of these APIs, and experiment with, discover what they do, discover some documentation on them, collaborate around them, and actually experiment with that service to see whether this service is sufficient for the requirements that I need. So in this case, my position API here will expose, for a given account number, a suite of assets and holdings. Assuming some API I discover is what I need, I can go and request access to any of these APIs and self-service the way that I want to access this data and get access to real living systems with real living data, assuming that I'm allowed to.

Adam Gugliciello (03:20):
If we don't find what we need in Exchange, API-led connectivity suggest that we should design our APIs collaboratively and cross-functionally to make sure that we're all on the same page before we develop anything, which takes us to Design Center. Here in Design Center, we can interact with all of the designs of these services and allow different constituents with different skill sets to participate in this. Integration specialists who are comfortable working in code, either in RAML or OAS, can simply pull together assets the way they need to and have the system help them build the description or examples of the data that they need in order to build out their APIs.

Adam Gugliciello (04:09):
Whereas less technical users have the benefit of a wizard that will walk them through how they want this API to interact, if they want to change defaults or examples or templates, maybe they want to require that you must have at least one character asset symbol to use this. Regardless of whether I'm a pro coder or a low coder, both of my users can switch from the RAW to an example data mocking service that they can turn on with the push of a button and experiment with these services and use that to communicate with their constituencies, "This is what the service requires. This is the data that it's going to respond with, its type and data formatting. Is this sufficient to your requirements? And if it is, we'll go ahead."

Adam Gugliciello (05:04):
In our use case, the wire frames we saw earlier described what data we needed at the experience API. And in many cases, the actual systems at the backend, whether that's Salesforce or MongoDB where my benchmarking lives, will describe the data that's available to the system APIs. And so now we can collaborate as a cross-functional team to agree on what reusable business interface looks like, ensuring the perspectives of domain experts, user experience designers, product owners, and so on. Once we've described what that position API should look like, each of my domain experts can produce an API spec for their domain area following the same approach. However, what's much more likely is that a number of these services already exist. And so in the case of perhaps our portfolio mainframe owner, he happily makes small changes to his existing spec, maybe adds a field or two versions that service in a way that doesn't break any of his other constituents and serves the position API.

Adam Gugliciello (06:08):
Once we've agreed to our specs, it's time to get building. MuleSoft's Anypoint Studio allows these domain experts to easily develop services, which serve data from a wide array of backend systems and powerfully transform those data sets into the spec we've agreed on with our users above. Here in Anypoint Studio, integration specialists can work to very simply, with no code, pull together data from, in this case, MongoDB and export that data in the shape that we've agreed to where MuleSoft is providing all of the metadata and all of the transformations, such that we can simply drag and drop the transformations that we need and develop the script.

Adam Gugliciello (06:54):
Moreover, we can work with doing not just APIs, but we can take batch processes where, for instance, we are handling an inbound CSV and pumping this into Mongo in a batch process periodically so that we can keep this data living and manage all of the integration tasks around Mongo inside the system API. As we go up a layer from the system APIs, it becomes MuleSoft APIs all the way down, allowing things like complex routing, parallelism, or caching to be easily managed as a flow of data, while effortlessly managing the wiring, transformation, and choreography of all of these services that have been exposed and discovered in Exchange such that if I needed to rewrite the way we are lifting account holder, for instance, I can again, drag and drop these things together and can say concatenate the name to the account holder for my upstream users.

Adam Gugliciello (08:00):
As each of these services were developed independently, we effectively moved from a waterfall stream that looks like this, where folks are blocked on implementations of services below them, to something much more parallel and streamlined that allows us to reduce the overall time to delivery significantly. Once we've agreed on specifications, all of my teams can move forward and work against mocks and implement their services against those mock services, replacing those mocks with real implementations once they're complete.

Adam Gugliciello (08:36):
So I'd like to thank you for your time today in exploring how the Mythical Bank has accelerated their front office digitization and generally begun really accelerating all of their projects using MuleSoft.