Application Modernization - Replace, Rewrite or Replumb?

This post sponsored by the Enterprise CIO Forum and HP.

In my last post on application modernization, titled Application Modernization – “Plumbing projects” or roadmap to innovation & revenue?, I talked a bit about the importance of  how modernization projects can deliver value to organizations.

In many application modernization projects, the best option is the one that provides the best long term value for the organization.  Since we don’t live in the real world, the best option is the one that can get funded, get done in the time-frame and provides the best value today and on the near term.  Of course, I’d argue (and do argue) that you shouldn’t allow near term to over-rule the long term, but oftentimes we all do things that aren’t perfect but get the job done today.

There are times when you have to make a decision that may not be optimal. Maybe you’d really like to completely replace your application / system but budget constraints or time constraints force you to choose to do something other than replacement…maybe you rewrite some of the system functionality or maybe you make your system work a little differently (for now).

I’ve been through this myself and have a nice little story to share of a project where we had to make the decision to replace, rewrite or replumb a major application.  Actually, we had to make the decision on two major systems within a very short timeframe.

Before we get started, thought let me take a second to define the three “R’s” that I’m using:

• Replaced – the application(s) will be fully replaced with a completely new application
• Rewritten – parts of application(s) are rewritten to bring new functionality to parts of the application but the entire application isn’t replaced.
• Replumbed –  the application(s) remains the same but new technology/platforms are implemented to provide new services and connectivity to other platforms.

The Backstory

A few years ago, I was involved in a project to revamp the website of a major organization.  We had a fairly large project underway to rebuild the main website for this organization using.  We were rebuilding functionality and trying to do some major information architecture to the website as well as doing some basic re-branding to meet new branding guidelines.    Some of the functionality that we wanted required a connection to the organization’s authorization and authentication  system and access to training/personal records that required a login to access. From this point forward, I’m going to call these two systems the AAR system.

The AAR systems had both languished in disrepair for years with hacks upon hacks added to each to add new functionality and make the system work.  There had been little real architectural work had been done to ensure changes to the system were viable, feasible and well planned.

So…we needed to connect to the AAR systems and build new functionality to allow users to login to access training modules, training records and other information that needed to be hidden behind an authentication system.  In their current state, the AAR systems would be difficult to seamlessly integrate with our Sitecore driven website, so a decision was made to review both the authentication / authorization and records systems to see if what needed to be done to make the integration work well and seamless for users.

The options available to us were either to rewrite, replace or replumb one or both of the systems.

The Plan

After many discussions, meetings and planning sessions, the final recommendation was the following:

• The AA system would be replumbed.  A new system was added to the IT infrastructure that would provide a gateway to the AA system from all new systems built in the organization.  This was accomplished using a new application that provided a service engine that allowed new systems to communicate using a standard service instruction set to check authentication and authorization.

• The Records system would be replaced.  The current record system had been hacked together over many years and would be easier to replace now than wait until after the roll-out of the new website & integration. In addition, this system was only used for a few activities in its current state…but if it could be rewritten, it could be morphed into something much more useful and powerful to the organization. The Records system would be replaced with a SharePoint driven system, which would be integrated Sitecore to allow a seamless transition from the public website and content to the non-public records and information in the Records system.

So….the plan was to replumb one system and rewrite another.  Sounds like fun, right? 🙂

The Outcome

The AA system was replumbed to allow new systems to more easily interface with it.  The Records system was replaced to allow a more flexible platform (SharePoint) to be implemented and utilized.

The decision to replumb the authorization and authentication system wasn’t ideal but it did allow the project to finish on time & provides for a new, easier to access AA system for the organization. Our decision to rewrite the Records system was the right one…it gave the organization a very flexible and powerful framework to build upon in the future.  That system has since been expanded on and more functionality is being planned for it.

The timeline was tight but the project(s) turned out well and we released on-time.  Our new website built on Sitecore was rolled out with some fairly tight integrations with Sharepoint for user authentication and authorization as well as record access. We also added some additional functionality that allowed our Sharepoint system to act as the search engine for our Sitecore driven websites…pretty cool stuff – and something I may have to write about in a future post.

Like most projects that are rushed out the door, there were quite a few issues found once the system was released, but nothing that wasn’t fairly straightforward to fix.   Most people within the organization didn’t realize (and probably still don’t realize) how much time, effort, blood, sweat and tears went into that project by everyone involved…but that’s the way it normally goes in these types of projects…and that is, yet again, material for another post.

Lessons Learned (?)

So…I’ve written a lot here (a little over 850 words so far). Hopefully its been an interesting read…but i’m not writing this just to share a story.  I’m writing this to highlight the compromises and trade-offs that we regularly make in the real world of IT.

There are times when you need to replace / revamp system, but you don’t have the budget or timeline to completely replace the application / system so you’ve got to determine a ‘best approach’ for the situation.  Rather than replace, you sometimes have to rewrite portions of the app/system and other times you need to replumb that system.  There are times when you have to take the non-optimal path…but if you have to take a the non-optimal path, at least take the best non-optimal path.

In a perfect world with unlimited budget and time, you’d do the absolute perfect option that gives you the absolute perfect functionality, growth opportunities with the least amount of maintenance…but we don’t live in a perfect world.

In the real world, we do what we have to do…we replace, rewrite and replumb.  The key is to know when to do what.  The key is to understand how to determine the right option for the organization and your team.

Image Credit: Question mark made of puzzle pieces By Horia Varlan on flickr

This post sponsored by the Enterprise CIO Forum and HP.