Service Information and Technology Architecture (SITA)

Revision Date:  March 18, 2004

1.  INTRODUCTION

The Clinger-Cohen Act^R requires each federal agency to create an Information Technology Architecture^D.  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 Information^R, 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 - 2005^R.  This  Strategic Plan was prepared in accordance with the Government Performance and Results Act^R.  The four mission goals are:

• Sustainability of Fish & Wildlife Populations
• Habitat Conservation: A Network of Lands & Waters
• Public Use & Enjoyment
• Partnerships in Natural Resources

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:

1.4  SITA Compliance

An IT Project^D 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.  APPLICATION ARCHITECTURE

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

1. As directed in Management of Federal Information Resources^R, developers must ensure that decisions to improve existing information systems or develop new information systems are initiated only when no alternative private sector or governmental source (i.e., application) can efficiently meet the need.
2. Developers must follow capital asset planning guidance contained in 270 FW 2, Information Technology Capital Asset Planning^R when the manual chapter is finalized.
3. Developers must prepare a project charter as described in 270 FW 3, Project Management^R.
4. Developers of remotely accessed, multi-user applications must coordinate with the Bureau of Communication Technology (BCT) early in the planning process.  This coordination is necessary to ascertain if the Service Wide Area Network (SWAN) can support the data traffic generated by the application.
5. Remotely accessed^D, multi-user systems, must be hosted on Internet Protocol (IP) addressable hosts.
6. Remotely accessed^D, multi-user applications developed by the Service and used by Service personnel must be written for the SUI as defined in Appendix 1.
7. Service Personnel who use Service-developed, remotely accessed^D, multi-user applications must have the SUI installed on their desktops.
8. All web-based applications developed by the Service must comply with DOI ITM Bulletin No. 2001-001, Policy Use of "Persistent Cookies" on Interior Web Sites.^R.
9. All web-based applications developed by the Service must post a privacy policy following the DOI Privacy Policy^R.
10. All web-based applications that are accessible by children must comply with DOI ITM Bulletin No. 2001-004, Interim Guidance on Children's Privacy Statements on Web Sites^R.
11. All applications, regardless of how they are accessed, must comply with Section 508 of the Rehabilitation Act^R.  The Architectural and Transportation Barriers Compliance Board (Access Board) published the Electronic and Information Technology Accessibility Standards^R on December 21, 2000.  Federal agencies must be in compliance with these standards by June 21, 2001.  Enforcement provisions of Section 508 are effective as of June 21, 2001.
12. All applications, regardless of how they are accessed, must work properly in conjunction with desktop workstations which comply with the Desktop Architecture.
13. All applications, regardless of how they are accessed, which have an email component must integrate with and be compatible with Notes mail.
14. When developing applications that require access to stored data, developers must use data sources (e.g., relational database, files, text archives) that provide drivers for either the Java Database Connectivity (JDBC) Application Programming Interface (API) or the Open Database Connectivity (ODBC) API.
15. When developing applications which use the Extensible Markup Language (XML), developers must make sure that any created XML documents follow the XML 1.0 Specifications detailed by the World Wide Web Consortium.
16. All applications, regardless of how they are accessed, must adhere to relevant Service security policies.
17. All applications, regardless of how they are accessed, must comply with relevant Service data standards.
18. Developers must coordinate with the National Data Administrator to ensure the data to be collected or created do not already exist.
19. All applications, regardless of how they are accessed, must have current, accurate data dictionaries.  Data dictionaries must define data as well as describe data sources, collection and creation procedures, quality, quality control parameters, formats, and storage locations.  In particular, data dictionaries must clearly identify data items which comply with Service data standards.
20. Developers must work with the National Data Administrator to establish new data standards to maximize the utility of the application and its associated data.
21. Developers, when collecting, creating or updating data which can be related to points on the Earth, must spatially reference the data to facilitate planned or possible future GIS analyses.
22. Developers must make the application's data available to the Service.
23. When archiving applications, developers must coordinate with the National Data Administrator and the Records Manager regarding archiving of the system's data.

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.  DATA ARCHITECTURE

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

