May 6, 2008 By Merrill Douglas
Time and time again, we hear that technology silos are bad news. The notion of 15 public agencies each building an infrastructure to run its own applications conjures images of wasted space, money, manpower and time.
For many, the solution for this kind of redundancy is to share. "Shared services" has emerged as a popular buzzword. But what people mean by that term - exactly what's being shared and how - depends on whom you ask.
It may mean a service that a central group provides to the whole enterprise; managing human resources or accounts payable for an entire state government is one example. "In the context of a lot of the public sector, it's oftentimes things like network communications, IT infrastructure and data centers - so you see all those data center consolidation exercises," said Paul Wheaton, senior vice president and chief strategy officer of Five9 Technologies, a Chicago-based IT management consulting firm that has helped several state governments with consolidations.
But to Gartner analysts, a shared service is slightly different: an organization governed in part by the customers it serves, rather than a consolidated center created by executive decree.
"True shared services involve three elements," said John Kost, managing vice president at Gartner and a former CIO of Michigan during the mid-1990s. "No. 1, that the customers are involved in governance. No. 2, that the organization that's running it is billing back all its services to its customers. And No. 3, that there are mutually agreed-upon service levels between the customers and the organization running the operation."
One of the more interesting forms of shared IT service is creating software services that perform multiple functions for several organizations - not simply moving servers, storage and technicians into a central facility. The best way to accomplish this kind of sharing, some experts say, is to use service-oriented architecture (SOA).
SOA is an approach to software development that relies on reusable components and open standards. The idea is to create a collection of services in the form of discrete software modules that can be combined in different ways to create different applications. They're a bit like Lego blocks, with standardized connectors that bind each piece to every other piece. You might use the same plastic blocks to build a model of a castle or a dinosaur. And you might use some of the same software blocks to build, for example, an online application that business owners use to apply for permits, or a different application that caseworkers use to enroll clients for benefits.
Discussing the role of SOA in creating shared services can be confusing because people also use the term "shared services" to denote the software modules themselves. Under the SOA approach, the software blocks are called "services," and numerous applications may use the same block in different contexts.
"When you talk about it in really tight IT terms, shared services is a component-based architecture, where you decompose a business service into elemental parts and then provide those common components for other people to adopt," Wheaton said.
Still, if you stick to the idea that "shared service," means an entity that serves multiple customers with software to meet their business needs, there are good arguments for using the SOA model to achieve that mission.
One Engine, Many Business Lines
In an insurance company, the life insurance and annuity business unit might need to produce proposals; the property and casualty business may need to produce explanations of benefits; the health insurance business might need to produce identification cards; and they all need to produce statements, each with its own set of details. "If they have a single SOA implementation of our engine, they can reuse that to enable multiple lines of business," said Christian Cole, product manager for Exstream Software in Lexington, Ky. Exstream uses SOA in its enterprise document automation solutions.
Typically an IT department builds a software platform that business units can use to generate documents tailored to their own needs, Cole said. Based on that software, the IT department develops a "center of excellence" specializing in that service. "Now you can eliminate silos," Cole said. The IT department has no longer to look after a different document composition tool for each business unit.
Within the federal government, the Office of Management and Budget (OMB) has spurred development of centers of excellence that provide IT services to multiple customers. Among them are four financial centers of excellence operated by the Bureau of Public Debt, General Services Administration, Department of the Interior and the Department of Transportation.
At the Administrative Resource Center (ARC) in Parkersburg, W.Va., the Bureau of Public Debt runs a single instance of the Oracle Federal Financials System. About 30 other agencies use that system to conduct their own financial transactions, including agencies within and outside of the Treasury Department such as the Armed Forces Retirement Home, Merit Systems Protection Board and the Office of D.C. Pensions.
"Why would you stand up all that infrastructure for these little organizations when they can simply log into somebody else's instance and partition the data, so it's secure from other people having access to it except for the people who need to be in that system?" asked Wayne Bobby, Oracle's vice president of finance and administration, public sector. Agencies pay ARC based on their transaction volume, he said.
SOA is key to this arrangement because it dictates the use of open systems standards, Bobby said. An agency that uses the ARC system for financial transactions must move data between that system and its legacy applications for functions such as procurement, human resources and property management. Any application based on open systems standards can exchange data with an application based on SOA, such as Oracle Financials, he said.
"Make sure you follow a service-oriented architecture so you're in an environment where all those systems can still talk to each other," Bobby said. "And then when you upgrade one of those systems, you don't find yourself spending six months and $1 million writing interfaces to make sure those things still talk to each other."
SOA to Control Risk
Besides saving time and money, SOA helps minimize risk in software development projects, said Peter Bostrom, federal chief technology officer at BEA Systems in San Jose, Calif. "If I know that 30 percent of a given application is based on pieces and parts that I have built on top of five times in a row successfully, I'm pretty confident that I can build the other 70 percent within a certain amount of time given a certain number of resources," he said. "I start to know with much more precision what I'm building and how much it's costing me."
SOA has made a greater impact in the private sector than in government, partly because in government there's less incentive to share. "If I'm a department, and I'm funding a development for a specific application or set of IT functions, what interest do I have in enabling some other department to do its job better?" Bostrom said. Nor do systems integrators that develop software for government agencies see much benefit in allowing other agencies to reuse components of that software, he said. "They make very conscious business decisions around wrapping their intellectual property up very tightly, so that it cannot be used again by other agencies."
Turf concerns also stymie the adoption of SOA and shared services. Agencies will agree to this kind of sharing only if top executives champion the idea. "You need an investment of money and a certain amount of technical expertise, but the main issue is you need an investment of political capital," said Kost. Few government leaders get behind SOA because the topic doesn't make it onto their radar screens, he said. "To a politician, it's boring as hell, especially when you compare it to things like public safety and education."
But for governments that overcome these kinds of obstacles, shared services based on SOA hold opportunities to offer better service to constituents. Government systems linked by shared software modules can simplify the process for citizens who need to update their records with several state agencies after a marriage, for example. "If you want to change your name and address, it would be nice to do it once and know that every government agency has made that change for you," said Kost.
This type of sharing also might cross jurisdictional lines, Kost said. "One could easily envision a time when SOA gets to the point where, when you change your name and address with that state agency, you're able to change it with the local governments that are impacted by it and perhaps even the federal agencies. It has profound implications in terms of how you're treated as a customer and how you are viewed as a customer by multiple governments."
You may use or reference this story with attribution and a link to