 Hey, everyone. Welcome to the session. In this session, we are going to talk about key lessons learned from building a wealth management portal using cloud native architecture. I am Uncle Kumar. I'm a senior director of technology. And so before we get into the session details, let me give you a brief intro about myself. I've been with sapient for more than 10 years with industry for 22 plus years. I am the technology lead for financial services. Hey, everyone. Welcome to the session. In this session, we are going to talk about key lessons learned from building a wealth management portal using cloud native architecture. I am Uncle Kumar. I'm a senior director of technology. And so before we get into the session details, let me give you a brief intro about myself. I've been with sapient for more than 10 years with industry for 22 plus years. I'm the technology lead for financial services. I focus on microservices and cloud native architecture. I'm certified as new soft platform architect to graph enterprise architect. AWS solution architecture and also I've done safe and scale agile certification. I've been speaking at different conferences. So feel free to engage me at Twitter or LinkedIn to know more. And I'm very excited to talk about today's session where we are going to see what I've learned. And as part of a journey which we started few years back of building a wealth management portal for a client in North America. Before we dive deep into wealth management case study. Let's understand what a wealth management is if you are already in financial services sector you might be knowing this but for those who do not are part of financial services. It's an advisory business where you do advise your clients or how to make your investment, how to grow money, how to make sure you manage the cash and investment strategy for your clients. As part of that there are two key entities and the first part is advisor who is advising the clients and who are basically involved in making that investment strategy and making the investment on behalf of the clients. Advises are essentially are regulated by FINRA or SEC. They in fact get a unique ID from them and they have to register and go through that process. Once you are done that the once you identify a client or you can see a prospect even before the client. You start discussing the initial goals and objectives and build that relationship with the client. And then you start doing the financial planning process as part of the wealth management goal. Once you understand what is the long term or short term goal for a particular client and then you start capturing different information for the client. You start collaboratively working with the client to understand and create a financial plan and then mutually open up that strategy of how you are going to make money for them. And there are different aspects of, I can't capture all different aspects but this is just a quick summary of what an advisor does for a client, opening up the digital account managing the investment portfolio, rebalancing as per the market dynamics. These are not the examples but it's a symbiotic relationship between the client or we say advisor and the client. So from the client perspective what they are expecting from advisor is that once they understand their financial objective, basically help them grow the money, provide the details of how they are doing it. Definitely work and trust the advisor because they are sharing all this information like bank accounts or all the financial details so that they can plan for their financial future. Exchange the documents and they are giving the an authority to advisor to manage the financial plan so you pay for advisory fees as part of your assets under management, but it's advisor and client they are working closely to make sure that the money or the investment strategy is in place for that. So in order to do that, and that's where the wealth management portal or wealth management business comes into the picture and that's what we are going to talk about today is how a technology can help an advisor to serve their clients better. And that's an statement from an advisor we captured early on is they don't want to worry about the platform they want to worry about the client so the platform is just a tool. The main purpose is to serve their clients. So, when we started in the journey which I'm going to share for one of the clients and where it's the second largest wealth management. You can say a broker dealer company, I can't share the name because of the confidentiality, but when we started working with them. You know, first thing you understand, try to understand from advisors and from the client is what is the key business challenge and the drivers where you know we wanted to enable the advisors we wanted to launch new features and we wanted to ensure that advice are getting the kind of service they're expecting so that they can serve their clients better. And in order to do that, they wanted to ensure that they have the right operational efficiency. The platform can be scalable and extensible as the market changes they should be able to meet the needs for the client so time to market and the ease of integration with different vendors is also a key part. The most essential part of the experience experience of advisor experience of the client so that they can serve their clients and clients can experience an integrated experience so that they can see the financial plan they can ensure that they can they have easy access to all the information. So, in order to do that they ensure that you know the outcome is that how do I reduce the total cost of ownership, reduce the time to market do better brand positioning and and also increase your advisor and client support base with that business challenge in mind. We started our journey towards almost in 2018 timeframe. We started building this digital platform and there were three key goals as outlined here. One is technology that you can ensure the technology is an enabler and we wanted to have the latest and latest technology but not using the microservices architecture and all that but that's not the essence of it. Essence is that you want to create an integrated customer experience and end to end digital experience and so that the advisor can bring that bigger financial picture to the client and they need certain tools like digital vaults, you know, easy e sign and different capabilities you will see that how do I accelerate the experience which I'm giving to the clients. Accelerated delivery is one thing which was always key that how can I do monthly releases or even weekly releases as as what we need of the hour earlier they used to have like six month release cycle. So we wanted to ensure that we can meet all these, you know, kind of a delivery goals as well as experience goal and technologies, enabler to doing that. I like this code where we say that you know do the best you can to you know the better because there are so many unknowns right. So the idea is how do we start progressing and as we know better, we will try to do better. That's the intent of it. So, in that journey, or any journey to be any journey, my focus is always and that's what I also suggest others to do is that look at the lens from people processing technology perspective. So, when you look from these lenses that how do I, it always starts with strategy and consulting right but the dynamics are when I say people is customer experience or advisor client experience enabled by technology and and the product is at the intersection of it. When we are talking about all three dimensions so product is the output but you know all this is all about these three different dimensions perspective so moving forward I think what we started doing is that we started streamline streamlining the client experience and we can't do it in a day so we defined a roadmap that okay let's let's do that with building the platform slash foundation, then we start launching the MVP feature. Let's say the decline portal and was a portal and financial planning and some of the capabilities we are talking about which are essentials for advisor and client to do business, and then later on we start in 2019 we started streamlining and accelerating some of the capabilities that how do I integrate with some of the key capabilities like account opening electronic delivery CRM integration and all that so he took a crawl walk and run approach that you know how you can start defining the baseline first and then you start launching capabilities on top of it. So by 2020 the platform was fully operational and now it's kind of being used by 20,000 plus advisors. So having said that the first lesson, which as part of the journey, which I, which, which we learned as a group is that organization culture and I know it's, it sounds, you know that organization culture that's fine but what do I mean and is we we observe that you know engineering is a lot driven by when you say what an organization culture is allowing you to offer. And having said that some organizations they are very waterfallish in nature and some organizations they are, they want to. They are very agile in nature. So what we started observing is that how we get that support. And the first thing like I said that for us it was to ensure that and going back to Convys Law is that you know organization, whatever is your organization, you will start designing your architecture as per your organization So putting and I can correlate with that because that's what we observe that you know the key challenge which we saw that any, any such organization where you go and start driving the digital platform adoption. Initially you need to understand the culture of the organization and ensure that you get enough support from the executive and change or at least try to change the culture of the organization so that you can build that platform. So that's what our initial learning was that how do I change the culture of the organization and leadership support. So make sure that you know the key stakeholders, you get a bind from them and they understand the why part why we are doing this and, and also people have these fear of, you know what will happen to the existing platform so you need to build that psychological safety and bring the culture of and cultivate the culture of product mindset not the just that we are doing this project not know we are. And that's what you know Martin follows if you have read the article long time ago he published you know that we need to move from the siloed functional teams to you know more of a you know teams either where you have a vertical cut of you know people where they're business driven, not that you know there's a UI specialist there is a middleware specialist and EBA specialist. So, so cultivating that product mindset is important and it's not, it will not happen in a day in our experience or so it didn't happen, but gradually you start doing that in first spring second spring and then you'll start seeing that, you know, after in soft development and following that approach and consistently doing it, you'll see that that will start everybody will start adopting to it. So you need to promote that culture and ensure that you know that you also promote the culture of you build it you run it kind of culture and that's what after our first release we wanted the deaf team to start operationalizing it as well so that that's another thing which culturally you have to enforce. One thing which I strongly believe is you know every failure is a learning opportunity and I've seen this. There will be lots of failures during and we also encountered that, but every failure we need to ensure that you are not pushing the team rather than we are enabling the team okay it's a learning opportunity and ensure that you know the team is focused on meeting the objective. Alright, so the second part of our, the second part is after the transformation journey the lesson learned is that how do we establish and people ask me that is there any secret sauce to it and I always say that you know it's every organization journey and every engineering transformation is unique and it's contextual to what organization or what client we are working on and what is the program under consideration right so it kind of start looking at the holistic perspective that engineering and cloud transformation when you start looking at you know from the technology and engineering from product process from communication culture. There are different aspects to it. So, if you look at it like technology engineering, you ensure that you know you are following cloud DevOps and you know microservices kind of architecture which is the modern day architecture. You ensure that from product perspective, you have the right ways of working you have the product management team in place you are focusing on customer experience and all. And then you have the right communication and influence on the culture so that you enable that culture to build that capability. From an organization design perspective you ensure that you know product and customer aligned there is enough governance in place and they are our right matrix to be. So this is just a framework, but you need to customize in all these areas that what works for you and that's what we did. We got this framework from sapient kind of ways of working we can use this framework as a reference but we customize it as per this journey as well so that's that's something which is up to you that how you want to customize it. The third lesson, which I learned as part of that journey is that how do you innovate and how do you apply open source and cloud native and these are very powerful technology which you have under consideration right that because it gives you the empowerment and enable to build something bigger. So when we started defining the architecture, and this is a very simplest simplistic view of the architecture and the logical architecture which I can't share the details but this is a, you can say a 50,000 feet view of the, the logical architecture that we had the user experience for advisor portal and the client portal. And then we had this API orchestration layer we can experience there which is aggregating the experience for, for the front end here, you can say back and for front end pattern. And then you have the microservices layer beneath that, which is using caching messaging and other different features but essentially these microservices are being orchestrated by the upper layer and then, you know, services are being rendered to the front end here. And then, at the end, you have the system of record you have many databases we had and you have, you know, different third party integration system data warehouse system, and other analytics and third party systems but I'm not getting to details but the high level these are the different layers in the architecture which we design and powered by the different cross cutting concerns that we have to address. So, when we start laying down this foundational architecture. We started seeing that, okay, what are the different elements of the architecture, which we can meet with open source and as an engineering principle we were always keen to look into what are the capabilities open source or the cloud native can offer. So, the application architecture, we started with the reference architecture for application. But we started looking for what are the different capabilities, then application architecture needs to have right so so we started with the before actually choosing the technology choice, we started looking at what are the, what are the capabilities we are looking for. So, definitely we needed for a better self service and application development experience you wanted. You know the Kubernetes kind of management and administrative interface. We wanted observability so that we know what's happening behind the scene we wanted better release management so we can do the faster build and release deployment and better time to market. We wanted to understand the analytics and notification and apply that CI CD and all configuration management is part of that, you know, continuous delivery approach. And then we wanted to enable that the whole support for CI CD we wanted a container registry software supply chain secrets management on all these different set of capabilities which we typically have as part of your software delivery. And the foundational layer is you know there is a container runtime and orchestration engine power and then compute network and store so these are the logical, you can say capabilities we wanted in in the application. So this is a relative kind of a reference architecture. So once we knew that you know this is what we were looking for, we started now mapping out that okay what do I need to and not going to share details about all the application architecture but this is a map of what we chose, right so we used for application okay we chose angular spring boot Drupal elastic crazy and post-crisis technology empowering different microservices and and different components of the architecture. But the key part is that for Kubernetes we were in fact they were already using rancher so we we kept using rancher as a as a more like a Kubernetes managed interface, which was providing a nice dashboard and, you know, kind of a capability to monitor your container orchestration and all. And we already had the good relationship with New Relic and New Relic was already in that organization so we use that as an observability and you can see application performance monitoring solution. But if you look at this you know we we kind of leveraged a lot of open source technology for CI CD like Jenkins and you know Kubernetes as an underlying platform and big bucket and all. And then we started, we also looked at like JFrogh Artifactory and use that as a registry and for software supply chain also JFrogh and secrets and identity management. Earlier it was Centrify but it got acquired by CyberRox so we are we're using that as an identity management solution and bucket was definitely the runtime engine and initially we were into rancher capital, which is not. You can see at that time Kubernetes compliant but now we are moving towards the Kubernetes. Kind of orchestration so and also in parallel because this whole architecture we had, you know, the complexity of the architecture is a hybrid cloud kind of architecture so some services and some components are on prem. Now we have also started taking another initiative where we are moving some of the components of the AWS so there are already those components are using EKS and Lambda as a function as a service and some of the you know the AWS native services. So it's a hybrid cloud kind of you can say architecture we are using on prem cluster using rancher as an orchestration managing all the containers and for cloud side we are using AWS EKS so it's a mixed you know kind of architecture we are using hybrid cloud. So, but if you look at the technology options here we ensure that we not only see that what is aligned to that organization as well as what is better suited in that context so you know your answer could be different. It's, I always believe that it depends a lot on the context and the organization, which technology you choose but you know that's what we also did and you can use the same mechanism to do that in your architecture. So having said that the next thing which score to my heart is about the deployment right because if you notice in the early, you know kind of a vision which will be started talking about what we were looking for the architecture and what we were looking for is that time to market right so if you can do the deployment right and do it something in a, in a time friendly fashion that you won't be able to achieve that vision right so the lesson learned is that you know, we also learned hard way that in any architecture including cloud native architecture you need to manage the deployment operations early on. And when I say manage, you don't need to wait you know, till the whole because it early days you are focused more on development so you're kind of don't ignore the deployment aspects of it because that is where will bring a lot of efficiency for the future releases. So, when we started looking at, you know, the cloud native architecture which we established and, and, you know, you might get over with so many technology or so many components you can say, which you have in your application right so, and every component can have a different deployment approach like we chose mule soft as a API management solution so that has a different way of deploying than a microservices application which are, you know, like spring boot application has different way of deployment so, similarly, if you have like rabbit mq for example we used for messaging. How do you ensure that the infrastructure as a code is set up. So every component has to be considered from the overall deployment perspective and that's the essence of it that's what I'm trying to communicate here is that once you understand your the application dynamics, you need to ensure that you have the details of each component that how you are going to manage the deployment of that aspect and that's what we also did. So based on that, you know, communities is foundational. And we all know that you know, when you're discussing a coven it is as a strategy. One of the lessons learned is that you need to be very early on discussing all these strategy and we learned at hardware game that you started with like rancher cattle and now we are moving to the full blown coven it is that it's a painful journey if you're doing that so think about the coven it is journey early on that what part of and we need to coven it is there some parts nowadays, you are having several as you're having, like we are talking we have also deployed an air blue as fog it. So you need to think about what components you want to deploy to several less what fits better for that area and what component you want to keep it to, you know, your managed coven it is and what you want to still do a self managed engine like rancher cattle so I think that is where a lot of innovation and you have many options, but you need to be very clear in terms of established. So the key lesson is that you know establish that strategy first, and for each component that strategy can be different. Okay. The fifth, and that's one of the most important areas that when you're building a complex solution like a wealth management. You can't build every capability by your own. Why because the time to market is a pressure, you need to launch like we launched in nine months so we need to ensure that you launch that capability sooner and then get the early feedback. So integration by integrations. What we learned is it's it's a it's a big accelerator, and you can keep the patterns to what industry standards are but some of the capabilities for example, financial planning, you, we use money guy pro. And that's a, that's a vendor, providing financial planning, some of the areas of financial planning but we also integrate with some vendors like you only for account aggregation so why we are doing that why not building that capability yourself because if you start doing for every capability you need to decide that whether you want to build or buy. But if you don't want to do by then it's the time to market will increase so that balance we need to keep and that's why integration plays a key role. In any set solution like wealth management. Some of the capabilities you're not going to build from scratch, you are going to take vendor offered capabilities and you're going to integrate that capability so that you have an integrated experience so the essence is that you know, it's an accelerator, but you can keep it standardized and used to and a great resources the enterprise integration pattern book which has catalog almost 65 patterns right. So there are different patterns for different areas that what do you want that how you want application to be integrated and and all these 65 patterns, you can go and bring about in detail but they offer a great catalog of how you can integrate with external services and we leverage a lot of these patterns when we were kind of integrating with these systems whether it's pubs up the point to point, whether it's using dead letter queue for any message which you can't process, whether you're using a messaging service for communication between services are correlation identifier for messaging routing we have used a lot of dynamic routing and pipe and filter pattern message translation. All these patterns we have to apply in different use cases for business so and the technology I'm just outlined some of the technology it's not like enlisting all of it but technology is again. similar for these patterns so the key recommendation is that always go and refer to these patterns and see whether you can apply these patterns in the as per your context and that's what we also learn. And I'm just sharing up, you know, a view right and it's not covering all the vendors so we've integrated with like 30 plus vendor so I can't show it all but I'm just sharing that you know that. So when it comes to integration, either you are integrating in a user experience or, or a business process or a data right. And that's what happens in the typical wealth management context right that you are maybe getting accounts data from your Lee. When I say counts data suppose I have a Bank of America account and I'm just sending a link to my account so and wealth management professional need that information so that data is coming through your lead to your wealth management system. So, some integrations are, you know, require like money guide like I talked about it requires integration in all three areas like experience process and data. And, and same goes for account linking and aggregation, we were leveraging, you know, all three aspects, and some are you know you're only like research report like Morningstar we it's a process based integration where we are getting a PDF or data from Morningstar and then ingesting the data and then keep it in our system and then the experience part is what we want. And similar to that, you know, in that wealth management portal, you always have some custodian like purging or broad range. So they are providing you the different statements and all so that is again, and my view is like, it's a data and process kind of integration So, what I'm trying to communicate here is that based on different vendors that and what capability you want to build and buy, you have to be applied to apply different integration pattern so be be clear on what you want to apply what area of integration piece and refer to that integration back catalog so that you are, you're kind of using this industry standard and that's what we also did. This is just a sample of what we were talking about, you know, how you are getting data through batch or ETL or I streaming interface. Typically what happens is that some of the integration touchpoints you can't even do, you know, the real time integration suppose you are getting a data which is to the volume is too much right because of, or some regulatory purpose you can't do a real time integration you have to provide the batch integration interface interface as well. So, this is just a view of you how you can, you know how we have kind of ingested as well as, you know, kind of a built that batch interface as well again applying the same set of patterns from the catalog which we talked about. And that's what the lesson is that you know, keep all your integration as per you know the integration patterns and mostly keep it standardized right so that's that's the key essence. And for last point, I just want to make sure you get it from the engineering standpoint is that later on we realize that it's very important to have a platform engineering team and any initial stage when we were foundation, building the foundation architecture. The platform engineering team is by default everybody is kind of contributing in that area of building that platform. At a later stage, that becomes more critical. And that's what we also learned. So we saw that you know, some of the areas like, if I look at the dev an ops part of it, when we established a platform engineering team, we saw that we gain a lot of momentum when we had a focus team. And that's a lesson that if you have not done that, establish a platform engineering team. And these are some of the outcomes which we have seen it happening in dev and upside of it, when we did that, like we redesigned the search experience using elastic search and move from database to that. And a lot of, there was a huge business benefit like business was looking for a global search kind of this feature and better response time we did that with no search redesign. We ensured the faster data ingestion time for better results. We kind of use feature toggle and platform engineering team kind of came up with approach. How to do feature toggling so that business can switch on and off any feature when we when they need that. We also kind of built a page building experience using Drupal, so that you can drag and drop widgets and build a content heavy page. So a lot of these capabilities was the outcome of having that platform engineering team. So, it's very essential that you also focus on that and that's the lesson we learned. And for operational team as well that we when a production issue comes that we realize soon that we need a consulate observatory dashboard we built that we also built a dashboard for production support team so that they can they can quickly resolve an issue. So we started tracking the SID matrix the for golden signals that's what they call it like latency traffic and error and resource saturation. So, all these traceability or tracking of those metrics through the dashboards instrumentation for tracking, synthetic monitoring for proactive alerting. These are just some examples but platform engineering team made it all possible so you know that ensure that the platform engineering team and helped us to accelerate some of the manual bills to automated and you know the developer tool enhancement, bringing that high motivation culture and a lot of things happen because of the platform. Listen, we learn. So, all this is just to create the business impact so want to highlight a quick slide that what impact we created and I, I just taken a, you know the advisors feedback for this and you know what once they in the initial release once that happened they experienced the advisor portal. And they kind of started using it you know that that speaks for itself that how this type of moment was promoting a good relationship for them to build with their clients. So the impact we made is that we saw that in our initial reasons we saw that almost 20,000 plus advisors control and when I said 20,000 advisors, imagine that each advisor can have many clients so almost we are talking about 5 to 10 million clients and then different broker dealers that's what we call it is that we start seeing a lot of them adopting the platform we ensure that we move the idea to live from when you the product manager writes an idea to live it got reduced from one to three months. We improved automation sprint lifecycle and platform adoption and also these are the key impact we made as part of the journey. And with that I will just say that you know, this is just the beginning we are still continuously improving the experience of the platform. And I'll be happy to engage in any conversation not linked in a Twitter, and thanks for spending time to hear me out. Thank you.