1. Managers of data creation projects must follow capital asset planning guidance contained in 270 FW 2, Information Technology Capital Asset Planning^R when the manual chapter is finalized.
2. Managers of data creation projects must prepare a project charter as described in 270 FW 3, Project Management^R.
3. Coordinate with the BCT early in the planning process if large data files will be exchanged via the SWAN.  This coordination is necessary to ascertain if the SWAN can support the data traffic.
4. Prior to collecting or creating data, coordinate with the National Data Administrator to ensure the data does not already exist.
5. Comply with relevant Service data standards when collecting, creating or updating data.
6. Adhere to relevant Service security policies.
7. Work with the National Data Administrator to establish new data standards when necessary to maximize the utility of the data.
8. When collecting, creating or updating data which can be related to points on the Earth, spatially reference the data to facilitate planned or possible future GIS analyses.
9. All data sets must have current, accurate data dictionaries.  Data dictionaries must define data as well as describe data sources, collection and creation procedures, quality, quality control parameters, formats, and storage locations.  In particular, data dictionaries must clearly identify data items which comply with Service data standards.
10. Make the data available to the Service.
11. Before buying data, ascertain if the data are available from an existing contract or if the Service already owns the data.
12. When buying data, attempt to acquire the data for the entire Service and not for an individual office alone.
13. Coordinate with the National Data Administrator and the Records Manager when archiving data.

3.4  Contracts

Contact: Karen Wood, 303-275-2415

3.5  Contact for Architecture Component

Barb White, National Data Administrator, 303-275-2310.

4.  DESKTOP ARCHITECTURE

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

1. All desktop and client systems must support Transmission Control Protocol/Internet Protocol (TCP/IP), be able to run the SUI, be able to run the Service email client, and be able to run the Service standard COTS software.
2. All desktop systems must comply with Section 508 of the Rehabilitation Act^R.  The Access Board published the Electronic and Information Technology Accessibility Standards^R on December 21, 2000.  Federal agencies must be in compliance with these standards by June 21, 2001.  Enforcement provisions of Section 508 are effective as of June 21, 2001.
3. All desktop systems must comply with the Desktop/Client Systems Standards defined in Appendix 2.

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

1. The BCT, in coordination with the Regional Notes teams, sets operational and configuration standards for Lotus Notes implementations, which are published in the BCT documentation library.
2. The standard interface for Service email is the Notes client version 5.05 and above (5.06, 5.07 and 5.08).
3. The Notes client includes an imbedded browser; however, this browser should not be used.   Instead, the Notes client should be configured to use Internet Explorer as the browser.
4. FWS regularly participates with DOI in providing comments for Department-wide messaging standards and practices.

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:

1. The information comes directly from the NAB, so standards and validation constraints in the NAB apply to the LDAP directory.
2. Individual users can maintain their own telephone numbers and other contact information through the Notes client.
3. An LDAP directory can be accessed across platforms and applications.
4. Other DOI NABs can be combined to provide an LDAP directory for user authentication across bureaus as well as a robust personnel directory (e.g., the Government Services Administration (GSA) white pages project).

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

1. An LDAP directory or any type of user directory operates on the basis of a "schema."  The schema specifies the data standards in place for the directory and determines the nature of all fields in the directory.  This includes field type, size and content.  When creating an enterprise directory that incorporates many diverse records into one central database, the participating records must adhere to the schema 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:

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

