« July 09, 2002 | Main | July 11, 2002 »
July 10, 2002
GIS to the Rescue
An article in Fortune discusses IT and Homeland Security:
It's a very bad day in Galveston, Texas, home to one of the world's densest concentrations of petrochemical plants. An airborne plume of hydrofluoric acid--stuff so nasty it can dissolve glass--is spreading from a railroad tank car blown up in a terrorist attack. Public-safety officials are in a scramble to understand the scope of the disaster and how to protect the population. Fortunately they've got a geographic information system, or GIS, to get a handle on the crisis and respond to it--fast.
If you're not familiar with GIS software, its used to keep track of almost anything you can put GPS coordinates on. Needless to say, GIS plays a very important role in state and other government IT systems. In state government, every data record we have either has a social security number or GPS coordinates. (Some have both).
Utah's Automatic Geographic Reference Center is the group that coordinates GIS systems for the state of Utah. They also created our state portal maps service. in the same way that the scenario in Fortune has GIS playing an important role in a poisonous gas leak, our AGRC folks have done numerous studies on inundation plains for dam breaks and other natural and man made disasters. GIS is a great tool to have in homeland security. Utah's lucky to have a dedicated team of people at the state level and county governments who also understand the importance and cooperate closely with us to create a GIS system that is complete and accurate.
04:48 PM | Recommend This | Print This
SICP Online
Kenneth Hunt informs me that SICP is available online. Thanks!
03:13 PM | Recommend This | Print This
Federal Funding Process
An Information Week article says:
The manner in which the federal government funds some state IT projects is at odds with the way states are implementing common IT architectures back home, state CIOs complained to a congressional panel on Tuesday. Specifically, the IT systems bolster state-run social-service programs, including food stamps, child welfare, child-support enforcement, and Medicaid.
We continually fight this problem. The ADP process has good intentions: ensure money is spent on what it was appropriated for. On the other hand, as Aldona says:
"It's clear that the [ADP] process strongly discourages using federal program funds to create common IT infrastructure," Kentucky CIO Aldona Valicenti said in testimony prepared for the House Subcommittee on Technology and Procurement Policy. "Although it frequently costs less to the original program than creating a separate, standalone IT system, it's precisely because it would benefit other programs that it's often termed unallowable."
We fight this by being willing to engage the Federal program officers early and gain permission for what we're doing. Governor Leavitt sees it as a "federalism" issue and we have a fairly good track record of engaging the Feds on it. Still it takes time and effort, so you only do it when it really matters.
Another way we combat it is through architecture. A good example is our eREP project. We administer billions of dollars of federal benefits every year. The IT system that manages this is being replaced (old crufty mainframe code). The system is essentially a CRM system with lots of specialized rules to determine eligibility and calculate specific benefits. Every federal welfare program is funded separately, so theoretically, we should build 6 or 7 eligibility systems. Instead, a core CRM system and rules engine will serve them all, with individual modules built for the individual programs. To satisfy the Feds, we have to be able to track and correctly allocate the costs and get some relief on ADP, but its workable. For a system that will ultimately cost $50 million or so, its worth it.