12.2. Technology Evolution

Deployed in 1998, GFM represented a huge improvement over the paper-based logistics and transportation processes that had previously prevailed within the FSD and throughout the DoD. But migrating from paper-based to electronic processes was just the first step in bringing the DoD's transportation systems in line with Twenty-first century business practices. The next step was enabling these electronic systems to take advantage of browser-based user interfaces, cost-effective IP networks, and Web-based business process technologies that improve responsiveness, productivity, and cost-effectiveness.

The process of Web enabling existing business applications not only changed the way users interact with these applications, but also called into question the way the applications were developed and maintained. For example, until recently, the FSD's GFM system housed all its data and programs for tender management, carrier rating and ranking, as well as payment and shipment tracking, on a host computer residing in Falls Church, Virginia. As the number of applications within the GFM system grew, and as the functional requirements for each application evolved, the FSD experienced increasing complexity in managing new application development.

While the need to protect long-standing investments in legacy hardware, databases, and applications remained a key factor in its IT decisions, the FSD was quick to begin implementing the DoD's vision for the Twenty-first century. Guided by the foresight of FSD product manager, Lieutenant Colonel Hank Abercrombie, the FSD became the first DoD department to migrate its operations to the Web, complying with a 1997 directive from the Office of the Secretary of Defense, called MRM 15.

In accordance with DoD directives, the FSD adopted an IP-based network and instituted Web browsers as the standard client interface. And since 1998, all new FSD applications have been written in Java technology. The cross-platform portability of the Java language and its object-oriented structure have given the FSD greater flexibility in providing a wide range of application services to a large user base. FAST, Spot Bid, and the Small Package system are all server-side Java applications.

Working with Sun Microsystems, Inc., FSD developers have been incrementally improving the performance and availability of their Java applications by taking advantage of new technologies, such as Enterprise JavaBeans (EJB). And in 1999, the FSD made its latest stride in ensuring the openness and extensibility of its transportation systems by adopting the Java 2 Platform, Enterprise Edition (J2EE).

12.2.1. Why J2EE Technology?

The FSD's migration to the J2EE platform was the combined result of an overall drive to improve the efficiency of the FSD's business processes, enhance application scalability and performance, and reduce application development and maintenance costs. In late 1999, a Java Architecture Assessment performed by the Sun Professional Services Java Center revealed that the FSD had much to gain by

• Standardizing its development processes

• Building a well-defined component-based application architecture

• Relying on standards-based containers to provide system-level functionality

• Creating a services framework with generic components that could be reused in other FSD applications

All these findings naturally pointed to the adoption of the J2EE platform, with its inherent specifications for system-level logic and its clear separation of applications into multiple tiers. These features provide both a highly standardized application framework and the flexibility to leverage that framework to quickly create new applications that meet specific demands.

The Defense Information Systems Agency (DISA), which is responsible for setting standards for application deployment within government agencies, had reached similar conclusions. In 1996, prior to the release of the J2EE standard, the DISA released a standard called the Defense Information Infrastructure Common Operating Environment (DII COE). Among other things, the DII COE specified that all new applications developed for the DoD should be self-contained—that is, have limited code dependency on other applications. Where such dependencies exist, they must be clearly defined to reduce the complexity of new development efforts.

Around the time of the Sun assessment, the need arose within the FSD for a new application to handle overnight domestic and international shipment of small packages. Based on the recommendations of the above assessment and a successful J2EE technology proof-of-concept demonstrated by a consultant from the Sun Professional Services Java Center and FSD developers, the FSD decided to apply the J2EE framework in developing the new Small Package application. In doing so, it became the first DoD agency to apply J2EE technology to a production application.

With the assistance of the Sun Professional Services Java Center, two FSD developers completed the first phase of the application in just three months. A high level of componentization within the application makes it easy to enhance the application with additional functionality. And just as important, the development effort yielded a number of reusable services components, which will significantly speed up the development of new applications at the FSD, as well as the migration of existing applications, such as FAST, to a J2EE-based architecture.

Lori Barnhill, MIS specialist at the FSD, notes that the agency is a pioneer within the DoD in the implementation of the industry and DII COE standards. “We are the first agency in the Department of Defense to develop a Web-enabled J2EE technology-based application that complies with the DISA specifications,” she says. “We are also the first agency to interface with a commercial system—such as our shipping vendors—using the J2EE technology-based framework.”