Most of us work in organizations where “green field” environments don’t exist and instead they use outdated systems. This means that when we get into these organizations, quite often in the integration space, we need to understand the challenge of taking something proven, robust, and foolproof, and evolving it to meet the needs of the organization in the future.
For example, discussions I frequently have with organizations revolve around mainframe systems or core banking systems that have proven their worth over decades. Evolving them can be challenging. Many of these systems don’t come with contemporary capabilities such as APIs. Thus, this blog features a variety of individuals who tackled this challenge through multiple angles including how to do this at a technical and a business level. Our panelists have experience with different elements of evolving legacy architectures which is why we have gathered them. Let’s meet the panelists!
Meet the panelists!
Dominic Masters, Sr. Technical Consultant at MuleSoft
During the panel, Dominic was the Integration Practice Lead at Tquila and just recently transitioned into a position with MuleSoft! Within his role at Tquila he provided support and governance to the integration team members spread across ANZ. His experience with integrations spans nearly his entire career — and specifically with MuleSoft, he has over three years of experience.
Laily Mukherjee, MuleSoft Architect and Developer at Sigma Healthcare
Laily is responsible for the MuleSoft integration architecture at Sigma Healthcare. Specifically, she has been a leading member of Sigma’s journey moving away from their legacy systems to MuleSoft. She has 18 years of experience in the integration space with five years of MuleSoft experience. Laily actually first saw MuleSoft when it was the CLI version before the Platform version and has enjoyed watching it evolve. She is also MuleSoft Certified with work experience in a variety of industries including retail and healthcare.
Nadeem Syed, Integration Architect at Sensis
Nadeem has seven to eight years of integration experience. He focuses more on team management and wears many different hats on any given day such as requirement gathering or resolution design. Nadeem also enjoys coding.
Rob Harris, Product Owner API Platform at NZ Post
Rob is both the product owner of NZ Post’s API platform and API simplification program. His job really focuses on taking the legacy systems they have and transforming them into something “new” and usable by his organization. Rob has been using MuleSoft for two years and considers himself a “newbie.”
Challenges with legacy architectures
Nadeem, with the career that you’ve had so far, what strikes you as a legacy architecture that you really didn’t like? When you think about a project or a system, how do you determine if it went well with the approach?
Nadeem: We had a large number of challenges in terms of maintaining the legacy architectures. The first was that the maintenance costs were very high compared to the costs of actual development. In order to change any business requirement, it was very hard to implement because we didn’t have the expertise to code for this. One classic example is that one of the departments in the U.S. Treasury was running IBM mainframes back 40 to 50 years and it was challenging for us to touch the code. We had a feeling that any changes to the code or any updates would break or crash the systems. Thus, we went with a different approach wherein we had to refactor the code and we had to slowly decouple the requirements or other components and start development in some sort of microservice architecture. The time to bring this feature to market was extremely time consuming.
When you left the organization Nadeem, did you see that they had found a better way of having to deal with this legacy architecture?
Nadeem: Yes, what we did is the legacy architecture was slowly being moved into API layers. For example, the domain model from the legacy system was being abstracted into the system layer. We worked quickly to expose this as a REST call. We tried within the spring integration framework, but it was not full-fledged compared to MuleSoft, so we did a POC on the feasible design to see whether the architecture can play a role and then we wrapped this around the middleware. We then moved to the process API and from there it was exposed to the outside world.
Rob, I have a question for you in your role as a Product Owner, I am curious if you have ever inherited a product that is backed by a system that you considered legacy and how did you approach this from a product owner perspective?
Rob: This is essentially my entire role at the moment. Quite a few of the technology systems we have at NZ Post are big monolithic applications so there is a lot of work we’ve done to look into which ones we wanted to migrate to the new structure first. Many more will be changed and in a hurry.
Challenges of evolving legacy systems from an organizational perspective
From an organizational perspective, do you find that it’s a battle to get these changes endorsed or is it something where you get a mandate from the top saying “we need a new system, Rob go ahead and figure out how to make this work.”
Rob: Yes is the answer to both of these questions. Not only is it desired to see all of these legacy applications removed, but I’m also often overwhelmed or impressed by how much people want to hold onto the familiarity of the tools they are using. Thus, you are competing in two battles at the same time: being able to demonstrate what needs to be changed and how it’s going to be approached as well as how it’s going to impact a customer, while making your organizations’ life as easy as possible. Nadeem had mentioned the cost of maintenance and that’s something we encountered in terms of incidents and mean time to resolution. It’s easier to solve problems, reduce the number of incidents, and reduce mean time to resolution with a more modern application. You have to push your way through all of the changes because even when it’s something the company wants, they want to know why.
Dom, you’ve had the luxury of being a consultant in the industry for a while, I’m curious what are your favorite anecdotes of evolving legacy architectures at organizations? Is there a particular story that comes to mind?
Dom: There are a few issues that you encounter wherever you go, specifically architecturally. Luckily, I haven’t run into too many major issues with legacy systems other than the challenge of simply getting the data out of these systems can be a huge issue. This is particularly difficult when there are no APIs available to you to use to expose the data. Other issues are political such as if your organization understands that you need this data, but it’s in a different business unit so they don’t want to give the other business unit access to the information. It can become very challenging unless you have project buy-in from much higher up in the organization. As a consultant sitting on the outside and looking in, that can be challenging.
Laily, would you like to share your similar experience to Dom’s?
Laily: When I was a consultant, I also faced legacy systems with a lot of connectivity and the way organizations needed to convert manual work into automated phases. For example, when we landed one of our customers, they were in insurance and with insurance there are claims that are handled manually. This was the hardest part of working with the customer as all of these were legacy systems. Thus, we decided to use MuleSoft and show them how they can implement Anypoint Platform while maintaining security. Although they were reluctant at first, it ultimately worked out as they liked the automation MuleSoft offers. Additionally, what we are currently doing at Sigma is converting the legacy systems into Mule 4 API-led architecture. With this architecture there are various things you can do that were not there in Mule 3.8. The best is having the ability to build custom connectors in Mule which allows you to connect systems easily and is low maintenance.
To follow up, Laily, you have had such a long career in a number of countries, what stands out to you as an organization that evolved their legacy architecture very well? What were some of the characteristics of this organization?
Laily: One organization had more than two to three hundred applications that needed to be modernized. They were eager to modernize and here we saw an excellent example of MuleSoft when we demonstrated how they can modernize in an automated and very feasible way. We highlighted that if in the future they wanted to add more applications they could do so easily. Additionally, during my five or six years of experience with MuleSoft, we did a lot of modernizing legacy architectures and finding the best solution using integration platforms. With MuleSoft, one of the top selling points was the ability to push to the cloud and increase performance with less costs and the ability to scale vertically and horizontally.
Handling legacy and new systems
When dealing with legacy systems how did you balance between managing both legacy and new systems in parallel? How did you control total cost of ownership?
Rob: COVID actually highlighted something quite well for us as New Zealand went into complete lockdown for about four weeks and none of the stores were open. Everyone started buying things online. This naturally overwhelmed pretty much the entire system at NZ Post as we were considered an essential service so everyone was sending items through us. We saw unprecedented volumes similar to the holidays which caused a few things to start breaking. We had to take a look at what wasn’t working well enough and had conversations with high-level executives for some of our clients wondering why they couldn’t print labels at 2am on a Sunday morning. We took a look at what would be the highest value fix and what was going to be the fastest to fix. There is a bit of managing between the two of these criteria and we had to have an initial decision point about what type of product they would be purchasing. As we were peeling these away slowly, we would direct them to either the legacy system or to the new architecture structure. I was handling both at the same time and what we tried to do was build the value push into production as often as we could and so once we finished a few sprints, we wanted to make sure that all of these were being used right away. We reduced our customers’ labeling failure rate from five to ten percent to zero percent which was awesome. Keeping the customers happy keeps the sales team happy! More importantly, pointing out the work you’re doing is beneficial and we were able to upgrade all of the APIs we have for our labeling process.
Laily: One thing I would like to add is that when you are moving from legacy architectures to MuleSoft, you should first analyze whether you are able to make customizations so that it requires less effort and then you are able to achieve whatever you need to plug into. I would say this is the rule of thumb for anytime you want to move to an integration platform from legacy systems.
What was your strategy in modeling the domain models of the legacy systems? Did you go with a canonical model approach or a bounded context or something else?
Nadeem: We went with the canonical model. We considered that as an enterprise integration pattern to minimize the dependencies between different services of the different components. As such, we could say that it becomes an independent data format and the transformation or the translation logic was done in a process API. This gave us a canonical domain model that was not tightly integrated with the system APIs such as Salesforce, SAP, etc. We didn’t have any experience in terms of an unbounded context, rather we went with a successful canonical model.
Laily: I work with both models, but the best approach was when we moved into the API-led approach. We also migrated from Mule 3 to Mule 4 and Mule 4 has very good features for API-led approaches. You need to be very cautious when you are developing your applications and make sure the customization is available so that you don’t have a bottleneck.
How did you manage the data composition and aggregation out of the legacy systems? Is this a challenge that you’ve encountered in your experience as a challenge?
Dom: This is a bit of a tricky one. As a consultant coming in, oftentimes there’s a lot of
brand context that you just don’t have visibility of. You have to involve the subject matter experts within the organization that you’re working with that understand these nuances that as an external you just don’t have the bandwidth to take on. Unfortunately, my team relies fairly heavily on the internal folks in the organization that we’re working with to work through these particular issues. Essentially we work with whoever the SMEs are in the organization that the integrations are being developed for, but we probably don’t have enough background information to be able to work specifically with those nuances and subsidies between the common data models of the various objects required.
Thank you to all of our panelists for sharing their expertise on evolving legacy architectures! You can watch the entire discussion below, including their answers to a few more questions asked by the audience members. If you are interested in presenting a topic with the Online Group, apply to be a speaker here!
To learn more about modernizing your legacy systems, download our white paper.
