CASE STUDY 01
Winning the National Fingerprint Search Contract
How simulation proved the architecture and helped win the program
AFIS was a technically complex problem that required a specific kind of solution — and finding that solution required getting deep into the machine, alone, until the answer emerged. That capacity for independent, unstructured problem-solving never left. What changed afterward was the scale of the problems and the context in which they had to be solved — moving from engineering rooms to boardrooms, from algorithms to operations, from individual contribution to executive accountability. If you are working through a problem that requires someone who can operate across that range, let's talk.
The Full Story
Before the FBI procured AFIS, its national fingerprint search system, the process of identifying someone with a criminal record in another state was slow enough to be nearly useless. Local law enforcement would ink a suspect's fingers, mail the card to the FBI, and wait. By the time the answer came back, days or weeks later, the person could be long gone. The FBI wanted to change that — AFIS would accept digital submissions from across the country, search a massive database, and return answers fast enough to matter.
There is only one FBI and only one competition to build AFIS. Lockheed Martin was either going to win that work or someone else was. I was a young engineer and was assigned to build a simulation that would help prove our proposed design could do the job.
That assignment became an eighteen-month grind. My background was Systems Engineering, not computer science — I had written some Visual Basic and Fortran, mostly in practical or academic settings — but I had not written serious software in C, and the main tool assigned to me, SES/Workbench, was one I learned from scratch. When SES/Workbench could not represent something I needed, I had to write C modules and plug them in. The job was not simply to operate a tool. It was to participate in our AFIS design, learn these tools, write code, and keep adapting as the real system design evolved around me.
The FBI projected more than 50,000 transactions per day across many different types — ten-print searches, latent searches, civil background checks, urgent requests, routine ones — each with its own expected volume and response time requirement. The question was not whether the system could match fingerprints. It was whether our proposed hardware could process the real mix of FBI work within the required response times. That question was the simulation's "why." I had to model the system at a microscopic level: disk reads and writes, processor use, algorithm timing, how long a single fingerprint comparison took, where queues formed, and what happened when urgent work arrived while lower-priority work was already in motion.
As I got deeper into the problem, I found that the obvious way of thinking about the workflow was wrong. A large transaction handled as one indivisible block could trap everything behind it, and the FBI workload mixed urgent and non-urgent requests with very different response time requirements. The scheduling approaches that seemed reasonable at the transaction level kept failing response time requirements. So I changed the unit of work. Instead of treating a transaction as one thing, I broke each into smaller pieces that could be scheduled more intelligently — urgent requests inserted at the front, lower-priority work moving without blocking the system.
Of course, it is far easier to test different architectural approaches in a model than to code and test each new idea in live software. When the work-unit approach finally proved itself in the simulation, this design flowed back into our actual software architecture. The simulation was not decorative analysis sitting beside the real program. It yielded the concepts that became the actual design.
About halfway through the project, I had to make a decision that made people nervous. The simulation had grown too messy — the structure I had started with would not carry the rest of the work cleanly, and it was becoming harder to add new ideas without losing coherence. I told the team I needed to refactor it. We were already deep in, and reworking the foundation of an eighteen-month effort was not a comfortable conversation. But continuing with the old structure meant complexity and risk would keep increasing. If you find yourself in a hole, the first step is to stop digging. Despite people's concerns, I rebuilt the simulation with a cleaner, more modular skeleton. Much of the prior work was carried over, but the foundation became sound enough to finish the job properly. That was one of those moments where you either trust your own judgment or you don't.
Beyond the engineering design work, the bid itself was the elephant in the room. AFIS was hardware intensive — a supercomputer — and the hardware footprint was the primary cost lever. If the simulation showed we needed more hardware, the bid price went up, and a higher price risked losing. The work-unit architecture turned out to matter here as well. By allowing the system to meet response time requirements efficiently, it kept the hardware footprint smaller and cheaper than it would otherwise be.
After eighteen months, it was time for validation. The FBI came in with real test data — not the internal data we had been using — and ran their tests. Our design worked. The simulation matched real performance closely. After that long living inside the model, seeing it hold up against reality was deeply satisfying. Our customer had proof that our much larger national solution was right-sized. We submitted the proposal, and eventually the rumblings became something concrete: we had won.
The FBI AFIS win changed Lockheed Martin's position in biometrics and helped create the national asset that later made other programs possible. Electronic fingerprinting devices were coming. State systems were evolving. Civil background checks were expanding. Companies would later build fingerprinting services around those flows. TSA programs would depend on background checks at national scale. The world that followed needed digital capture, digital routing, and national search capability. AFIS was one of the foundation stones.
This was a large team effort, and many people did excellent work — the algorithms, the software and hardware teams, the capture strategy were all excellent. Our team was awarded Lockheed Martin's NOVA Award, the company's highest employee recognition. Our names were published in a full-page spread in USA Today. I was and am proud: without the simulation work and the architectural approach that was born from it, our team would have had no choice but to propose a larger, more expensive, less competitive hardware solution.
For me personally it was a turning point. I was still an engineer then, deeply entrenched in design teamwork. But AFIS was my last pure engineering contributor assignment. By the time we won I had started to see something clearly: at a company like Lockheed Martin, the high-performing technical work was the product being sold. The engineers came in, briefed their slides, answered questions, and went back to work. I wanted to be in the rooms where the larger conversations happened. When an opportunity opened to support international business development, offering AFIS technology to foreign governments, I took it. From that point on, my career moved toward capture, program leadership, and eventually executive operations. The AFIS capture began as an engineering assignment and ended with my pivot to becoming more than an engineer.