November 29, 2004 By Blake Harris
Developing an enterprise architecture has emerged as the next big idea in government's continuing efforts to unify disconnected information silos and deliver services more efficiently.
In essence, enterprise architecture is about integration -- integration or sharing of data, integration of processes and applications, and where appropriate, integration of business functions.
Most, if not all, state governments understand that an enterprise architecture is the sensible approach for priority evaluation and new technology deployment. But an examination of three states that placed highly in the Center for Digital Government's Digital States Survey shows that successful state strategies to develop an enterprise architecture vary greatly.
South Dakota's Push for Unity
South Dakota's Virtual Enterprise U-Government initiative has been ongoing for several years and demonstrated significant results. Taking an enterprise architecture approach helps information sharing across state government while reducing future development costs. The state also seeks to link new systems with older legacy systems to extend the useful life of past assets and investments.
U-Government, meaning unifying government, began when Otto Doll interviewed for the state CIO job in 1996 (a job he has held since). Then-Gov. William Janklow complained that he asked five agencies a question and received seven different answers.
Each agency or department said its answer was right because its data was better. In other words, there was virtually no data integration across agencies -- or even across many programs.
"I kept that thought, and it took me four years to finally say, 'OK boss, this is how we solve it,'" Doll said, noting that was the U-Government initiative's birth. "After Y2K, we got to thinking about how we could unify three important components of state government -- people, data, process. We decided one of the first major pieces that had to be implemented in our technology stack was application integration. Ultimately we bought into the SeeBeyond product suite."
SeeBeyond developed its unified platform around a standards-based architecture for system, application and data integration. Prior to adopting the solution, the state built custom "point-to-point" interfaces. As demands for electronic information exchange increased, however, this solution became unworkable.
Doll cites data on drivers' licenses and deadbeat parents as an example of the most widely used information across agencies. State law now requires, for instance, checking deadbeat parent information before issuing such things as a fishing licenses.
"In the old days, we would build an interface from any application to the needed data -- say drivers' licenses -- whether it stayed within an agency and just crossed program areas, or if it needed to cross agencies," Doll explained. "But heaven help you if you ever change anything relative to that driver's license. You change the data structure, and lo and behold, you have to go out and change 15 interfaces."
Using a platform like SeeBeyond was relatively easy because the state's IT operations were already centralized under the CIO. "That level of centralization naturally generates things like enterprise architectures and the ability to take a single architecture, integrating it across the enterprise via one IT organization to maximize technology benefits," Doll said.
"Think of it from the standpoint of the developer or analyst. For the first time, developers who normally were very much aligned to an agency, or even potentially a program within an agency, now more readily see any data and application within the enterprise," Doll added. "It is easier for them to think about any solution from an enterprise level, versus a more stovepiped view."
Doll admits that even as centralized and small as South Dakota is, the state will never be able to restrict every agency to one database manager, one computing platform or any one solution.
You may use or reference this story with attribution and a link to