Tag: application modernization

Application Modernization – Replace, Rewrite or Replumb?

This post sponsored by the Enterprise CIO Forum and HP.
Question mark made of puzzle pieces By Horia Varlan on flickr
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.

Application Modernization – “Plumbing projects” or roadmap to innovation & revenue?

This post sponsored by the Enterprise CIO Forum and HP.

Plumbing By BodHack on flickrApplication Modernization….only two words…but two words that denote a big undertaking for most organizations.

I’ve touched on the subject of modernizing applications and infrastructure, in a few posts in the past (see here and here).  In my consulting efforts, I’ve run across many CIO’s and IT professionals who would love to do nothing but focus on modernizing their legacy systems to be better prepared for the future.  Most have failed at making the case for these modernization projects – namely because the organization sees them as ‘plumbing’ projects.

People see these ‘plumbing’ projects as something that don’t necessarily need to be done  – re-plumbing the organization won’t really deliver in new value or competitive advantage they argue.  They see these projects as being something that can be scheduled when the IT staff has downtime…but we all know there’s little downtime for today’s IT.

I’ve been asked by a few CIO’s in the past to help them justify these modernization projects…and I have to say that its one of the hardest things an IT team can do today. The reason its so hard – because most modernization projects are attempting to replace or improve something that is working just fine today.  Many organizations don’t see the value in spending millions of dollars on a perfectly capable application.

Let’s look at an example. Imagine you’ve been tasked by your CIO to put together a business case for a revamp / rebuild of your data center.  You put together spreadsheets that show costs for new equipment and infrastructure.  You provide a reasonable argument about what the redesign needs to take place.  You use charts, numbers and lots of language to try to build your argument.

After spending days (or weeks or months) putting this business case together, you present it to the CIO and IT leadership team. They are blown away with your research and presentation. You are feeling on top of the world….but then the CIO asks one question that deflates your ego quickly.  He asks the one question that seems to matter the most – if this project isn’t started today, will the current data center be able to handle ongoing operations for the coming year? What about 2 years?

Now…sometimes the answer to that question is no….but many times, the answer is yes.  If the IT staff has done their job, the data center has been keeping up with the times and the current architecture can handle anything the current organization can throw at it.

So…if your answer to the CIO’s question is ‘yes…the data center can hold up for another year or two’…then what chance do you have of getting funded to rebuild said data center? {hint: your chance is close to zero}.

In order to make these types of projects seem valuable to the organization, you must show real value and opportunity.

From plumbing to innovation driver

So….you need to get your application modernization project funded…but you can’t quite seem to get the business to understand why they should spend a few hundreds of thousands (or millions) of dollars to  rebuild something that’s working perfectly today.  Sure…they understand that the money will have to be spent eventually to improve the infrastructure / application at some point in the future…but they know they don’t have to do it today.

So…how do you get a project funded that, according to the business leadership, doesn’t need to be funded?

You’ve got to sell the business on the value of the project.  You’ve got to sell the business on the value of what the ‘plumbing’ project can bring once completed.  Most importantly…you’ve got to remove the stigma of the project as being a ‘plumbing’ project and show why the project is much more important than that.

Let’s revisit that data center project above.  You can throw together charts and numbers all day long…but at the end of the data, your asking for money to upgrade a data center that does what it needs to do today.

But…what if you were able to show how your data center upgrade could help to drive new revenue?  What if you can show innovative ways to use the new hardware and/or new software to drive innovation?

Imagine being able to put together a proposal that can show an immediate or short term payback for the investment? Imagine what the CEO would say if you told her that your investment of $350,000 this year in new infrastructure could lead to new services with the possibility of $1.5 million in revenue over the next 2 years?  Your CEO would have to take a long hard look at your project, wouldn’t they?

If you need examples of companies doing this today, look at Amazon’s additional revenue from their IT infrastructure (AWS, EC2, etc).  Think about your infrastructure and how it might be able to provide new revenue opportunities for your business.  Would your modernization project provide more opportunities for revenue? More opportunities for better service and/or new services?

Whether you’re talking about a data center upgrade, data warehouse upgrade or legacy application rewrite, the modernization project is a tough one to get approved for most IT groups. Next time you’re looking at getting funding for an application modernization project, take some time to think about how that new application / infrastructure can be used to deliver bottom line (or top line) value to the company.

Rather than focus on the money that your project needs from the business, focus on money your project can deliver to the organization in the coming years.  In the end, to get your modernization project funded, you’ve got to show the business that its not just a ‘plumbing’ project. You’ve got to show the roadmap to innovation and revenue…you’ll be surprised at how much more you can get done when people see a return on what had been thought of as simple ‘plumbing’ project.

Image Credit: Plumbing By BodHack on flickr

This post sponsored by the Enterprise CIO Forum and HP.