For the application modernization phase of the project, FlowFactor used three primary components to transform the transit company’s applications into modular, containerized architectures:
- IBM Transformation Advisor software scanned the applications and configurations and recommended steps for modernizing the apps from traditional WebSphere Application Server to the lightweight, cloud-native IBM WebSphere Liberty runtime in containers. Although the number of steps per application created the impression that the task was large and daunting, FlowFactor used its experience to identify common code across many of the applications, allowing for reuse. Thus, after modernizing the first application, the rest took relatively little work.
- IBM WebSphere Liberty provided a lightweight application runtime ideal for running the modernized applications in a containerized, hybrid cloud environment. (Transformation Advisor, WebSphere Liberty and traditional WebSphere are all available in IBM WebSphere Hybrid Edition.)
- The Red Hat® OpenShift® (link resides outside of ibm.com) platform and Open Liberty Operator provided deployment automation and container orchestration, streamlining the automation of workflows between development, test and production environments.
FlowFactor also reengineered the customer’s build pipeline, creating standardized, reusable processes. From there, the team applied open-source Jenkins automation software end to end, from initial build processes through production deployment. Thanks to the new app architecture, the Jenkins software can automate movement of containerized code across the full software lifecycle.
But all of that was only part of the project.
In public transportation, getting people on board is the simple part. In app modernization, it can be the hard part. It’s one thing to implement technology that automates processes; it’s quite another to get people to evolve how they work in ways that will get the most value out of the automation.
FlowFactor needed to help the transport company shift its culture to embrace automation and adopt DevOps practices.
“Definitely in large, more traditional customers and governments, it is a sensitive topic,” explains Niemegeerts. Engineers and others with expertise in existing processes pose serious questions: Will such drastic change break what actually works well? Will their jobs simply be automated away?
“The main thing there,” says Niemegeerts, “is we need to find a balance, to automate a lot and still involve the original engineers and explain to them what will stay the same. We show them that their jobs are never really replaced, they’re just altered. The most important part is, they will do the more interesting part of their job more often and not the repetitive stuff. It’s giving them time to troubleshoot more, to investigate more, to innovate more.”
Niemegeerts continues: “As soon as we start delivering some first candidates of the applications that are modernized, they notice the advantage. They see the faster deploy times, less impact. No long maintenance windows required to deploy a new application.”
And DevOps becomes the way to get the most out of the faster, more flexible processes. This is where the previously siloed teams learn to balance their responsibilities and collaborate more efficiently and more agilely. As Janssen explains: “In the past, application availability was the responsibility of the infrastructure team. Now, when the infrastructure team sees that the development team is taking responsibility to bring stability—not just new features—into production, the mind shift starts and the process really starts running and delivering new applications.”
As for the dev side, says Janssen, “The development team gets a lot more power. They can now deploy when they want, to any of their environments.”