Interview

How did you predict or determine whether the client needed a user interface facelift versus a full redevelopment or redesign effort?

Alan Katawazi: 

It really is a bit of an art, isn't it? Being able to go in and we have this phrase, "software archeology." We have to discover what's going on. Can you elaborate on methodology related to really getting in there and figuring out what the client needs? And I know we discussed this earlier, not only discovering what they need, but predicting what they're going to need.

Was it partially motivated by modernization in general? Getting into the cloud?

Alan Katawazi: 

Well, that may have been part of the driver. Many times it is a large portion of the conversation. It's a big checkbox for organizations to be able to say, "Hey, we're in the cloud, we're an entity that has the ability to scale and be secure." Sometimes the company doesn't need their entire software stack replaced. Sometimes they just need a user modernization, a user interface modernization of their solution.

Tell us about this specific project. What was the size and scope of it?

Shawn Livermore: 

This specific example I'm giving us for one of the largest financial payment processing companies in their specific category in the United States. They process around 17 billion dollars a year through their platform. And so - we went in and did a multi-year project that allowed us to give a top-layer facelift to modernize just their user experience and nothing beneath it. It was not easy. It was very complex because they were unable to, as you stated, replace the whole technology stack. They had about 15 years' worth of technical debt in this application. It had over 750 webpages in it. A portion of those were not even used anymore. About 500 total web pages were in use and they needed a facelift. And so we went in and provided moved them up to the bootstrap framework on standard HTML type formats and standards and upgraded the approach of which browsers they were using. They had to require their clients use Internet Explorer and in compatibility mode, even.

Alan Katawazi: 

Right. This user experience modernization, 750 screens. How did that work? It seems like a daunting task, but the methodology and the process that was in place to do it is really, really quite interesting.

Shawn Livermore:

There was a framework level effort, and then there was a platform effort and then a user experience effort. We moved them from early version of the .net framework to one of the most modern versions. We replaced their requirement for Internet Explorer and now they can use any modern browser and then moving into the actual user interface of data grids and profile pages. And there's just so much that you're constrained to because you can't remove all the functionality. You're just trying to reformat it, and so that can be very challenging. In that code base had 15 years of technical debt, code atrophy, not the best practices observed. There was an architectural deficit and inconsistency across several different lenses if you look at the prism of the code and how it's constructed. But overall, we were able to allocate resources toward every single angle that required effort and repurpose over 750 or so webpages to now have a fully consistent, modernized look and feel. And so the client was able to preserve all their enterprise knowledge and very specific business rules in the code base, and yet take advantage of some of the modern web-based practices that are on the market today.

750 Web Pages, 15 years of technical debt, 20 developers, 18 months

Alan Katawazi: 

To be clear, there were hundreds of pages and all that was left intact in place so that institutional knowledge was still there, but from the user's perspective, a completely modernized user experience and a lift, a technology lift from an old .net framework to a modern one.

Shawn Livermore:

Yeah. And that's kind of what the idea was is that this project would, would provide air cover while the modernization efforts in parallel allowed the client to catch up holistically with a full rebuild or a replatforming for their flagship products. Definitely multiple layers of complexity, multiple teams of developers across multiple continents and literally hundreds of people involved, and it all came through and launched and was successful. Truly, the client is now in a much better position because they can take advantage of everything they couldn't before. They can leverage APIs, they can use any browser, they can take advantage of all the accessibility features that some of the third-party products are able to use now, meeting the standards of their clients. Some of these clients of theirs are large financial institutions themselves, which have government-mandated accessibility frameworks that they have to adhere to for those with sight impairments or different sorts of tools that they use within the browser. We were able to move them forward on multiple layers, multiple levels, simultaneously with this one project.

What were some of the advantages of doing just the facelift and not the full rewrite of the codebase?

Shawn Livermore:

Well for starters, the client was able to retain 15 years worth of intellectual property without having to go back and retrace their steps in detailed documents or large flowcharts or similar. They saved millions of dollars this way for sure. Plus, we found ways of simplifying their web application's HTML markup so that it was a much smaller footprint of code. So technically, some of their technical debt was reduced even without the full rewrite. So time, money, and of course then there's also the advantage of avoiding the distraction of the client's operational and business folks. They didn't have to take their eyes off of existing business opportunities and projects in order to facilitate a full rewrite. That's key. Because of course, when you embark on these multi-year efforts, rewrites are not simple or easy, and they typically will pull your best people into the project for months and months...

‍

‍