1. As directed in Management of Federal Information Resources^R, developers of GIS must ensure that decisions to improve existing systems or develop new systems are initiated only when no alternative private sector or governmental source can efficiently meet the need.
2. GIS developers must follow capital asset planning guidance contained in 270 FW 2, Information Technology Capital Asset Planning^R when the manual chapter is finalized.
3. GIS developers must prepare a project charter as described in 270 FW 3, Project Management^R.
4. GIS developers of remotely accessed, multi-user applications must coordinate with the BCT early in the planning process.  This coordination is necessary to ascertain if the SWAN can support the data traffic generated by the application.
5. Remotely accessed^D, multi-user systems, must be hosted on IP addressable hosts.
6. Remotely accessed^D, multi-user GIS applications developed by the Service and used by Service personnel must be written for the SUI as defined in Appendix 1.
7. Service Personnel who use Service-developed, remotely accessed^D, multi-user GIS applications must have the SUI installed on their desktops.
8. All web-based GIS applications developed by the Service must comply with DOI ITM Bulletin No. 2001-001, Policy Use of "Persistent Cookies" on Interior Web Sites.^R.
9. All web-based GIS applications developed by the Service must post a privacy policy following the DOI Privacy Policy^R.
10. All web-based GIS applications that are accessible by children must comply with DOI ITM Bulletin No. 2001-004, Interim Guidance on Children's Privacy Statements on Web Sites^R.
11. All GIS systems, regardless of how they are accessed, must comply with Section 508 of the Rehabilitation Act^R.  The Access Board published the Electronic and Information Technology Accessibility Standards^R on December 21, 2000.  Federal agencies must be in compliance with these standards by June 21, 2001.  Enforcement provisions of Section 508 are effective as of June 21, 2001.
12. All GIS systems, regardless of how they are accessed, must work properly in conjunction with desktop workstations which comply with the Desktop Architecture.
13. All GIS systems, regardless of how they are accessed, which have an email component must integrate with and be compatible with Notes mail.
14. All GIS systems must adhere to relevant Service security policies.
15. All GIS systems must comply with relevant Service data standards.
16. GIS developers must coordinate with the National GIS Coordinator to ensure that the data to be collected or created does not already exist.
17. GIS developers must work with the National GIS Coordinator to establish new data standards to maximize the utility of the data.
18. Data shared via the SII or the Internet must be documented according to the Geospatial Metadata Standard.  In particular, metadata must clearly identify data items which comply with Service data standards.  GIS developers are  encouraged to document all data.
19. GIS developers must make the data available to the Service.
20. Before buying data, ascertain if the data are available from an existing contract or if the Service already owns the data.
21. When buying data, attempt to acquire the data for the entire Service and not for an individual office alone.
22. When archiving systems and/or data, GIS developers must coordinate with the National GIS Coordinator and the Records Manager.

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.  INTRANET ARCHITECTURE

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

1. SII web servers must restrict access to users with an IP address in the range assigned to the Service.
2. All SII web servers must keep the Operating Systems (OS) up to date and they must apply all relevant security patches.
3. Log files must be kept for at least one week.
4. There must be a system administrator who is responsible for monitoring the site and ensuring that only Service employees gain access to the information.
5. SII administrators must adhere to all Service security policies.
6. SII pages should be kept current and expired sites must be deactivated.
7. A web manager must be appointed for each site and the contact person must be posted on the web pages.
8. The SII site must be registered with the BCT.
9. All communications over non-SWAN connections must be encrypted.
10. All SII servers must conform to any Service VPN implementation standards.
11. SII applications must comply with the Application Architecture.
12. Authentication and authorization for SII applications must follow Service best practices as defined by the BCT: US Fish and Wildlife Service Intranet Web Design, LDAP Authentication for Applications.
13. SII sites must comply with DOI ITM Bulletin No. 2001-001, Policy Use of "Persistent Cookies" on Interior Web Sites^R.
14. SII sites must post a privacy policy following the DOI Privacy Policy^R.
15. SII sites must comply with Section 508 of the Rehabilitation Act^R.  The Access Board published the Electronic and Information Technology Accessibility Standards^R on December 21, 2000.  Federal agencies must be in compliance with these standards by June 21, 2001.  Enforcement provisions of Section 508 are effective as of June 21, 2001.

8.4  Contracts

None.

8.5  Contact for Architecture Component

Sky Bristol, Internet Services Manager, 303-275-2372.

9.  NETWORK ARCHITECTURE

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

1. SWAN nodes must be designed by the BCT and they must use a Cisco router as recommended by the BCT. (Reference the notes from the SWAN Definition Workshop, 1997.)
2. ISP connections for Field Stations are allowed.  They must be coordinated with the Regional Office and BCT according to the Service Modem Pool: Regional Migration from the Service Modem Pool plan.  Support for ISP connections is provided by the local ISP not by the BCT.  (Reference the Service Modem Pool: Regional Migration from the Service Modem Pool.)
3. Standards for ISP connections are provided in the ISP Connectivity document.
4. IP addresses must be assigned according to the Internet Protocol Addressing Standards and Guidelines.

9.4  Contracts

None.

9.5  Contact for Architecture Component

Stu Mitchell, Engineering Team Leader, 303-275-2325.

10.  RADIO ARCHITECTURE

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, it’s 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.

