Continuous development and decision records
This is part of a series discussing our practices and values in the context of unemployment insurance modernization with the US and NJ DOL.
We build great software and teams. The former can’t happen without the latter, which is why we embedded our crew alongside the US and NJ DOL for the entire ride in modernizing unemployment insurance (UI). We worked together to uncover needs, improve processes, and made sure they could continue to scale long after we’re gone.
Early in our work period, we ran into a critical problem for project success: reconciling a tight timeline with decades of out-of-sync technology and practices. To meet this challenge, our engineering leads (Brandon Lenz and Josh Clarridge) and product leads (Dudley Emmert and Greg Troester) built alliances with our client team to modernize their software development practices and solidify their decision making protocol. Throughout our contract, major stakeholders appreciated our teamwork — one thanking us for “increas[ing] our skill sets and improv[ing] existing ways of working.”
Continuous development
We believe modern software development should be incremental and iterative, and thus delivered continuously, guided by human-centered design principles and research. Wherever possible, we automate those processes—including basic functionality, usability, accessibility, and security checks—to run at regular, frequent intervals. We also acknowledge that feedback and testing inform better solutions, so we are always prepared to adapt and iterate.
Combining Agile methodologies with a robust CI/CD pipeline, we were able to run experiments and refine them into completed features. This ultimately allowed us to deliver a high-impact set of improvements for claimants as well as state and federal agencies.
Our first year with the USDOL was focused on broadly understanding the landscape of UI modernization and capacity for change across states and territories. We then proceeded with their goal of building a centralized intake system that all states might be able to use. However we found that states had too many barriers to adopting the central model. This prompted us in our second year, partnering with one state (New Jersey), to build a more customized solution and learn more about the degree of uniqueness.
From a technical perspective, this was foundationally different, though most of the form interface we had just built was relevant to NJDOL’s needs. Because of this, large swaths of presentational code were reusable, though some of the core architecture needed reimagining. We worked closely with NJDOL and other contractors to continuously evaluate how best to integrate the UI Intake Application so the application could perform crucial functions and reduce the possibility of fraudulent claims. Examples of these systems were their…
New Jersey single sign on (SSO) services
Social Security Identification validation service
Driver’s License validation service
Wage record lookup service
Mailing/residence address validation service
UI agents’ system for managing claims
Mainframe / system of record
Rather than take a blanket-policy approach, we evaluated each legacy system’s…
Usability and capabilities
License agreement
Infrastructural availability
Timeline to eventual replacement of the system
Stability
Security
In most cases, accommodations had to be made that allowed the project to move forward, while shoring-up functional or security weaknesses in legacy systems. This was to ensure the teams had a healthy capacity and time to properly vet replacements and ensure long-term success of UI Modernization. Some of these legacy systems—though serving long and well—still hold considerable (sometimes crushing) technical debt and potential for profound service disruption when disturbed. Even updated documentation can be impossible to deliver, so organizational memory is often the most reliable, though imperfect.
Our fellow contractor, Nava, demonstrated a forensic approach that we believe is a best practice here: devoting up-front engineering resources to document and diagram how each legacy system worked and interacted with other systems. Not only does this provide those table-stakes docs, but it also makes conversations with SMEs much more efficient. This reduces the burden on state employees to divide their time between already full-time jobs and additional work required of them in order to modernize the systems they use. This, of course, needs to be accounted for in time and resources during the initial planning and contracting.
Our modernization work with NJ DOL’s IT organization included building new hosting environments in the AWS cloud and delivery pipelines to facilitate rapid integration and deployment of software changes. Leveraging cloud-based infrastructure significantly decreases the time needed to deploy new systems and scale the resources as demand increases (think seasonal work variations and events like the pandemic). We followed general best practices to architect the system for increased reliability and uptime, and utilized our standard infrastructure as code approach to provision environments quickly, consistently, and securely. We built CI/CD workflows to automate the build, test, and deployment of application changes. One was an early “steel cable” pipeline that ensured access to every level of infrastructure available, from engineer development environments to user-facing production. It was then expanded to serve the intake application as it is developed. This pipeline is still a living, evolving piece of infrastructure adapted to suit the application’s delivery needs as it evolves in tandem.
What we delivered is lean and maintainable enough for one state to support the application, but also flexible enough to encourage iteration and improvement. The modern tools used serve as an example for other states to follow, improving modernization confidence, and lowering barriers to adoption.
Decision Records
Truss uses “decision records”—a general-purpose version of architectural decision records (ADR)—to document both engineering and non-engineering decisions, including:
A decision that needed to be made or problem to be solved
Context surrounding the situation
What options were apparent, including their perceived pros and cons
A recommendation from members of the team to the person or people who ultimately needed to decide which option to pursue
The decision, who made it, and why
How (if needed) to undo the decision
Screenshot of a decision record on our React-USWDS project
We assume that perfect understanding of a situation and how it will play out in the future is impossible. Therefore, the goal of decision records is not to place blame for decisions that turn out to yield suboptimal results, but rather to make it clear what decision was made and why.
By documenting what is known at a given time, it is possible to continuously improve our decision-making processes and efficiently communicate nuanced decisions to team members at any time.
The Truss product team—especially engineering—embraced this from day one, and eventually we used it with stakeholders to guide NJDOL in reaching a decision in a complex space with many unknowns. Around the midpoint of the second year, we formed a “Decision Record Working Group” with key stakeholders from NJDOL and other contractors. This process was embraced nearly immediately, as it brought clarity to trade-offs and allowed stakeholders to compare the merits of multiple decisions. It also enabled them to fully describe a decision to be made later, when they determined it could not or should not be made at that time.
This process greatly improved focus and throughput of quality work, because it allowed the entire team to devote more time to developing features and functionality that supported a thoroughly and clearly documented decision. By the end of our contract, we had documented a dozen# decision records.
While this is standard Truss practice, we still find ways to improve. We learned in this project that starting this process sooner would have gotten our clients comfortable with it sooner. With that, we could have more quickly identified key stakeholders and experts that moved the process forward. It also would have better surfaced and qualified the risk that the client took on by delaying decisions or making alternative decisions.
How does this story resonate with you? Are your claimants stuck with a slow, out-of-date process when it comes to accessing their money? Truss can help. Please let us know what questions you have. We’d be happy to jump on a quick call and open up the conversation.
This is part of a series discussing our practices and values in the context of unemployment insurance modernization with the US and NJ DOL: