Navigating Customer Service Pack Delivery Alongside Focused Release Efforts

This Tech Byte provides insight into how Systematic’s developers adapt to changing situations and priorities within a release cycle. It is a story about delivering customer service packs while the software release code stop is looming closer on SitaWare Mobile - two device-independent applications operating in a cross-platform environment offer solutions for the first line of military defence.

By Andrei Ghideu, Senior Software Developer for SitaWare Mobile

Synchronising architectures in a multi-platform environment 

Delivering military defence software has special requirements—systems must operate in strenuous situations, demanding physical surroundings, and often over long distances. Our developers must consider these challenges carefully and create robust implementations when developing such software. They do this by, among other things, carefully catering to real-life situations in the code, test, and delivery to operations. 

SitaWare Mobile is a software solution project that offers solutions for the first line of military defence. It has released three major software versions. The main applications are SitaWare Frontline for Windows and Linux and SitaWare Edge for Android, followed by SitaWare Tactical Communication (STC), an essential piece of Mobile’s ecosystem. 

Cost in maintaining multiple codebases 

The objective is to deliver software for desktop and mobile environments, but the way this was done early in the project differed between the various applications and technologies. When SitaWare Frontline and Edge 2.x were active a few years ago, the two applications had different codebases, with Edge lacking features. That resulted in a higher cost to maintain both codebases. It is also worth mentioning that Symbology, a critical functionality in reporting information about military units, was not aligned between the two applications because symbols were illustrated differently—other issues related to SitaWare Suite alignment were backwards compatibility and the need for 3D maps. 

The release of SitaWare Frontline and Edge 3.0, written from scratch, changed this situation. These versions introduced product suite alignment using the map engine developed in-house for SitaWare Headquarters (HQ). 

Write features once and deploy them on 3 platforms! 

Now, both mobile applications share a higher level of core codebase, with a minority part differing due to required specific implementations. The technology stack was upgraded from Java and Java UI-related frameworks 2.x to Java and Angular for UI in 3.x. 

To achieve all of this, a clear scope was defined in 2020: Write features once and deploy them on Android, Linux, and Windows, and this is still active today!

The technology stack is strongly connected to synchronised architectures, with Frontline and Edge using Java 11 for backend implementation and Angular 15 for the frontend solution. 

The modularised architecture has a strong foundation with the dependency injection framework used: Dagger 2 version. But why Dagger and not Spring Boot? Dagger offers a lightweight solution, which perfectly suits Edge’s requirement for support of a significant variation of hardware and old firmware. Even though Google created Dagger focused on Android, it can easily be used on core databases and the backend. For the UI, Angular offers the necessary support for a common UI to fill the content on each type of device: a smaller one like a phone, a medium one like a tablet and a larger one like a laptop.

However, having both applications tested more intensely in a real-world environment highlighted some issues, especially on a network add-on for radio communication for longer distances. For example, in our test environment, we tested the connection between two devices, and we were expecting to have a timeout after a couple of seconds when one device did not respond in time. In a real-world environment, the distance between devices might be vast, and that timeout can be several minutes, and the time must be configurable by the user. 

Simulate behaviour in same conditions as real radio communication 

The upgrades also contained bug fixes to improve the overall experience for the customer, so the priorities were changed to service packs. At the same time, the rest of the team worked on delivering the features for the current release. I participated in this task, switching from feature work to finding performing, scalable and stable solutions for the reported issues and ensuring the fixes would be completed within a fixed deadline. The key people I worked with were the tester from my team, the project architect and the program test manager.

• "…you can work with some abstract features (e.g., simplified deployment), and you will only understand the bigger picture once you are exposed to how the customer uses that delivered feature and how much it improves their workflow.”
  

  Andrei Ghideu
  Senior Software Developer for SitaWare Mobile

Testing limitations were a massive challenge for this task because the customers using the network add-on have restrictions on radio transmission, so Systematic had limited access to an actual device, in our case, a radio, that could easily reproduce the issues. A positive influence was the SitaWare Tactical Communication (STC) team's contribution, which helped us simulate the behaviour in the same conditions as real radio communication. However, a simulation is still inaccurate, so you know there’s a slight chance that the fix discussed carefully with the architect, tested thoroughly by the go-to person for that area where issues were reported, could not be enough to fix the problem for customers. 

I was intrigued by the complexity of the issues because it was the first time I had to work on these kinds of incidents. I knew that my contribution could be more hands-on with a specific customer who needed the fix urgently, while our features were oriented to be delivered to multiple customers. To give some context, you can work with some abstract features (e.g., simplified deployment), and you will only understand the bigger picture once you are exposed to how the customer uses that delivered feature and how much it improves their workflow. It also helped that the functional area was familiar to me.