Whether technology is used to manage welfare caseloads for a state or finances for a midsize city government, the result is often the same: an intricate computer system built from the ground up as a single unit. Invariably, the software is complex, custom-designed and hard to modify, even if the change involves just one business function. The result, say government officials, are systems that cost too much to build and are at a high risk of failing. It doesn't have to be that way.
For decades, engineers have used the "Black Box" approach for developing everything from cars and PCs to stereos. Rather than try and build an entire project yourself, engineers suggest breaking it down into discrete pieces, which are built separately, but based on a common architecture. Each piece is both independent of and integral to the entire system. "The premise of Black Box," said David Gray, chief information officer for California's Secretary of State, "is that it's very inefficient for one organization to build everything they need, whether it's a product or a computer system."
Gray, an engineer prior to working in the public sector, pointed out that when Sony builds a stereo, the company doesn't try to design and build the tuner, speakers, CD player and amplifier itself. "They create a common architecture for the entire system, specialize in one area and then purchase component parts from firms that specialize in CD players, tuners and so on," he explained. "Sony then integrates all those together to make a product."
Gray, along with a small but growing number of IT executives, believes that same concept can be used with large-scale computer system development in the public sector. "The way it applies to information technology," outlined Gray, "is that the IT organization in an agency becomes the integrator, not the developer, of products necessary for a solution."
The difficulty with Black Box is designing an underlying architecture that's both scalable and open, covering everything from the network and operating
system to database management and memory specifications. Once the architecture is done, separate groups can be assigned to build components without necessarily knowing what is inside the other components. The advantage of this process is that, if an agency's business model changes over time, the IT department can retire and replace the system component affected by the change without redoing the entire system. "Black Box works because it reduces risk and cost by breaking large projects into little pieces," said Gray.
Black Box in Practice
The Secretary of State's Office used the Black Box approach for two key applications: one involving the certification and management of notary publics, the other for a document warehouse. In both cases, the agency created the architecture and then had a combination of in-house and private-sector developers build modules that interface with each other but are also stand-alone applications.
With more than 125,000 notaries in the state, the job of managing this licensed position requires significant automation. Unfortunately, the Secretary of State's Office only had a 30-year-old mainframe -- which costs $25,000 per month to maintain -- with limited functionality to do the job. According to Gray, the office decided to increase the efficiency of its Notary Public Automation System by automating a number of notary business functions, including commissions and investigations.
To design any new system using the Black Box approach, Gray begins by holding numerous meetings with his staff from the office's Information Technology Division to determine whether a system is a suitable candidate for Black Box development. Then the proposed system is evaluated by IT staff for ways it can be broken down into stand-alone components.
Ultimately, design of the notary system was divided along functional areas: data, commissions, investigations and seal
Actual design and development used two methodologies. Joint application