Found in: Case Studies
Oct 2, 2010
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.
"We are always going to have technical diversity," he said, "but that is not where I want my guys spending most of their resources. If you look at our staffing levels over the years since we consolidated, we have moved many of our staffing resources out of the traditional infrastructure side of IT and into development. Development now is the largest of all our IT groups, and the one that has grown the most over the eight years because that's ultimately where the action is."
To get to this point, the state first built the technology foundations that would allow all staff to spend less time managing infrastructure and get down to what really mattered -- aligning data, people and process.
"That means obviously creating information systems that get to the data when you need to get to it, and in a fashion you need to get it in," said Doll.
The payoff already has been significant. It paved the way for all state agencies to comply with the Health Insurance Portability and Accountability Act (HIPAA) in a minimal amount of time.
"It is not just the fact we met the deadline for HIPAA, but also that we are not only talking about eight agencies," he said. "We have a lot of providers with whom we are exchanging data as well. People have noted that the amount of money it cost us to get to that solution was a lot less than expected."
Achieving the degree of integration that now exists in South Dakota was as much a people process as it was a technological one. Initially Doll formed a committee within the Bureau of Information and Telecommunications to manage all process dynamics. The committee expanded to include the various agencies' key technical contact people, who started to educate other agency personnel about the benefits of an integrated IT system. Eventually all analysts from the agencies were brought into the loop. The training organized technical people into individual programs so they could understand the new capabilities being introduced.
"There has been a long, slow process, and it will continue for several years before it becomes second nature for people to think enterprise first," added Doll.
Colorado's Enterprise Best Practices
Colorado identified four e-government strategies that form its comprehensive enterprise IT management framework: enterprise architecture, policy structure, IT risk management and portfolio management. Enterprise architecture itself is viewed as three distinct layers -- business, information and technical -- and the state is drafting a reference model for each one.
"When we took an enterprise view across all departments in the state, we found components -- such as enterprise architecture and portfolio management -- that in the private sector have driven not only business change, but management of IT assets," said Jeff Sherrard, deputy secretary of technology and chief architect for Colorado's Office of Innovation and Technology. "However, in Colorado state government, there were no clear directional targets. There was a lot of process, a lot to do with how you turn the engine of state government as far as review and approval processes. But there weren't good set targets that described where we want to be so many years into the future."
To address this issue, Sherrard organized an Architecture Advisory Board of traveling architect consultants from Sun, Microsoft, Oracle, Cisco and IBM. He asked board members to identify the key industry standards and technologies they automatically assume are in place when they act as consultants in any commercial setting.
"I did not want to get started on a 'boil-the-ocean' approach," said Sherrard. "Our focus is to bring the state government up to 1990s-level technology and efficiencies. We are not even trying to get to 2000 or 2004 because there is a whole generation of commercial efficiencies that happened in industry in the '90s that states aren't yet operating with. Or if they are, it is in pockets."
In Sherrard's view, identifying common industry practice would form a great target for where states should be. These are all proven technologies that have been scaled in large industries. They have long life, and in many cases, the successful ones already have years of additional standards built on them.
The advisory board came up with 38 standards -- including such basic things as every computer should have a TCP/IP card and be network-addressable via IP.
"These are things you can't assume in state government until they are stated," said Sherrard.
They then assembled an architectural score card based on the 38 standards. Using this, department CIOs scored their departments to see if they completely complied with the standards. This provided a new basis for evaluating the state of technology in any department.
Every new project that included IT was also scored against the architectural scorecard. It became a tool all state CIOs, technologists and nontechnical people could use to evaluate programs.
"Even our Legislature conceded that a program that scored 80 percent compliance was better than a program that scored 70 percent compliance," said Sherrard. "They didn't have to argue whether Microsoft SQL server was better than Oracle's database or whatever -- stuff they couldn't evaluate anyway."
The state now requires RFP respondents to detail their compliance with these standards. "All around, it has proved to be a good decision-making tool," Sherrard said. "It allows technical and nontechnical people to assess their projects against this baseline, and it allows us to do year-over-year comparisons that show how we are improving as a state."
It also helps encourage some departments to seek help in progressing faster.
"You always have departments that are underfunded and an IT group that doesn't think it actually needs to change because it is in a very stable environment," said Sherrard. "Those are often the hardest ones to get movement in until you can actually show them, 'You're scoring 40 percent compliance. Here's your peer who is scoring 80. Give them a call. Have lunch with them. See what they are doing.' That kind of thing works out very well."
Additionally the standards provided a basis for launching the statewide portal initiative. "If we have every department moving toward these different information accessibility standards, and we have the ability to execute on those areas that actually have enterprise applicability, then we can leverage that to invest the dollars once in the tools needed to meet those standards," Sherrard said.
Indiana's Toolkit Approach
In 2001, because of increasing demand for services and diminishing resources to deliver them, then-Indiana Gov. Frank O'Bannon established a technology group to examine immediate business needs across multiple organizations, identify technology solutions and implement them. As part of this effort, the group established an initiative to research enterprise architecture approaches. The resulting framework consisted of governance, business and technology architectures.
Subsequently under CIO Laura Larimer, the state adopted the National Association of State Chief Information Officers' (NASCIO) toolkit for technology architecture and the federal Office of Management and Budget's Business Reference Model, and established a Technology Leadership Team to shepherd and govern the initiative.
"We used the NASCIO toolkit and the federal government's business architecture toolkit to develop our own approach," explained Chris Pichereau, deputy director of product development and support in the state Division of Information Technology.
The state tackled the problem from three different levels. First, governance was put in place to oversee the architecture. Using people within other state agencies -- MIS directors and business leaders -- the state formed the Technology Leadership Council (TLC), chaired by the CIO, to look at different aspects of the challenge.
"While we knew it was important to look at technology, we felt it was also very important to link the technology to the business objectives," explained Pichereau. "So we had representatives from the business side, as well as the technology side, serve on the council."
The TLC's first phase was conducting a complete inventory. On the business side, this included all the functions state government performs. They ended up with a list of 982 business functions.
"It was a massive task, but it helped us look at our organization from the perspective of streamlining these business functions," said Pichereau.
The council also documented all current technologies used by the state government along with their compliance components.
Additionally the state began looking at issues to be focused on to maximize technology at an enterprise level -- such as creating a centralized portal to combine its Internet, extranet and intranet environments. After issuing a competitive RFP, the state picked IBM's WebSphere solution to establish a centralized identity management and metadirectory service. Finally the state began looking at content management from an enterprise perspective.
In phase two of the enterprise architecture project, council members are examining different business functions throughout the state to find common elements that might be combined technologically.
"We are after either common solutions that could be deployed, or if a common solution wouldn't be practical, where best practices could be implemented," explained Bill Pierce, Indiana's acting chief architect. "The one that keeps popping up that we are going to address relatively quickly is grants management. A lot of state agencies in Colorado do some form of grants management. Similar to what they did on the federal site, we will probably end up putting up a site for state grants and point to all the different grants people can apply for."
Many Roads Ahead
As South Dakota, Indiana and Colorado clearly show, successful approaches to developing an enterprise architecture vary from state to state. A viable enterprise architecture strategy obviously needs to spring from the resources and circumstances of each state, but there is also plenty of room to be innovative.
Perhaps the most important lesson, however, is that no matter the approach, it is never just about technology. It is just as much about people who have their own perspectives and who are often comfortable in their silos. The silo walls don't come down easily until all concerned can see an enterprise architecture's benefits
Source: Found in: Case Studies, Oct 2004, Enterprise Architecture: The Drive for Integration,