Software as a Service (SaaS): Modernization Challenges for Enterprises

Most companies are making the decision to retire legacy software deployments and migrate to SaaS based solutions. One of the hidden challenges of this migration is how to replace the larger ecosystem of solutions built on top of these legacy deployments. This article will describe one real world use case and the outcome of this transition.

Modest Intentions

Like most software projects, my team had identified a gap that we felt technology could address. I was part of a strong innovative team that was passionate about patenting. During larger organizational meetings, teams were recognized for their technology breakthroughs but we found that many other teams were not investing time in submitting disclosures failing to capitalize on these innovations. When our senior executives mentioned that visibility to activities such as patenting were restricted to direct reports, we realized there was an opportunity to rally around patenting to increase awareness more broadly. At that point, a few of us decided that we could invest some of our spare cycles to work on a pet project that was directly applicable to our passion in patenting.

Global Adoption

What started as a short term side project quickly grew by word of mouth across our division. Over time we rolled out access to this web based application for all US based managers and eventually globally to all world wide employees. By leveraging our corporate LDAP, we were able to define Access Control Lists (ACLs) that cascaded across entire organizations and with some innovative algorithms, were able to provide detailed reports for organizations exceeding 5,000 employees. By the time the roll out was complete, we had over 9,000 registers users and sending approximately 1 million automated monthly reports annually to managers and individuals across the entire company. In reality, we identified a relatively significant gap in how our company tracked patenting and were able to provide a layer of transparency to many teams.

Integrations

One of our foundational architecture design points was embracing REST for our APIs. This was in stark contrast to the systems we were building on top of which relied solely on SQL queries. As a result, we encountered many teams building other solutions on top of our APIs. One such instance was a tool that was intended to be used for the selection of Master Inventors. The realization of these extenders only came by chance when one of our developers was submitting the form nominating one of our other colleagues. At this point, we clearly had provided value beyond what we had initially intended.

Managing Legacy

One of the unspoken truths about internal application development is the likelihood that the investment quickly turns to maintenance only mode. This was the case with our side project. The result is that the entire platform, while incredibly stable, was running completely on unsupported technology from both the Java Runtime, the Application Service as well as the UI technology had all been out of service for many years but the risk of updating code and encountering regressions in behavior were deemed too risky. In addition, the application was hosted on systems that were not suitable for the latest and greatest operating system patches. Even smaller things like passwords expiration became one more routine thing that we had to track and prioritize against our daily workloads. Lastly, maintenance costs for items such as SSL Certificate renewals were considered low priority when compared against actively developed projects. The truth is that legacy applications have their own form of costs that need to be accounted for in development organizations.

Modernization

With the explosion of the cloud, we often talked about what it would take to reinvigorate the project and invest development dollars to modernize the tool which would long term save us money over hosting our systems on leased Virtual Machines(VMs). As we had built the architecture to be REST based and leveraged dependency management tools, we had a reasonable design in place to move to modern architecture based upon microservices with the idea we could expand our client platforms to mobile and chat. Ultimately we decided against investing here since we learned that there was going to be a corporate roll out of a new SaaS based tool to replace the platform we had built on top of.

SaaS Solution

During our discussions with the teams driving evaluation of the various SaaS solutions under consideration, we got more details on the SaaS offering that was being rolled out. The tool selected was a market leader and definitely a significant improvement over the core platform that we were based upon. The downside is that the platform is intentionally opinionated on how the tool is to be used and had limited extension points to build out solutions that extend the platform capabilities. This is very common with SaaS solutions that are focused on providing multi-tenant hosted of their solutions for large scale deployments. It is simply too cost prohibitive to create a completely open platform with access to the internals similar to the legacy solution we built.

Conclusion

With companies moving more to SaaS based solutions, this will not be an uncommon scenario. The key aspect to learn from this story is that when looking to replace legacy solutions, it is equally important to identify the complete ecosystem in which these legacy systems participate in and to ensure whether there is significant investment in these solutions that need to be migrated to the SaaS based offering. Failure to do so can result in leaving behind a significant portion of your user population and result in delayed adoption of the new (and often better) solutions.