A Virtual Standstill on Border Security
On Feb. 22, the Department of Homeland Security announced it was accepting Project 28, which was the prototype stage of the "virtual border fence" that's also known as SBInet. That stands for the "Secure Border Initiative", and the idea was to combine cutting-edge perimeter security, intrusion detection and surveillance technologies into the kind of system that would work as a "force multiplier" for Customs and Border Patrol (CBP).
We heralded this project when it was time for initial bids. I recall writing in my Friday column that this was the kind of project that could raise the bar on the levels of integration that happen in our industry. So, based on what Chertoff said roughly one week ago, it seemed that Project 28 was going somewhat "OK". After all, things couldn't be too bad, since on Feb. 22, the DHS accepted Project 28. Admittedly, the project had been delayed (original completion date was supposed to be the summer of 2007), but it's easy to forgive a six-month schedule miss considering the potential value of such a project.
However, at the core of every good integration is good software, and that appears to be the weakness. A GAO report on the SBI program from Wednesday, Feb. 27, 2008, identified software as a main culprit behind Boeing's delays.
The report stated: "Specifically, SBI program office officials said that the software that Boeing selected for the COP was intended to be used as a law enforcement dispatch system and was not designed to process and distribute the type of information being collected by the cameras, radars, and sensors."
Mindful of that integration problem (as well as challenges with video and radar signals), the DHS is now pushing back the timeline to 2011 (the original schedule had slated project completion for 2008, which is obviously unrealistic).
I was on the phone yesterday with David Fishering, a research analyst with Frost & Sullivan who has been tracking this project. He says he's wonders if the "delay" of this SBInet timeline means the project might die altogether.
"[The revised timeline] is an acknowledgement that you can either continue going down a path of wasting money, or you can put a foot down and say 'This isn't working, and it's time to push it back,'" said Fishering, who said the project faced unrealistic goals from the start.
Fishering also questioned the value of what had been accomplished in Project 28, since "integration" was the core goal of this SBInet prototype model.
"With SBI, the goal was to increase stakeholders' (such as CBP) domain awareness," said Fishering. "Even if we had a bunch of standalone sensors working, if they are not integrated, then it's not really being that effective."
So where to go from here? For one, there seems to be word of a new, specialized integration software on order so that DHS could cut out the outdated law enforcement dispatch software that Boeing's team attempted to use as a glue to integrate all of the complex signals and data.
Fishering said that the initial emphasis in the SBI program was "to show that the DHS is doing something." Rushing an integrator/systems contractor into a project where they have to use bad software was the result of that. Now, in the GAO report from this week, SBI managers are saying they are ready to do it "right, not fast."
I still have hope for this security integration project, but the focus lately on border control seems to be more about creating physical fencing standards for our southern border and buying steel in bulk to accomplish the construction of a southern fence. Perhaps the sizzle of a virtual border fence has been lost. After all, you only get one chance to "do it right the first time," and that didn't happen. It's not about where to place the blame (culpability seems to fall to DHS, CBP, Boeing and even the dispatch software), but about our overall approach to complex integration projects.