Big software ' big decision

'|'SPECIAL TO GCNSay 'Enterprise software?' at a trade show and vendors will come rushing with their definitions of the phrase. Acronyms will fill the air: ERP, CRM, SFA.But then ask for software that meets the needs of government agencies and the crowd will quickly thin. Only the largest enterprise software companies and a few dedicated smaller companies have built specialized systems for the government market. Others have only modified their business products to meet the distinct financial and organizational needs of government.At first glance, some types of enterprise software wouldn't apply to the government market'at least, not unless you redefine the terms at hand.The most obvious is sales force automation (SFA). Agencies don't have sales forces. But many do have large field staffs responsible for collecting data. The Census and Land Management bureaus, to name two, have data-intensive activities that match up with SFA. But not all agencies require extensive tie-ins to supply chain management systems and other businesslike back ends, and they might also require functions that don't exist in the commercial sector.The same is true of enterprise resource planning (ERP), customer'or citizen'relationship management (CRM), purchasing and financial software packages. Unless they have government-specific versions, what's built for business doesn't always map cleanly to government requirements.Even government versions might not work across the board because of the variations from one agency to another in operating requirements. You might have to do extensive work to adapt the packaged software to meet customers' requirements.As a result, enterprise software installation often becomes a vehicle for consulting services and other expenses that aren't usually associated with the term off-the-shelf.The late 1990s were the golden age of enterprise software'at least in sales. Companies and government agencies seeking to purge potential year 2000 problems from their human resources, purchasing and financial software turned to companies such as J.D. Edwards & Co., Oracle Corp., PeopleSoft Inc. and SAP America Inc. to make the problems go away. Using commercial products also helped prevent them from saddling their overworked programmers with creating custom-built systems.To some degree, they succeeded. But it is a process fraught with peril. Just ask folks in Virginia familiar with the Commonwealth's Integrated Human Resources Information System project. Two years ago, the failure of its ERP software led to this headline in the Richmond Times-Dispatch: 'Taxpayers to Pay for $9.4M Goof.'That software meltdown, like many enterprise software project failures before and since, had its roots in the very nature of the product. If you don't pick the enterprise software that suits the way your organization is structured, you have to change the software'or change your organization.And when your organization's structure is dictated by legislation, changing it isn't an option. What at first appears to be a small ding in the software architecture can transform into a giant sucking sound of increasing magnitude as agency budgets are siphoned off to bridge the gaps with custom-built code, systems integration consulting and software sleight-of-hand.Those hazards have tipped the build-or-buy scales for many managers further toward building their own. Eventually, Virginia deployed a system it built on top of WebLogic application server from BEA Systems Inc. of San Jose, Calif., and tools from SAS Institute Inc. of Cary, N.C., for a fraction of the cost of the original, failed packaged software.Customizing software will ensure that it meets your organization's needs, but you can meet those needs more cost-effectively with packaged software if it suits your organization. And if your agency doesn't have the organic software development resources required for a project of that scope, you're back to Square 1 anyway.Fortunately, enterprise software has become more flexible and easier to customize over the past few years. The advent of Web and other application integration tools have eased the burden of making the square peg of business software fit the round hole of government needs.Still, the key to a long-term government enterprise software project is to look beyond the feature set and make sure there's a flexible and extendible architecture behind it.There are even more incentives for picking enterprise software that supports emerging Internet standards beyond having the ability to extend the software internally. For example, at the General Services Administration, electronic procurement exchanges often can be integrated directly into enterprise software systems through software hooks, or through software such as Microsoft BizTalk or other electronic-commerce application servers.But the real goal of a flexible enterprise software architecture is to conquer something basic: fear of the unknown.As the demand for electronic government services expands, the demand on the infrastructure of agency applications will increase in ways unforeseen by developers. And with the costs of these systems running into the tens of millions of dollars per installation, government information technology professionals won't be able to justify ripping out and replacing them on a regular basis.For that reason, having an infrastructure that can be easily extended and adapted is perhaps the most important feature any enterprise software system can offer. Support today for protocols such as the Simple Object Access Protocol and other Extensible Markup Language interfaces means that these packages will meet the distributed computing demands of the increasingly complex world of e-government. XXXSPLITXXX-