Revision Date: March 18, 2004
1. INTRODUCTION
The Clinger-Cohen ActR requires each federal agency to create an Information Technology ArchitectureD. This architecture is the framework and process for aligning Information Technology (IT)D with the business of the U.S. Fish and Wildlife Service (Service) and sustaining that alignment. This alignment will enable the Service to accomplish its mission more effectively.
The Division of Information Technology Management (ITM) established SITA in December, 1997. Compliance with legislation was one factor driving the creation of SITA. However, equally important was the recognition by Service Managers that the Service should begin operating more like a corporation in order to benefit from the associated efficiencies. In other words, it made good sense. SITA must evolve because it is based on changing information needs and evolving technologies. ITM will continually reevaluate and redefine SITA to serve as a target architecture. This process will enhance SITA's alignment with and support of the Service's mission. ITM will also ensure that SITA evolves in concert with the Department of the Interior's (DOI) Information Architecture.
1.1 Director's Support
The Director's support for SITA is demonstrated in A Strategy for Sharing Corporate InformationR, which was signed on August 27, 1999. The Director supports SITA, not only to comply with the requirements of Clinger-Cohen, but also to ensure that IT decisions are made in support of the business of the Service.
1.2 Service Mission and Goals
Knowing the business of the Service is critical to creating an effective information architecture. The Service's mission is "Working with others, to conserve, protect and enhance fish, wildlife, and plants and their habitats for the continuing benefit of the American people."
The Service's Mission goals are defined in the Fish and Wildlife Service Strategic Plan, 2000 - 2005R. This Strategic Plan was prepared in accordance with the Government Performance and Results ActR. The four mission goals are:
SITA supports the above by defining the IT framework for achieving current, accurate and shared information; reliable, rapid, and secure communications; and flexible technologies.
1.3 SITA Organization
SITA is comprised of the following interrelated sections. The first twelve sections comprise the architecture components, also known as sub-architectures.
Application Architecture
Data Architecture
Desktop Architecture
Electronic Mail Architecture
Enterprise Directory Services Architecture
Geographic Information Systems (GIS) Architecture
Intranet Architecture
Network Architecture
Radio Architecture
Security Architecture
Software Architecture
Telecommunications Architecture
Acronyms and Terms
Definitions
References
Appendix 1. Standard User Interface (SUI)
Appendix 2. Desktop/Client
Systems Standards
Appendix 3. Commercial-Off-The-Shelf (COTS)
Software Standards
Each architecture component is defined in detail in a separate section, and each section contains the following topics:
Mission Statement. | Provides a concise statement of the purpose of the specific architecture. |
---|---|
Introduction and Background. | Provides general background information and a high level discussion of key features and issues related to the architecture component. |
Standards. | Identifies standards related to the specific architecture. |
Contracts. | Identifies existing contracts for purchasing items related to the architecture component. |
Contact for Architecture Component | Identifies the individual(s) to contact with questions about the architecture component. |
1.4 SITA Compliance
An IT ProjectD may fall into one, or more than one, of the architecture components listed in section 1.3. For an information project to SITA-compliant, it must comply with all relevant standards defined in the appropriate architecture sections.
1.5 Contacts
For general questions, comments, and suggestions regarding SITA, please contact Al Fisher, Chief - Branch of Data and Systems Services, 303-275-2413. For questions on specific sections, please communicate with the contact person for that section.
2.1 Mission Statement
The Application Architecture defines the processes for developing economical, long-lived software applications that satisfy users' needs, can evolve quickly to satisfy changing information needs, can be maintained with minimum cost and disruption to users, and require minimum training and technical support. In addition, this architecture assures that all applications within the Service can communicate and share data as necessary to accomplish the Service's mission.
2.2 Introduction and Background
The goal of the Application Architecture is to assist in the rapid implementation and deployment of open computer applications in a rapidly changing computer environment. Many of the Service's software applications are considered to be "stovepiped". The term stovepipe is a metaphor for the exhaust pipes of pot-bellied stoves. Because wood burning produces corrosive substances that erode metal, a stovepipe must be constantly maintained and repaired to avoid leakage. Often, these stovepipes are repaired with any materials at hand; thus wood-burning stoves quickly became a hodgepodge of ad hoc repairs - hence, the term stovepipe is used to describe the ad hoc structure of many software systems. Stovepiped software applications and systems are designed independently at every level, from analysis to implementation.
Lack of commonality among disparate applications inhibits interoperability between these systems, prevents reuse, and drives up costs. There is little if any opportunity to share data or expertise across stovepiped systems. As a result, Regional and Field offices have to work with more than one legacy system, each with its own idiosyncrasies.
To avoid these types of systems in the future, the Service must coordinate the development of new applications through the definition of an application architecture. This architecture includes the standards presented here and the SUI presented in Appendix 1. The establishment of these standards and the SUI will help ensure that future SITA-compliant applications are maintained at a minimum cost and will interoperate with other SITA-compliant systems within the Service.
2.3 Standards
2.4 Contracts
Contact: Karen Wood, 303-275-2415
2.5 Contact for Architecture Component
Mike Brewer, Chief - Systems Development Services, 303-275-2302.
3.1 Mission Statement
The mission of the Data Architecture is to manage the Service's data as a corporate asset.
3.2 Introduction and Background
The work of the Service must be based on sound information. Our data is the foundation on which we build our assessments, recommendations and forecasts. This data is a corporate resource just as our personnel constitute a corporate resource. As such, our data must be safeguarded, documented, compatible, accessible, and available for use throughout the Service. Reuse of data will free our Field Offices from the requirements to recreate data and to reenter data into multiple information systems.
3.3 Standards
3.4 Contracts
Contact: Karen Wood, 303-275-2415
3.5 Contact for Architecture Component
Barb White, National Data Administrator, 303-275-2310.
4.1 Mission Statement
The Desktop architecture defines desktop systems to be used for running SITA-compliant applications and standard COTS software packages.
4.2 Introduction and Background
Although the Service is moving towards open or "platform independent" solutions, as evidenced by adopting the SUI, issues relating to technical support, the availability of COTS Software and, to some extent, security, require the Service to adopt Desktop/Client Systems standards. The desktop architecture is based on Intel/Microsoft products. These standards do not preclude the use of other computer systems as servers, or as workstations for very specific applications aimed at small audiences, however; it should be clearly understood that only desktop/client systems that comply with the following standards will be SITA-compliant.
4.3 Standards
4.4 Contracts
Contact: Karen Wood, 303-275-2415
4.5 Contact for Architecture Component
Debra Brown, Acting Chief - Branch of Technical Services, 703-358-1729.
5. ELECTRONIC MAIL ARCHITECTURE
5.1 Mission Statement
E-mail is the primary method of conducting business operations within the Service and within DOI. It provides a means for the quick and efficient exchange of all types of data files across the system. These advantages in speed and efficiency directly benefit the decision-making process and translate into measurable cost and time savings.
5.2 Introduction and Background
FWS-Mail/Messaging (FWS Messaging) (the ServiceĀ“s national e-mail system) was established in 1992. FWS Messaging has evolved over the years, most recently with the Servicewide infrastructure upgrade from Lotus cc:Mail to Lotus Domino/Notes. This upgrade has significantly improved the reliability and performance of Servicewide e-mail, as well as reduced the effort and cost associated with managing e-mail. FWS Messaging supports more than 8,000 users nationwide.
Because most DOI agencies are using Lotus Notes, data and email exchange across multiple DOI bureaus is quicker and easier. Lotus Notes provides the tools for workgroup and workflow automation, information management and sharing capabilities.
The FWS Information Portal was established to offer a convenient starting point for access to Service resources, such as the FWS Home Page and the Service Internal Internet (SII). The Portal also offers a convenient connection point for access to commonly used features of Notes, such as e-mail, calendars, address books and to-do lists. The Portal will also provide additional links to specified Regional resources.
The FWS Information Portal provides a more efficient means of distributing news and information to all employees by dramatically reducing the number of messages necessary to reach all Service employees. This is accomplished by using a national news database that is replicated to all Notes servers (rather than distributing a copy of the message to every Service employee). Regional and local databases allow managers to target news and information to specific audiences.
5.3 Standards
5.4 Contracts
None.
5.5 Contact for Architecture Component
Brenda McCoy, FWS-Messaging Operations Manager, 303-275-2400.
6. ENTERPRISE DIRECTORY SERVICES ARCHITECTURE
6.1 Mission Statement
Enterprise Directory Services provides a viable framework for a cross-platform user directory that leverages not only informational directory capabilities but also a powerful application security system. The Service uses Lightweight Directory Access Protocol (LDAP) to provide session-based authentication on names and Internet passwords in the Lotus Notes Name and Address Book (NAB).
6.2 Introduction and Background
LDAP is an Internet standard for directory services that runs over TCP/IP. An LDAP client, such as Lotus Notes, connects to an LDAP server and can submit a query to request information. An LDAP directory is a database that can be served through an LDAP server as a specialized directory service.
Benefits of a Notes-based LDAP directory:
The BCT implemented a system that allows outside access to the Service's Intranet using LDAP authentication. With this system, requests for Intranet pages are passed through a front-end proxy server that contains centralized authentication controls. Users from inside the Service network are allowed access with no additional authentication, while users from outside the network must pass LDAP authentication with their Lotus Notes user name and Internet password.
Using this method, static Intranet sites and advanced application sites can be placed behind the Intranet proxy to allow access for both Service users with external Internet service access and Service partners in the Extranet community. In addition to basic access control at the proxy server, additional restrictions may be placed on certain sites. For instance, the proxy server may require that all users, whether they are from inside the Service network or not, must be authenticated as part of a specific Lotus Notes group prior to being granted access to a particular application.
Web account managers for sites hosted by the BCT now use a system that allows users to modify their personal LDAP record. These users can synchronize their Lotus Notes Internet password with their active directory password for File Transfer Protocol (FTP) access through a single Web form.
6.3 Standards
The current LDAP schema used by the Service is using the default Notes configuration, which is aligned with the open LDAP standards. The following primary fields are used in the Service LDAP implementation:
NAB Field | LDAP Field | Value Example |
---|---|---|
FirstName | givenname | John |
LastName | sn | Doe |
CN | cn | John Doe |
DisplayName | dn | CN=John Doe, OU=BCT, OU=R9, OU=FWS, O=DOI |
ShortName | uid | jdoe |
HTTPPassword | userPassword | Encrypted String |
Internet Address | John_Doe@fws.gov | |
OfficePhoneNumber | telephoneNumber | (123) 456-7890 |
Location | Location | Office Name |
City | homeCity | City Location |
Any other LDAP servers utilized within the Service must comply with these basic standards. Applications that are built on these standards must be able to rely on the persistence of the standard laid out within SITA.
6.4 Contracts
None.
6.5 Contact for Architecture Component
Stu Mitchell, Engineering Team Leader, 303-275-2325.
7. GEOGRAPHIC INFORMATION SYSTEMS (GIS) ARCHITECTURE
7.1 Mission Statement
The mission of the GIS architecture is to facilitate the knowledge of, and use of, this technology in the Service in order to enhance decision making and natural resource management.
7.2 Introduction and Background
Although GIS can be considered as one of many IT technologies used in the Service, it has its own advisory group, the Service GIS Steering Committee. This group is charged with guiding the use of this technology in the Service. Also, the National GIS Coordinator maintains the Geographic Information Systems & Spatial Data web site to assist biologists, managers, and GIS professionals in achieving the maximum benefit from this technology. As a result of the emphasis placed on GIS in the Service, it is defined as a separate architecture component.
7.3 Standards
7.4 Contracts
Contact: Karen Wood, 303-275-2415
7.5 Contact for Architecture Component
Deb Southworth Green, National GIS Coordinator, 303-274-3574.
8.1 Mission Statement
The Service's Intranet is implemented as the SII. The main purpose of the SII is to provide a secure, collaborative work environment based on Intranet technology. The SII is restricted to Service employees and has the ability to provide access to Service partners.
8.2 Introduction and Background
The SII is a collection of web servers that use IP filtering to restrict access to users that have Service IP addresses. Most of the SII web pages reside on a computer located at the BCT in Lakewood, CO. A few of the Regions also have web servers that restrict access by IP address. These servers are considered to be part of the SII.
A proxy server allows users from outside of the SWAN, to access internal resources. The proxy detects users with non-Service IP addresses and switches them to a secure link using Secure Socket Layer (SSL). The user is prompted for a user name and password, which is authenticated with the Lotus Notes NAB.
The Service does not currently have a Virtual Private Network (VPN) standard.
8.3 Standards
8.4 Contracts
None.
8.5 Contact for Architecture Component
Sky Bristol, Internet Services Manager, 303-275-2372.
9.1 Mission Statement
The mission of the network architecture is to provide a stable, reliable wide area network transport that supports data communications within the Service. The BCT, located in Lakewood, CO, provides engineering and operational support for the SWAN. The SWAN is supported 12 hours a day 5 days a week. (5am to 5pm Mountain Time, Monday through Friday.)
9.2 Introduction and Background
The SWAN consists of a variety of wide area network circuits including but not limited to Dedicated Transmission Service (DTS), Frame Relay and Asynchronous Transfer Mode (ATM). The network is arranged in a hierarchical configuration and the backbone nodes are located in Portland, OR (R1), Lakewood, CO (BCT) and Arlington, VA (R9). Major distribution nodes are located in Hadley, MA (R5), Atlanta, GA (R4), Minneapolis, MN (R3), Albuquerque, NM (R2), Lakewood, CO (R6) and Anchorage, AK (R7).
A centralized Service Modem Pool (SMP) is located in Lakewood at the BCT. It provides dial up services via a toll free number. Field Stations and travelers use the SMP to gain access to SWAN resources and the Internet.
Internet services is provided by UUNET at each of the backbone nodes. (Portland, Lakewood and Arlington)
Field Stations may elect to use local Internet Service Providers (ISP) instead of the SMP or a direct connection to the SWAN. However, these connections are not centrally supported by the BCT. Access to the SII and other internal resources requires additional VPN software and hardware at the Field Station.
9.3 Standards
9.4 Contracts
None.
9.5 Contact for Architecture Component
Stu Mitchell, Engineering Team Leader, 303-275-2325.
10.1 Mission Statement
The Service has standardized on the Federal Land Mobile Radio Standard, known as Telecommunications Industry Association (TIA)-102, for all of our radio systems. The Service is currently migrating all of its radio systems to this standard.
10.2 Introduction and Background
Congress passed legislation authorizing the auction of the radio frequency spectrum, forcing federal agencies to reduce frequency bandwidth. To comply with this legislation, the National Telecommunications Information Agency (NTIA) created additional radio channels by "narrowbanding" the VHF and UHF radio spectrum so that a portion of this radio spectrum could be auctioned off by the Federal Communications Commission (FCC). Radio narrowbanding reduces a radio channel's bandwidth by 50%, which doubles the number of channels available for frequency assignment within a given frequency range. The federal VHF high-band portion of the radio spectrum (162-174 MHz) must be narrowbanded by January 2005 and the UHF (406-420 MHz) radios by 2008. All Service radio systems must be redesigned by these dates. To meet this requirement, the Service adopted and mandated transition to the Federal Land Mobile Radio Standard (TIA-102), which has become the standard of choice for the federal and civilian public safety community. The new radio communication standard is known as TIA-102 in the federal arena, and Project 25 in the civilian world. It was developed by the Association of Public Safety Communications Officials (APCO) in conjunction with industry representatives and the user community. Technical information on the TIA and APCO standards may be found at http://www.apcointl.org/frequency/project25/.
After 2008, its likely the federal government will be mandated to narrowband our radio systems again to conserve even more of the radio spectrum. Because the Service standardized on TIA-102, we will be able to accomplish this by simply upgrading the software in the radios we are now purchasing.
This standard has also been adopted as the 700 MHz public safety band standard by the FCC. TIA-102 supports the integration of both data and voice over one medium and will allow public safety users to communicate by using a common air interface regardless of the frequency by using bridging devices.
The BCT provides a single source for radio project implementation solution for our customers, saving them time, money and resources.
10.3 Standards
These standards apply to all Service radio systems and trunked, mobile data and control systems.
10.4 Contracts
DOI contract: http://www.blm.gov/natacq/IDIQ/index.html.
10.5 Contact for Architecture Component
Noel Newberg, National Telecommunications Manager, 303-275-2409.
11.1 Mission Statement
Provide policy, guidance, advice, and oversight in the area of IT security.
11.2 Introduction and Background
Security is a cross-cutting issue and concern, relevant to all Service computer use. The lowest level of restriction, referred to as IP filtering, does not provide security, but excludes nearly all access from non-Service users. Higher levels of security are obtainable through the use of usernames and passwords, intermediate devices such as "firewalls," and the encryption capabilities of hosts and browsers.
The effectiveness of security on a user level is dependent upon many factors, including complexity of passwords, password aging, user education, and compliance with security procedures by both information/system owners and users. Application of and adherence to industry and bureau "best practices" where cost effective and relevant should address a great number of the security issues the Service will encounter.
Standards
11.3 Standards
11.4 Contracts
None.
11.5 Contact for Architecture Component
Thomas Snoich, Bureau IT Security Manager, 703-358-1729/2215
12.1 Mission Statement
The software architecture defines standard COTS software packages for use in the Service.
12.2 Introduction and Background
The Service is reliant on COTS Software for routine activities and office functions such as word processing, spreadsheets, and electronic mail. The COTS standards simplify and reduce technical support costs, acquisition costs, and interoperability and document exchange difficulties.
12.3 Standards
12.4 Contracts
Contact: Karen Wood, 303-275-2415
12.5 Contact for Architecture Component
Al Fisher, Chief - Branch of Data and Systems Services, 303-275-2413.
13. TELECOMMUNICATIONS ARCHITECTURE
13.1 Mission Statement
The Service's long distance telecommunications services are centrally managed and ordered to provide the most cost effective services possible while meeting mission requirements.
13.2 Introduction and Background
FTS2001 is a Governmentwide contract vehicle that provides cost effective telecommunications services including voice, calling cards, video conferencing, data, and internet services. While this contract is non-mandatory, there are minimum revenue guarantees to the vendors that must be met. The Service will be using the FTS2001 contract for all voice and calling card services. Video, data and internet services will be ordered using the FTS2001 contract when it is the best solution in terms of functionality and cost effectiveness.
13.3 Standards
13.4 Contracts
FTS2001, GS00T99NRD2002.
13.5 Contacts for Architecture Component
Region 1 - Mike Lee, 503-231-2234
Region 2 - Sherry Hoff,
505-248-6446
Region 3 - David Gustafson,
612-713-5210
Region 4 - Leslie Strickland,
404-679-4131
Region 5 - Debra Euchler,
413-253-8333
Region 6 - Brian Ostenson,
303-236-5412 x223
Region 7 - Mike Lewis,
907-786-3347
Region 9 - Lilly Hankins,
703-358-1729
National Conservation Training Center (NCTC) - Linda
Shook, 304-876-7421
Bureau of Communication Technology, Ellen
Waterman, National Voice Systems
Manager, 303-275-2410
The following acronyms are used in this document:
APPENDIX 1. STANDARD USER INTERFACE (SUI)
The SUI is defined as Internet Explorer 5.x with 128 bit encryption and specific security settings. The SUI does not include plug-ins, components and add-ons except for the following. Developers may use one or more of the following as part of a system's user interface.
Name | Version | Manufacturer |
---|---|---|
Acrobat Reader | 4.x | Adobe |
Virtual Machine for Java | Version (build) distributed with Internet Explorer 5.x. | Microsoft |
Crystal Reports Active X Viewer | 8 | Seagate |
Developers wishing to add additional software to the above list, must coordinate with the Chief - Systems Development Services.
Microsoft periodically releases security updates for Internet Explorer. Users are advised to implement security patches as they are released. Developers are advised to take these updates into account.
Applications that deliver content (e.g., Hyper Text Markup Language (HTML), Dynamic HTML (DHTML), Applets, Javascript) to the SUI must follow security guidelines for the use of sessions and cookies as described in section 2.3.8. In addition, these applications must be consistent with the specific security settings for Internet Explorer 5.x.
Developers of SITA-compliant software applications for Service personnel and Service contractors will build for this client-side interface. Users of these applications will have this interface installed on their workstations. The advantages of a SUI are: developers will always "know" their user community even if the individual users are unknown, persons providing technical support to the user community will have fewer variables to consider when troubleshooting problems, ITM managers and the user community will find it easier to deal with security issues and software updates. When the user community for an application includes people outside the Service, that segment of the user community may not be using the SUI. They may use a different user interface, e.g., the Netscape browser. In this case, the application must be designed to work with the SUI as well as with any Netscape standards specific to the application itself. Exceptions to the SUI standards will be addressed on a case-by-case basis if difficult technical incompatibilities between the two browsers force a compromised solution.
Note that the SUI standards presented here do not apply to Web Publishing for non-Service audiences where both Internet Explorer and Netscape are used. For guidance on Web Publishing, visit the Service's Web Publishing Site.
There is one alternative to the SUI for applications that will be built in Lotus Notes. If the users of a system have all been converted to the Notes Client, then a developer may consider the Notes Client as an alternative interface for that system. Systems developers need to be aware that the migration from cc:Mail to Notes Mail has not been completed for all Service personnel. Also, some Service users will not convert to the Notes Client, e.g., some users will access Notes Mail via a browser. An additional point to consider is that there is no guarantee that users outside the Service will be using the Notes Client. The decision to use the Notes Client as a user interface should be weighed carefully.
Contact: Mike Brewer, Chief - Systems Development Services, 303-275-2302.
APPENDIX 2. DESKTOP/CLIENT SYSTEMS STANDARDS
The goal of these standards is to define desktop computers that will be guaranteed, at any given time, to run any SITA-compliant system. System developers will know what sort of systems they need to be able to support, and offices will be able to plan procurement accordingly. As technology progresses, SITA-compliance will inevitably change, and we want to provide information that will allow procurement planning to keep apace. We don't want to make a change that will make existing systems non-compliant without advance notification.
A feature of the standards is the assignment of expiration dates as a way to define expectations as to how long a desktop system will be viable in regard to support of SITA-compliant systems. If you purchase a PC meeting a standard with a given expiration date, then you can expect the platform to be able to run SITA-compliant systems at least to that date, and you can expect support. If you are trying to run a SITA-compliant system on a platform with standards that have expired, you should not expect support. The Minimum spec will expire before the Recommended spec, so offices that buy PCs will know the SITA expectation and be able to make rational planning decisions for PC purchases. An office that purchases a Minimum spec PC may have to upgrade at the expiration date in order to remain SITA-compliant, so one can save some up-front costs at the expense of a (possibly) shorter SITA-compliant life. SITA-compliant developers must be prepared to support such platforms until the expiration date. As time proceeds, we will modify the Minimum and Recommended specs to keep up with technology.
Note that the previous Recommended spec equals or exceeds the new Minimum, so those who invested in the old Recommended spec will be good for a while.
Nominations for changes to these standards should be submitted to Debra Brown in the Division of ITM.
Component | Current Minimum (expires October, 2001) | Recommended Specification (expires October 2003) |
---|---|---|
Operating System | Windows 95 | Windows 98, Windows 2000, or NT 4.x with Service Pack 6.0a or above |
Processor | Celeron, Pentium II, AMD K6-2 | Pentium III, AMD K7 |
Clock | At least 266 MHz | 800 MHz or higher |
Memory | At least 32MB of SD-RAM | 128MB or more of SD-RAM |
Cache | 512 KB, type L2 | 1024 KB, type L2 |
Hard Drive | At least 6 GB IDE | 10 GB or more IDE, SCSI or ATA/UDMA 66 |
Bus | 100-133 MHz | |
NIC (LAN connection) | 10/100 Mbps | 10/100 Mbps |
Modem (dialup) | V.90 dual standard | V.90 dual standard |
Video Controller | AGP card with at least 4 MB, at least 800 X 600 resolution | AGP card with at least 16 MB, supporting at least up to 1280 X 1024 resolution |
Monitor | 15" SVGA, .28 pitch, at least 800 X 600 resolution | 17" SVGA, .26 pitch or less, at least 75 Hz refresh rate at high resolutions (1024 X 768, 1280 X 1024). Note: larger monitors should have smaller pitch (.22-.25). |
Contact: Debra Brown, Acting Chief - Branch of Technical Services, 703-358-1729.
APPENDIX 3. COMMERCIAL-OFF-THE-SHELF (COTS) SOFTWARE STANDARDS
Note: Although some of the following COTS software packages may be included in the SUI, this is not true for all. See Appendix 1 for details on the SUI.
Name | Version | Manufacturer |
---|---|---|
Acrobat Reader | 4.x | Adobe |
Crystal Reports Active X Viewer | 8 | Seagate |
Domino | 5.0.x | Lotus/IBM |
Internet Explorer | 5.x and 128-bit encryption | Microsoft |
QWS 3270 (free 3270 emulator for casual users of the Federal Financial System (FFS) and Federal Payroll and Personnel System (FPPS)) | 3.2 | Jolly Giant |
QWS 3270 Plus (commercial 3270 emulator for those requiring advanced FPPS functions) | 3.2 | |
Notes Client | 5.0.3 and above. | Lotus/IBM |
Virtual Machine for Java | The version (build) distributed with Internet Explorer 5.x. | Microsoft |
Windows | XP | Microsoft |
Windows 2000 | Server | Microsoft |
SITA defines several file exchange standards in terms of COTS software file formats.
Standard | File Formats |
---|---|
Geospatial Data Exchange Format | Arc/Info Export (.E00), ESRI Shapefile, AutoCAD DWG |
Al Fisher, Chief - Branch of Data and Systems Services, 303-275-2413.
Return to the U.S. Fish and
Wildlife Service Information Technology Management Home Page.
Visit the U.S. Fish and Wildlife Service Home Page.
Please contact Dr. Alan R. Fisher with any questions and
comments.
Privacy Statement
Last Modified