The Harmonized Tariff Schedule (HTS) is a detailed breakdown of goods and the associated tariffs (custom duties) owed when they are imported into the United States. The U.S International Trade Commission publishes and maintains the Schedule while U.S Customs and Border Protection enforces the classifications and collects the duties.
As part of the modernization efforts at CBP to update legacy systems that dated back about 30 years, we were tasked with migrating the Harmonized Tariff Schedule’s system of maintenance into the new application environment. The HTS is the heart of the entire import operation. It is what is referenced when duties are calculated for the Santa Clause outfit imported from China. It is also what gets updated when a trade agreement (like NAFTA) goes into effect.
When it comes to refactoring code, one of the biggest challenges is understanding what the existing code is doing. This becomes extremely difficult when the code is written in a language that no one seems to use anymore. In the case of the CBP legacy systems, the language of choice was COBOL.
Since none of our Java developers also moonlighted as COBOL developers, it was often hard to understand the logic in the old scripts. Trying to figure out if a data element, such as a boolean flag, was required for technical reasons versus business reasons often took asking our subject matter experts a long series of roundabout questions.
20-year-old user manuals, disjointed system documentation, along with complex business rules and data validations made it difficult to comprehend let alone translate into clear, concise user stories and technical requirements.
Since the system, the subject, and the process at hand were completely foreign to me and my team, I had to use all the resources I had at my disposal to get a full understanding of the technical, functional and business requirements.
I spoke with our subject matter experts at length about their workflow and created process flows for them to validate. I read and re-read the 20-year-old user guide for the legacy system to reinforce the topics discussed by our SMEs.
I printed out screen shots of the old ‘green screens’ and mapped the input fields on the ‘UI’ to database fields. Having familiarized myself with the process, the data elements, and the system functionalities, I was able to read through the old COBOL scripts with new context. This, in turn, gave better clarity to the complex business rules and data validations.
When it came time to translate this information into requirements for our developers to quickly understand and implement, I opt for whichever conveys that information best, whether that be a process flow, a spreadsheet or an interactive prototype.
Understanding a problem often requires more than just asking the right questions. It also takes patience, diligent research, careful analysis, and sometimes having to put together pieces of a very large and complex puzzle you weren’t prepared for. I’ve learned that you can’t be afraid to jump into unfamiliar territory to find the answers you’re looking for.
Paper prototyping the UI layout. CBP uses a common Twitter Bootstrap UI library shared across all of its applications. To maintain uniformity across the different applications, development teams are encouraged to use this general 2-column layout.
Adding some "content" to the paper prototypes. Placeholders for: an inbox, search panel, search results, record details.
Post-its are great for quick user feedback. This was used during a design discussion with our subject matter experts to determine what search parameters should be included.