 |
|
||||
|
|||||
|
|||||
|
|
|||||
|
|
|
|
||||||||||||||
|
||||||||||||||||
|
|
|
|
|
|
|
| ||||
| The state of components | |   | |
| ||||
| ||||
| Georgia CIO spearheads nationwide component initiative Claude J. Bauer (claudebauer@claudebauer.com) Larry Singer, Chief Information Officer (CIO) for the state of Georgia and executive director of the Georgia Technology Authority (GTA), chairs the Component Reuse Subcommittee for the National Association of State Information Resource Executives (NASIRE). Mr. Singer's mission for NASIRE is to promote component-based architectures for government software, as well as to establish an online component brokerage where state and local governments can share resources and reduce development costs. NASIRE's work in the area of software components and reuse is being funded and encouraged in part by the Office of Justice Programs (OJP), U.S. Department of Justice. What initially sparked your interest in component-based architectures and reuse? My interest started with IBM's AD/Cycle initiative years ago, which included the concept of model-based development that allowed developers to abstract requirements from code to a business level. I felt that if you could take those models and find common business requirements, based on common models, you should be able to reuse those model elements. The problem with AD/Cycle and the computer-aided software engineering (CASE) tools that followed, however, was that people built tightly integrated hierarchical models that reflected their experience in writing code. While the potential for components always existed, programmers did not build the models in such a way that would allow for component development. What was the impact of object-oriented programming around the late 1980s and early 1990s? That stimulated a lot of interest in reuse, but the objects were at such a fine level of granularity that you got a lot of reusability in things like print drivers and spell checkers, but we weren't seeing business-level reusability in most development shops. Nevertheless, I noticed companies like IBM Global Services, EDS and others, who had multiple customers in the same business, coming in with solutions that included reuse, and the whole concept of components and reuse really caught me. Were there any particular initiatives in government that spurred your interest in components and reuse? During the 1990s, the federal government, which was paying for many health and human services around the country, began to notice that even though the states had some unique requirements, they had as much as 75 to 85 percent commonality in how they performed child welfare processing. The federal government began requiring that states reuse software from state to state. With child support, for example, they only funded a handful of states for new development, and required all the other states to transfer to the same system. The effort was a huge failure because the small percent of functionality that was different from system to system wasn't isolated in one module, it was spread throughout the system. However, I realized that a component-based development model would have allowed them to modularize the functionality and begin isolating those functions that were unique to specific programs. Do you see a place for open source software in government, as well as components? The benefits of open source are similar, in some ways, to those of components –– allowing for reuse and tweaking, and saving organizations the trouble of reinventing the wheel. I do. The same benefits accrue and there is room for any technology approach that promotes reuse. There simply are not enough states to support a marketplace for commercial-off-the-shelf software (COTS) in our verticals, such as human services, justice, etc. Open source and components can enable the creation of that market. How does the move towards componentization affect applications at the state and local government level? There's a huge opportunity. For example, it's hard to think of a department in a state government that doesn't issue some kind of license or permit. While licensing a brain surgeon and licensing a truck driver require very different types of data, the process is very similar: collecting certain information, processing that information against certain rules, checking the validity of the information and issuing the license. There's a tremendous amount of potential for reuse of licensing components within state governments. There are numerous other applications where the same principles apply. How would you characterize the market for components for state and local government programs? Across the 50 states in this country, we do roughly the same business in a whole variety of areas, but the marketplace, with only 50 customers, is too small for packaged applications to be successful. However, it's a pretty large market for components. The cost of entry into the marketplace has traditionally been prohibitive to small application vendors, because you not only have to be able to build the application, you have to be able to market it in 50 state capitals. But if we can provide a component marketplace online, we can start bringing in small companies who, instead of selling multiple $30 million child welfare systems, could get away with selling $300 intake modules to 15 different programs in 50 different states. What is the opportunity for small, independent developers to break into this potentially lucrative government market? After selling a component to each of the 50 states, what's the likelihood of a developer being able to break into other government markets or even foreign countries? Would there be any restrictions on selling U.S. software components to governments overseas? If an independent developer is willing to build components to specifications instead of under a consulting contract they can retain ownership rights to the software program product they create. The marketplace for those components then could certainly expand beyond the states to other governmental units, and even to non-governments who have equivalent processing requirements. The whole benefit to components is that they can be easily modified, so the developer could customize them to other industries or jurisdictions, using their state government marketplace as a sort of "anchor tenant" or first customer. How would the online component marketplace you describe actually work? The best way would be using an Internet model, where the states can download the components, try them, and if they like them, pay for them with a credit card. This means virtually no marketing costs for the seller. We are working with NASIRE and the National Governor's Association (NGA) to create just such a clearinghouse. The state of Georgia will host it, and vendors with components to sell will be able to post their wares. In addition, states can put up components they've developed internally that are in the public domain for others to use and share. What's the status of the project? We have an RFP that should hit the street soon for creating the component repository. We also have a series of pilot projects going between states. The results of those pilots and the RFP will be shown in Austin, Texas at NASIRE's spring conference. A number of states are working towards demonstrating the efficacy of this approach now. What's the federal government's stake in this? It fits into some of the architecture initiatives that have been underway throughout the federal government. For example, the Office of Justice Programs (OJP), U.S. Department of Justice, has provided funding support for the NASIRE initiative because they believe the opportunity for reuse promotes the creation of integrated justice systems nationwide. Locally, our governor is very committed to protecting the welfare of underprivileged children, so we're using components here to link different departments –– such as community health, labor, and human resources –– to provide integrated human services. If you're reusing the same component in different applications, it's easier to share data. How will a component marketplace for state and local governments affect development costs? It should reduce the cost of application development, because you don't have to do custom development for each job. The federal government has learned the value of commercial-off-the-shelf (COTS) software, and we think component-off-the-shelf software is now the direction to go. What level of component are you talking about? Today, components can be as small as a single field that performs a specific calculation, all the way up to entire applications. It's true that most of the components available now are quite granular. What we're looking for is a higher level of component, at least equivalent to an Enterprise Java Beans (EJB) component, all the way up to a template component. But for components to have real use in the government market, they'll have to be based around program-level functionality. They're going to have to be high enough so people in government can recognize how they fit with their business processes. Who else is involved in the component initiative besides Georgia? We've had a lot of states jump on board to help demonstrate that this can work. Pennsylvania is already pretty far along in the process and reusing mostly COM-based components for virtually all their Internet applications. Arkansas and Mississippi have been moving very aggressively in this direction, as well. Missouri for some time has been doing model-based development, and are now componentizing their models. Michigan has some components, too. How will this component model you're proposing for state and local governments affect the price of software for your market, and how will it be received by vendors? That's difficult to predict. Many software programs today are built under contract to a single state, and most vendors price in their profit from that first customer. With software, if you make your whole profit margin on the first sale, everywhere else you sell it after that is a 100 percent margin. We think a competitive marketplace will drive down the cost of software. For example, if there were components developed by IBM Global Services, IBM is going to have a strong marketing position when the state that bought the component, or set of components, needs integration services. The original vendor will have a familiarity with the content and architecture of those components. We think that vendors will want to market the components and keep the prices down so they can pull services behind them. Do you think these components will require much tailoring to get them to work in the different states? Not so much tailoring within the components, but quite a bit of architecting to snap them together. Are the tools out there to support that? The problem up until very recently has been that the tools weren't available to take advantage of component-based development (CBD), and the operating systems and databases prevalent in the industry really promoted old-style development. The new operating environments practically require component-based application delivery. Software architects in the last two or three years, in order to support Internet-based applications, have begun architecting on a component basis. If we can drive the business users to begin isolating their business functions, we really have an opportunity to take advantage of CBD. Numerous tools are emerging for CBD, and we're beginning to see a marketplace for software components. Everything's coming together, and all the promise that's been out there since the late 1980s is finally becoming a reality today.
| | ||||||||||||||
 |
| About IBM | Privacy | Terms of use | Contact |