1. All new purchases of VHF (162-174 MHz) and UHF (406-420 MHz) Service radios shall be TIA-102 compliant.
2. All existing Service radio systems must be narrowbanded by January 2005.
3. All Service radio system procurements must be reviewed and approved by the National Telecommunications Manager.  Reference: February 25, 1992 memo from the Director on Radio System Procurement.
4. All Service radios must use authorized frequencies. Contact the BCT at 303-275-2400 before ordering any radio equipment to ensure authorized frequencies are available.
5. All new radio systems must consider sharing with other federal agencies in the vicinity.

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.  SECURITY ARCHITECTURE

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

1. System and application security should not be assumed to be handled by the SWAN. Developers must ensure that adequate security is built into the system commensurate to the scope and access requirements of the system/application. See section 8.3.12 for relevant information..
2. Developers must follow the security guidance and requirements as specified in 270 FW 7^R, its relevant appendices, and OMB Circular A-130^R.
3. System owners are require to perform a Management Control Review (MCR) on all General Support Systems (GSS) and Major Applications at a minimum of every three years, or sooner if major changes are made to the system/application.
4. System owners are required to certify and accredit all GSS and Major Applications at a minimum of every three years.
5. Per the Department''s Interim Network Perimeter Security Standard and 375 DM 19^R, all public information systems will be physically or virtually separated from sensitive information and information systems.
6. Per the Service's Draft Network Perimeter Standard, publicly accessible servers should be located in a "demilitarized zone" (DMZ)^D outside of the Bureau's firewalls.
7. Shared information must be protected appropriately, in a manner comparable to protection provided when information is processed within the system/application.
8. All systems/major applications are required to have a written security plan.
9. All systems/major applications are required to have a written contingency plan.
10. All systems/major applications are required to have a written Risk Assessment^R.
11. All users of sensitive systems are required to have an annual Statement of Responsibility on file prior to accessing any Service IT system.
12. All users of systems requiring password access are required to have an annual Password Control Statement on file prior to access of such systems.
13. Administrative accounts and user accounts shall not be one and the same; user accounts shall not have administrative equivalence.
14. In the event of a security breach or other security-related problem, the issue should be reported as follows: (1) Report the issue to one's immediate supervisor. (2) Report the issue to the local Security Manager. (3) If the issue has national involvement or widespread effect (viruses, system vulnerabilities, etc.), report to the Bureau IT Security Manager for action.

11.4  Contracts

None.

11.5  Contact for Architecture Component

Thomas Snoich, Bureau IT Security Manager, 703-358-1729/2215

12.  SOFTWARE ARCHITECTURE

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

1. When acquiring COTS software, you must comply with the standards contained in Appendix 3.
2. When buying COTS software, investigate the cost vs. benefits of acquiring licenses for the entire Service and not for an individual office alone.
3. All COTS software must comply with Section 508 of the Rehabilitation Act^R.  The Access Board published the Electronic and Information Technology Accessibility Standards^R on December 21, 2000.  Federal agencies must be in compliance with these standards by June 21, 2001.  Enforcement provisions of Section 508 are effective as of June 21, 2001.
4. Microsoft Windows XP is the Service standard desktop operating system.  See IT Technical Bulletin 2004-002, "Adoption of Department of Interior Standardization on Desktop and Server Software."
5. Microsoft Windows 2000 Standard Server is the Service standard server operating system.  See IT Technical Bulletin 2004-002, "Adoption of Department of Interior Standardization on Desktop and Server Software."
6. The Service has standardized on the Microsoft Office XP Suite including Word, Excel, Access, and Powerpoint.  See IT Technical Bulletin 2004-002, "Adoption of Department of Interior Standardization on Desktop and Server Software."

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

1. All orders for FTS2001 services (including new services, changes to existing services and disconnection of service) will be coordinated through the Regional telecommunications contacts.  The Regional contacts will forward requests to the Designated Agency Representative (DAR) at the BCT who will place the orders with MCI Worldcom.

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

14.  ACRONYMS AND TERMS

The following acronyms are used in this document:

