FEBRUARY 9, 2016 // By Ryan Hanisco
With so much of the industry talking about preventing disruption and driving digital transformation, a lot of businesses find it hard to even know where to start in modernizing the applications that are at the heart of their business. The harsh reality is that many organizations stopped investing in their applications as the economy went through recession and focused on just keeping the lights on.
While this was often a critical necessity, many businesses are now evaluating their application portfolios to find that they aren’t as agile as they would like and that their applications aren’t as relevant in today’s market. Ecommerce and web applications find that their user experience (UX) is now being compared to the marketplace as a whole rather than to just their competition. Line of business applications are based on technology that is harder to maintain and test, and that the skill sets needed to maintain them are harder to hire to. Data applications can’t cope with the volume of data created and can’t monetize the depth and interconnections that exist in the information sets.
Even where the focus wasn’t completely shifted away, there is a natural application lifecycle that occurs as investment in an application shifts from innovation, to active development, to maintenance and support. This maturation process occurs as the application becomes harder to evolve and as critical resources – time, talent, and capital – are moved to more urgent priorities. If a direct investment isn’t consciously made toward maintaining agility, this “agility pressure” will drive the organization to focus elsewhere.
An organization looking to modernize their applications will have three viable options.
Ground Up Development – While this might sound like completely starting over, this is a much more directed process than beginning from nothing. The organization has had significant experience knowing what works, what doesn’t, and how they will actually use the application on a day-to-day basis. This is an opportunity to look at all the things that you wish the application did better and set a new course.
In this case, the organization can work in a true agile fashion, defining the user stories covering the needed functionality and come at the design and architecture with a completely new take. This does take some discipline to not do things the same way just because that’s how they were always done, but the process can be innovative and constructive with strong leadership.
Test Case Driven – In cases where there is a reluctance to document the functionality from the top down, many companies will choose to write the test cases that the existing system will pass and then choose to implement against those test cases. If the new application can pass all of the tests, then it is to be accepted as meeting the functional needs.
Organizations will often choose this when they need to match some outputs exactly or where the requirements are poorly documented, but where they have built a significant test suite to manage their update/ deployment process. This does have pitfalls where some of the application might not be covered by tests but it can allow some subsystems to be reused where the technology matches and can lower costs where there are complex integrations or data exchange that will not be rewritten.
Codebase Rewrite – Lastly, some organizations will look for automated tools or partial rewrites to migrate the existing code, warts and all. While it is attractive to think that there is some automated system out there that will be able to convert the code with little human intervention, I find that most companies that start down this path will eventually settle on one of the other paths unless they can contain the rewrite to just refactoring a fairly isolated piece.
Evaluating what to Modernize
I never advocate taking a shotgun approach to application modernization, that is wanting to do a one-for-one migration of an app. There are always things that the business wants to do differently, parts of the application that are rarely used, or even some cases where a problem in the application’s workflow has led to new behaviors to be ingrained in the business as a work-around.
Instead, I always recommend that businesses look at their existing feature set (User Stories, Test Cases, BRD) and really evaluate it into the following categories. This is an opportunity to take a real look at what you’re building and to best align it to the needs your business has today.
Taking this approach will drive great conversations amongst your product owners and will shape the approach to the project. This will help your team build the modernization roadmap and focus everyone on building the right thing the first time.
If you’d like to contact Magenic directly, email us or call us at 877-277-1044.