Corneil du Plessis, Chief Software Architect and Problem Solver at JumpCO Consulting
Corneil du Plessis, Chief Software Architect and Problem Solver at JumpCO Consulting, shares his account of an experience reconstructing a software programme for a major South African insurance company
The Chief Technical Officer of a large insurance company was driving out the decision to move all enterprise applications onto WebSphere Application Server. The head of one of the business divisions engaged JumpCO Consulting as an IBM Partner to help them move from Glassfish Application Server to WebSphere. This turned into a journey that took four years, but it resulted in accelerating the pace and quality of their software delivery.
The system in question had already been a decade in development. For most of that time, it was in production with regular updates and improvements. The division was running a mature Scrum process with seven teams of about four to seven people, releasing once a month.
We quickly identified the brittle build process as an obstacle to success during the migration because the local developer experience was frustrated. They could only test a small part of the system locally while interacting with many remote components and services. The root cause was dependency management.
The project was made up of over 300 modules — five were Java Web applications, about 40 were (Enterprise Java Bean) EJB applications and about 50 were Java CORBA servers — while the rest were libraries consumed by these applications. A developer could only run a few of these applications locally at any point in time. They needed to be sure they weren’t using the wrong version of the libraries or their dependencies.
We tried to use Maven but quickly realised it couldn’t deal well with a project that size. We then tried Gradle which had just been released at the time. The project had used Ivy as a means of describing modules and their dependencies and so we wrote a script to scan the path for ivy.xml files and dynamically generate Gradle build files that would properly reference local and remote dependencies.
We established a central continuous integration process to build code as it was committed. Very soon developers had a stable development experience. The central build used to take an hour or more, but after switching to Gradle the average build time was typically less than five minutes but occasionally more than twenty. We needed only to build the components that changed.
Eventually, the builds for releases into pre-production and production weren’t full rebuilds. We rebuilt and deployed only the modules that were affected by changes.
Releases went from a six-hour ordeal to a one-hour chat while we waited for testers to tell us all was well. The organisation moved from four-week sprints to two-week sprints.
The risk associated with moving to WebSphere and upgrading to newer versions of WebSphere was reduced to the extent that it is now, conveniently, a non-event!
At the time there wasn’t a clear understanding of the term DevOps. Looking back one can see that this was an adventure in DevOps with a happy ending for everyone involved.
If your company is building Java or Spring Boot applications — or would like to — we’d love to think it through with your CTO. Give us a call on +27 11 431-1666 or email Corneil du Plessis on info@jumpco.io
