In my previous blog, we have talked about taking the right decision about considering an application for modernization path & architecture upgrade on containers.
Now the question is if an application has been defined as a modernization candidate, could there be a faster and cost-effective solution to modernize instead of directly triggering a lengthy application re-write project. Decades ago, when computerization first initiated, customers targeted development of applications for core processes to their business as first set of applications to be developed. These applications when developed, helped automation of core business processes provided an efficient and fast completion of business workflow for customers. This led to a revolution around manual process to computerization trend and prominent computer languages of that time were used heavily to develop these applications. These trends kept going for replacement of a given manual business process by fast & easy to handle software applications.
Over a period of time, computer technologies also kept evolving, new ways and design patterns were adopted to standardize and fast track computer software application developments. New languages and application architectures were evolved, and customer kept using these different patterns shown below to develop their other applications.
This led to heterogenous technologies implemented in customer application portfolios and complexities of maintaining these application kept increasing, leading to a huge IT budgets for applications maintenance and developments. Budget pressures always kept customers on toes to make a balance on their OPEX and CAPEX strategies and finding new ways of portfolio modernizations like now a days these same initiatives are leading to cloud migrations, AI, ML and other innovative architecture implementations and re-write of legacy applications. Now the question really is, should we rewrite every legacy application while there are ample amount of new, out of the box cloud services and SaaS products available in market. I think as an IT professionals this is our job to help our customers decide and take better decision around these legacy application whether a given application should be build or buy. We as a Technologists should be able to show them pros & cons for any application re-write vs replace with SaaS product and guide what is best for them. In my view if we are able perform build vs Buy analysis right it can help our customers upto a great extent in utilizing their CAPEX budgets better and make a proper balance with OPEX which will eventually make us a true partner to the success of our customers instead of an IT vendor.
Build vs buy framework generally based upon the below parameters help our customers better in deciding about re-write vs replace i.e.
If all the above parameters when assessed in details and results is favourable to go for COTS instead of re-writing the legacy application would definitely help the customer better. Though these are not the only parameters to take decisions about this need but technologist can add more to the list based upon their experience and customer scenario. The key here is that solution should be cost effective for customer, easy to maintain, futuristic in nature and adaptable to new features, platforms without any compatibility issues. Then we should definitely recommend GO for a COTS, SaaS or any software readily available to replace any legacy application in the customer environment. Have shared my thoughts based upon best of my knowledge on this topic hope it will help.