Applications: XML, Web services pave the way

Computer applications express agencies' missions as code. Missions stem from a blend of policy and the management of implementing policy. Policy makers these days are demanding agencies cut IT costs by sharing applications and data, avoiding redundancy. They want citizens to have one-stop shopping for government services.For program and technology managers who must pay for and build applications'or pay to have them built'it all means radical change is coming. Change that will redefine the way you think of traditional databases and enterprise applications.The transition is toward decentralized development and fragmentation of the applications, towards the obsolescence of centralized runtime environments.Application development is still in flux. But what is emerging is a picture of apps broken apart as developers migrate to building series of remote calls and services, of applications that interact with multiple data resources throughout the government. Such services may live anywhere from your server to some place far outside your network.For the short term, this technology path leads to use of Extensible Markup Language for information sharing. One example is the Navy's use of XML as it designs its new Navy-Marine Corps Intranet portal.Longer term, the trend is toward ever broader use of Web services.Experienced code jockeys will tell you the Web services idea is nothing new. The main concept, a remote-procedure call within an application, has been around for nearly 20 years. There are also more efficient ways to place such requests than the text-based protocols used by Web services.So what's changed? For the first time, a majority of the tech community has agreed on a unified way to call functions remotely on multiple systems. It's a vendor-neutral approach that can reach across manifold operating systems, databases and apps.But the transition is complicated enough, and the standards'beyond XML anyway'are hazy enough that the migration will not happen tomorrow or the next day. Talk to federal IT architects, you'll hear that most of them are experimenting a bit with XML and they have Web services on their radar screens. But without a standardized government tag set for marking XML data, or a government- wide approach framing an official way to implement Web services, it's risky for most to jump into the fray too soon. Avoidance of that risk will delay e-government and widespread interagency IT sharing.Developers also realize a different step is needed before taking their applications in this new direction of fragmentation. The Office of Management and Budget is pressuring agencies to complete their enterprise architectures. Program and technology managers must understand what they already have in place within their agencies'which applications are redundant, which ones need to be grown and extended. For apps that ultimately will be extended across the enterprise and to external partners, Web services will be the likely answer.'At the Bureau of Engraving and Printing we had success using an XML repository for enterprise architecture,' said Susan Warshaw, who recently moved from the bureau to become the IT enterprise architect for the Department of Health and Human Services. She said they used Metis, an enterprise architecture modeling tool, from Computas Inc. of Sammamish, Wash.Warshaw said one of the benefits of modeling the enterprise architecture is to know the extent of your enterprise and to establish communication with the application stakeholders as future plans are made. 'I used it as a way of gaining knowledge of my apps and data.'Ira Grossman, IT architect at the National Oceanic and Atmospheric Administration, said his organization is taking the same approach, outlining the business model of the enterprise first, and making decisions for the applications infrastructure based on that model.'For most people, Web services are still on the horizon,' said Bill Wright, president and chief executive officer of Computas. His company is working with several agencies, including the Treasury and Commerce departments and some intelligence offices, to model their current enterprises before pressing ahead.That might delay the transition, but it should ultimately ensure that efforts are focused in the right place.For most agencies, the process goes something like this:At a basic level, Web services can be thought of as middleware that enables application-to-application connections and interactions.Web service transactions simply run over HTTP and TCP/IP networks, the same as Web pages. Beyond that, the Web service architecture has three main elements: discovery, description and transfer. Each of the three has its own standard developed around an XML foundation.As agencies move toward e-government, they'll also move toward data sharing and application extension. As they continue building new architectures and cutting costs, they'll find it logical to share services and eliminate some applications entirely.