SitaWare Frontline & Edge

SitaWare is Systematic's command-and-control (C2) product line. SitaWare Frontline runs on the platform a soldier carries; SitaWare Edge runs on smaller, lighter devices closer to the edge of the network; SitaWare STC sits at the higher echelons of the same picture. They share the same problem: deliver an accurate, shared operational picture under conditions where the network is bad, the device is constrained, and the cost of a wrong message is real. Systematic builds mission-critical software for defence and the public sector, and the suite is in operational use across NATO and partner nations, which means interoperability is not a feature: it is the product.

I joined as a Junior Systems Engineer for a 25-week engineering internship and was placed on a Scrum team working on the web client. The first two weeks were onboarding: business areas, the Feature-Driven Development methodology Systematic uses, the architecture of the project, and the toolchain (Bitbucket, Jira, the build pipeline, and the code-review culture that comes with shipping software people stake decisions on). Daily standups, sprint planning, story estimates, feature kick-offs, feature briefings: the full Scrum cadence rather than a watered-down version of it.

From week three onward I was contributing in the same loop as the rest of the team:

• Feature work. I picked up user stories on a feature in the web client, took them from prototype through implementation, qualification, and the documentation that has to ship with a defence product. One late-internship block was a feature where I implemented the last user stories, refactored on feedback from the feature lead, and added the automated coverage that signed it off.
• Defects and quality verification. Triaging and fixing defects against a release; verifying user stories implemented by other developers (including a senior with twenty-five years on the product); running manual and exploratory test setups across old and new application versions to confirm backwards compatibility.
• Test automation. A meaningful share of the internship was UI-level integration tests in Robot Framework with Python (including introducing the Page Object pattern to a component of the client), Cucumber / Gherkin scenarios closer to behaviour, and JUnit-style coverage closer to the code. Working with a Test Engineer to map system requirements onto the test set was, in hindsight, where the QA mindset that still shapes how I work was forged.
• CI/CD and host automation. Two configuration-management tasks late in the internship: small PowerShell scripts that filled gaps in the build pipeline and automated housekeeping on the remote hosting servers and issue trackers (one watched documentation changes on PRs, the other surfaced expiring development licences as defects). Tiny, but the kind of housekeeping that compounds.
• Architecture conversations. A refactoring discussion with the lead architect of the web client over a structural impediment to a story I was developing: my first taste of how senior engineers reason about long-lived codebases under feature pressure.

The internship ended with a technical report, two logbooks, and a work-placement presentation handed back to VIA University College. The throughline was simple: ship code that holds up, write tests that catch what the manual ones miss, and respect the mission, because the people on the other end will.