• ACCESS BOARD.  Architectural and Transportation Barriers Compliance Board.
• APCO.  Association of Public Safety Communications Officials.
• API.  Application Programming Interface.
• ATM.  Asynchronous Transfer Mode.
• COTS.  Commercial-Off-The-Shelf.
• DAR.  Designated Agency Representative.
• DMZ.  Demilitarized Zone.
• DOI.  Department of the Interior.
• DTS.  Dedicated Transmission Service.
• FCC.  Federal Communications Commission.
• FTP.  File Transfer Protocol.
• GIS.  Geographic Information System.
• GSA.  Government Services Administration.
• GSS.  General Support Systems.
• GWAC.  Governmentwide Acquisition Contract.
• IP.  Internet Protocol.
• ITM.  Information Technology Management.
• ISP.  Internet Service Providers.
• IT.  Information Technology.
• JDBC.  Java Database Connectivity.
• LDAP. Lightweight Directory Access Protocol.
• MCR.  Management Control Review.
• NAB. Name and Address Book.
• BCT.  Bureau of Communication Technology.
• NCTC.  National Conservation Training Center.
• NTIA.  National Telecommunications Information Agency.
• ODBC.  Open Database Connectivity.
• OS.  Operating Systems.
• SERVICE.  U.S. Fish and Wildlife Service.
• SII.  Service Internal Internet.
• SITA.  Service Information and Technology Architecture.
• SMP.  Service Modem Pool.
• SSL.  Secure Socket Layer.
• SUI.  Standard User Interface.
• SWAN.  Service Wide Area Network.
• TCP/IP.  Transmission Control Protocol/Internet Protocol.
• TIA.  Telecommunications Industry Association.
• VPN.  Virtual Private Network.
• XML.  Extensible Markup Language.

15.  DEFINITIONS

• Demilitarized zone (DMZ).  In computer networks, a DMZ is a computer host or small network inserted as a "neutral zone" between a company's private network and the outside public network. It prevents outside users from getting direct access to a server that has company data.  (The term comes from the geographic buffer zone that was set up between North Korea and South Korea following the war in the early 1950s.)
• Extensible Markup Language (XML). The World Wide Web Consortium's open standard for describing data.  XML is used for defining data elements on a Web page and in business-to-business documents.
• Information Technology.  Any equipment or interconnected system or subsystem of equipment, that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by an executive agency. For purposes of the preceding sentence, equipment is used by an executive agency if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency which (i) requires the use of such equipment, or (ii) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. The term "information technology" includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources.  (See Clinger-Cohen Act^R.)
• Information Technology Architecture.  An integrated framework for evolving or maintaining existing information technology and acquiring new information technology to achieve the agency's strategic goals and information resources management goals.  (See Clinger-Cohen Act^R.)
• IT Project.  The expenditure of funds for IT assets, including hardware, software, communications, data, the development, operations, and maintenance of IT systems (including employee and contractor costs), and modifications to existing Service information systems and databases.  (See 270 FW 2^R.)
• Java Database Connectivity (JDBC).  A Java API that enables Java programs to access Standard Query Language (SQL) data sources, e.g., relational databases.
• Open Database Connectivity (ODBC).  A database programming interface from Microsoft that provides a common language for Windows applications to access databases on a network.
• Remotely Accessed.  For the purposes of this document, remotely accessed is defined as accessed by a desktop which is not connected to the application server by means of a Local Area Network.

16.  REFERENCES

1. 270 FW 2, Information Technology Capital Asset Planning.  This document is in draft.  Contact Lou Irwin for status.
2. 270 FW 3, Project Management (replaced by 270 FW 2).
3. 270 FW 7, Automated Information System Security.
4. 375 DM 19, Information Technology Security.
5. A Strategy for Sharing Corporate Information.
6. Appendix III to OMB Circular No. A-130 - Security of Federal Automated Information Resources.
7. Clinger-Cohen Act, formerly known as the Information Technology Management Reform Act of 1996, Division E of P.L. 104-106, National Defense Authorization Act for Fiscal Year 1996. (Summary).
8. DOI ITM Bulletin No. 2001-001, Policy Use of "Persistent Cookies" on Interior Web Sites.
9. DOI ITM Bulletin No. 2000-004, Interim Guidance on Children's Privacy Statements on Web Sites.  The url included in this bulletin is out of date.  The correct url is http://www.ftc.gov/bcp/conline/edcams/kidzprivacy/kidz.htm.
10. DOI Privacy Policy.
11. Electronic and Information Technology Accessibility Standards.  (Summary).
12. Fish and Wildlife Service Strategic Plan, 2000 - 2005.
13. Government Performance and Results Act of 1993.
14. Management of Federal Information Resources.  Office of Management and Budget (OMB) Circular A-130, November 28, 2000.
15. Risk Assessment.
16. Section 508 of the Rehabilitation Act.

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.

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.

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.

SITA defines several file exchange standards in terms of COTS software file formats.

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