Skip to content

SIRMM Modernization

Three generations of security incident modernization.

A JSP monolith carried into a Spring Boot rewrite, now redesigned around clean architecture and a schema consolidated from 308 tables to 61.

At a glance
~3.9k incidents/year · Bilingual EN/FR · Kerberos/SPNEGO SSO · Shipped April 2025
Key terms
EIMET: Emergency and Incident Management Electronic Tool: CRA’s umbrella application
SIRMM: Security Incident Reporting and Management Module
BCMM: Business Continuity Management Module
ERMM: Emergency Response Management Module
EJB: Enterprise JavaBeans: legacy Java RPC framework
JSP: JavaServer Pages: server-side Java templating

Evolution

Project Trajectory
v2 begins
Funded Spring Boot rewrite kicks off
Year 1–2
Lead carries the full stack: schema, services, UI, deploys
Burnout
Lead requests to move off project; second dev promoted to help
Stall
Second dev cannot close the gap: codebase complexity too high
Departure
Original lead leaves the project; no clear owner for the codebase
I join
Inherited the codebase, stabilized delivery, shipped to production
Today
v2 running in production; v3 clean-architecture redesign under way
Legacy→Rewrite→Redesign
1
SIRMM v1 (Legacy)
Legacy Monolith
148
JSP Pages
308
Tables
55 servlets behind one EJB session bean
Ant build
9 incident types, 34 subtypes
5 resource bundle pairs (en_CA / fr_CA)
Kerberos/SPNEGO authentication
2
SIRMM v2 (Active)
Spring Boot Rewrite
196
Angular Components
1 WAR
Angular + Spring Boot on WildFly
Maven + Angular build
EJB integration with the BCMM/ERMM application
Same 9 / 34 incident schema
In production today
3
SIRMM v3 (Design)
Clean Architecture
61
Tables (from 308+)
7
Domain Services
Core, Submission, Transfer, Summary, Document, Action, SIR lifecycle
Preserves all 34 subtypes
Kerberos/SPNEGO + LDAP

Context

EIMET is the CRA application that carries three modules: SIRMM (security incident reporting), BCMM (business continuity) and ERMM (emergency response). Legacy EIMET ran as two applications over two databases. The SIRMM side, 148 JSPs, 55 servlets and a 308-table schema behind one EJB session bean, is what became SIRMM 2.0. The BCMM/ERMM side stayed on ICEFaces with 26 custom tag components, still reached from SIRMM over EJB.

Architecture

Angular SPA and Spring Boot backend ship as one WAR on WildFly, over the Oracle schema v2 inherited from v1, with five enterprise integrations.

CRA Staff
Domain-joined workstations
HTTPS
EIMET System
Angular SPA
Angular 16 + TypeScript + Material
13 modules
IncidentsRisk AssessmentReportsWorkshelfSearchMetricsAdmin
JSON / REST
Spring Boot WAR
Java 8 + Spring Boot 2.7 + Hibernate
8 components
REST APIBusiness LogicData AccessSecurity & AuthMetricsEmailFeature FlagsScheduler
JDBC / JPA
Oracle
Schema inherited from v1 · Liquibase-managed
Enterprise Integrations
Kerberos / KDC
SPNEGO
SSO authentication
Active Directory
LDAP
Employee lookup, auth fallback
ATLS Audit
SOAP
SIN/BN access compliance
SMTP
SMTP
Workflow notifications
Jira
Webhook
Error and health alerting
Angular assets are bundled into the WAR's static/ and deployed to WildFly 16 as one artefact. No CORS and one release to coordinate; the price is that a front-end fix redeploys the backend

Incident lifecycle

Which SIR actions a user sees is a lookup on role and status, not a coded transition. Information-breach incidents take the risk-assessment branch.

Main flow
Draft
Reporter has saved the incident but not submitted it
Submit
Submitted
Awaiting coordinator acceptance
Coordinator accepts
In Progress
Active hub
Every branch returns here before the incident can close
CloseTransferInfo breach RA
Close
Closed
Terminal
Resolved and retained for audit
Transfer loop
In Progress
Transfer
Transferred
Temporary
Reassigned to another coordinator or branch
Accept, back to In Progress
RA loop
In Progress
Info breach
Pending RA
Awaiting RA
Risk assessment required before the incident can close
RA complete, back to In Progress
There is no transition table in code. Available SIR actions come from RoleToStatusToSirAction, a data-driven matrix of role × status, so business can add a transition without a release. The price is that the lifecycle cannot be read from the source alone

Delivery

Two-week sprints, twelve developers, and no room in the schedule for broad test coverage. Automation went where regressions actually recur: every reported defect got a test that reproduced it, and the test merged with the fix. The suite grew along the paths that had already proven they could break.

Rollout was graduated. Administrators and directors first, then coordinators and programme officials, then the agency. A toggle in the UI let pilot users move between SIRMM 1.0 and 2.0, so a defect found in the pilot cost a switch back rather than a rollback.

Key architectural decisions

SIRMM v2SIRMM v3
T1: Scope
Split SIRMM 2.0 out of the three-module EIMET delivery and halved the sprint from four weeks to two.
The programme had committed to modernizing SIRMM, BCMM and ERMM together, and the combined scope was already slipping. Separating SIRMM meant one module could ship on its own, and a two-week sprint put working software in front of stakeholders often enough to correct course. SIRMM 2.0 shipped in April 2025. BCMM and ERMM moved to a separate project, so the EJB seam between the two applications survived the modernization and still has to be maintained.
1 / 8
Worked across all three generations of CRA's security incident module. Inherited a stalled Spring Boot rewrite, stabilized delivery, and shipped it to production. The v3 redesign consolidates 308+ tables to 61 and splits the monolith into seven domain services.