U.S. Department of the Interior

 

 

Interior Enterprise Architecture

 

 

 

 

Chapter 2

Infrastructure Architecture

Version 2.0

 

 

 

 

image 002

 

 

 

October 15, 2003

 


 

 

Chapter 2.  Infrastructure Architecture



2.1              Introduction and Background

 

Within this TRM, Infrastructure incorporates Network, Directory and Collaborative Services. Together, they comprise the “invisible glue” that supports the Department’s framework for interacting with others; whether organizations (e.g., states, other agencies), people (e.g., employees, partners), or systems. With the proper “glue”, these services enable the Department to successfully carry out its various missions efficiently and effectively. Without proper “glue”, the framework becomes fragile and many of these necessary interactions may fail to occur (e.g., network down). The infrastructure needs to be strategically planned, strongly backed, and expertly managed.

 

For the Network Services, this means:

  • Utilizing standard communication protocols;
  • Sustaining and supporting high capacity and high performance communication;
  • Being scaleable, reliable, and extensible;
  • Providing a variety of advanced telecommunications functions;
  • Smoothly integrating with other private and public communication networks.

 

For the Directory Services, this means:

  • Incorporating robust identity management;
  • Enforcing strict access control;
  • Managing proper resource identification and location.

 

For the Collaborative Services, this means:

  • Delivering seamless workflow;
  • Using transparent communications (e.g., email, messaging);
  • Supporting flexible human interaction styles from the structured to the improvisational.

 

The focus of the Interior Enterprise Architecture is on providing guidance for information technology (IT) issues and initiatives that are Interior-wide or multi-bureau in scope. If used correctly, the Interior Enterprise Architecture will act as a catalyst for those looking to capitalize on its contents and better understand the full meaning of its guidance.  This understanding will permit IT personnel to better engage the non-IT organization in discussions around tradeoffs and priorities within the proper governance structure (e.g., Management Initiatives Team (MIT), Information Technology Management Council)). The Interior Enterprise Architecture is not intended to be the “last word” (e.g., some automated checklist for product selection).  It is intended to be one of the “first words” to assure that Interior’s mission priorities and its IT priorities remain closely aligned. 

 

Because Interior is incorporating the OMB’s Federal Enterprise Architecture (FEA) models, the technical guidance provided by the subject area experts within a domain spans both the Service Component Reference Model (SRM) as well as the Technical Reference Model (TRM). For the Infrastructure domain, the SRM elements are as follows:

 

Service Domain(s):    The Business Management Services Domain defines the set of capabilities that support the management of business functions and organizational activities that maintain continuity across the business and value chain participants. The Business Management Services domain represents those capabilities and services that are necessary for projects, programs and planning within a business operation to successfully be managed.

 

                                    The Support Services Domain defines the set of cross-functional capabilities that can be leveraged independent of Service Domain objective and / or mission.

 

Service Type(s):         Organizational Management – defines the set of capabilities that support both collaboration and communication within an organization.

 

Collaboration – defines the set of capabilities that allow for the concurrent, simultaneous communication and sharing of content, schedules, messages and ideas within an organization

 

                                    Communication - defines the set of capabilities that support the transmission of data, messages and information in multiple formats and protocols.

 

                                   

Component(s):            Workgroup / Groupware - defines the set of capabilities that support multiple users working on related tasks.

 

Network Management - defines the set of capabilities involved in monitoring and maintaining a communications network in order to diagnose problems, gather statistics and provide general usage.

 

                                    Email - defines the set of capabilities that support the transmission of memos and messages over a network.

 

Shared Calendaring – defines the set of capabilities that allow an entire team as well as individuals to view, add and modify each other’s schedules, meetings and activities.

 

Task Management – defines the set of capabilities that support a specific undertaking or function assigned to an employee.

 

Threaded Discussions – defines the set of capabilities that support the running log of remarks and opinions about a given topic or subject.

 

Audio Conferencing – defines the set of capabilities that support audio communications sessions among people who are geographically dispersed. 

 

Real Time / Chat – defines the set of capabilities that support the conferencing capability between two or more users on a local area network or the Internet.

 

Video Conferencing – defines the set of capabilities that support video communications sessions among people who are geographically dispersed.

 

Computer / Telephony Integration- defines the set of capabilities that support the connectivity between server hardware, software and telecommunications equipment into a single logical system.

 

image 004These SRM service elements are likewise supported by Interior’s IT (technical) infrastructure (e.g., servers, networks). Within this infrastructure are individual TRM components for which this domain team is providing guidance. The graphic below outlines those TRM elements for this domain that support the service needs of the SRM

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Additionally, it’s doubtful that a single domain chapter from the TRM can be used to address a substantive issue.  More realistically, a few architecture domains may need to be reviewed when addressing an important IT decision.  For example, if Interior was considering the creation of a new Interior-wide Call Center capability, then the TRM chapters like Platforms, Information Security, and Distributed Systems Management might all need to be reviewed along with this chapter on Infrastructure.

 

2.2              Architectural Principles

 

The principles listed below provide guidance for the design and selection of technology components that will support the Infrastructure technology needs of Interior-wide IT initiatives.

 

Principle 1:  The Network is an Interior asset

 

The Network is a valued asset of Interior and must be managed. 

 

Rationale:

  • Information must be shared to maximize effective decision-making and the network is the transport for sharing.

 

Implications:

1.      Valuation of the network asset needs to be addressed (e.g., replacement costs, maintenance costs, equitable charge back).

2.      As with any asset it requires regular depreciation/ replacement costs and understanding by the management and user communities.

3.      Network impact must be included early in applications planning process (e.g., Interior Department Electronic Acquisition System (IDEAS), MAXIMO).

4.      Network capacity planning tools will be needed and used across Interior.

5.      Need for periodic review with users to assure network is aligned with business directions.

6.      Need for improved cross-bureau network coordination (e.g., Interior Network Council).

7.      Need to develop a model to understand impacts of network “outages” to customer service levels.

8.      Continuity of Operations Planning (COOP) needs to include impacts on Interior’s network resources.

 

 

Principle 2:    Integration/ Interoperability

 

Systems must be designed, acquired, developed, or enhanced such that data and processes can be effectively shared, for appropriate purposes, across Interior and with our partners.

 

Rationale:

·        Increased efficiency will better serve our customers (e.g., the public, employees, etc.).

 

·        Inter-departmental exchange of information requires network interoperability.

 

Implications:

  1. Use of common protocols will be necessary
  2. Need for Interior-wide working group to provide guidelines on interoperability
  3. Need for recognition that interoperability and security may be impossible between vendor products that adhere to “standards for interoperability” (e.g., if using VPN’s directly from firewalls, the current major firewall vendors don’t interoperate although both ostensibly support interoperability.)

 

 

Principle 3:     Ensure Security, Confidentiality and Privacy

 

Network systems must be designed and implemented in accordance with security and privacy legislation & policies to assure information confidentiality, integrity and availability.

 

Rationale:

  • Helps safeguard confidential and proprietary information.

 

  • Enhances public trust.

 

  • Enhances the proper stewardship over information.

 

  • Enhances the integrity of the information.

 

  • Complies with the Computer Security Act, the Privacy Act of 1974, and Office of Management and Budget (OMB) Circular A-130 “Management of Federal Information Resources.”

 

Implications:

  1. Network security needs to be integrated with security programs.
  2. Network security is a major part of the network management service and needs to be “resourced’ appropriately.
  3. Network security has major impact on network operations and increases the complexity of troubleshooting (e.g., tracing, Internet Control Message Protocol (ICMP)).
  4. Network security must be “baked in and not painted on.”
  5. Need for recognition that interoperability and security may be impossible between vendor products that adhere to “standards for interoperability” (e.g., if using virtual private networks (VPN) directly from firewalls, the current major firewall vendors don’t interoperate although both ostensibly support interoperability).

 

 

Principle 4: Continuity of Operations Planning

 

An assessment of business continuation and recovery requirements is mandatory when acquiring, developing, enhancing or outsourcing systems. Based on that assessment, appropriate disaster recovery and business continuity planning, design, testing and maintenance will take place.

 

Rationale:

·        Customers and partners have heightened awareness of the need for systems availability. 

 

·        Any significant visible loss of system availability and stability could negatively impact our mission and legal responsibilities.

 

·        Application systems and data are valuable organization assets that must be protected.

 

Implications:

1.      Operation and systems plans will need to be categorized according to business recovery needs (e.g., short term essential and long term essential).

2.      Systems should be designed with appropriate level of fault tolerance and recovery in mind.

3.      Plans for work site recovery will need to be in place.

4.      Life cycle and other costs will increase.

5.      Continuity of Operations Planning (COOP)/ Continuity of Business Operations (COBO) will require periodic testing and revision.

 

 

Principle 5:    Basic Services

 

A basic set of information services will be provided to all employees.

 

Rationale:

·        Consistent IT capability provides the basis for larger business initiatives and greater access to information.

 

·        Potentially reduces total cost (TCO) of ownership.

 

·        Provides basis for improved communication.

Implications:

1.      Basic network connectivity for voice, internet, etc. needs definition (e.g., least common denominator).

2.      Network bandwidth will increase significantly as set of “basics” increases.

3.      Support requirements for basic services will increase (e.g., “I can’t get to the internet, why?”- help desk).

4.      For places where basic services cannot be provided, alternate processes/ methods need to be created (e.g., wildlife refuge 300 baud connection).

5.      Need clarification of who will pay and how for increasing basic services (e.g., new voicemail).

6.      May increase initial costs for deploying personnel.

7.      More training will need to be provided to the entire organization for any addition to or modification of the basic services.

8.      May require 24x7 operation and associated personnel availability and costs.

 

 

Principle 6: Interior-wide interoperable network

 

We must continue to implement an Interior-wide “interoperable network”; performing as if it were a virtual, Interior-wide Network.

 

Rationale:

·        Networks are the essential enabling technology for client/server, Internet, and collaborative computing (e.g., emails, file transfers, secure teleconferencing, workflow). An interoperable network enables the organization to more easily reach out to customers and suppliers.

 

·        E-government users (e.g., public, employees, partners, suppliers) have increasing need for access to information across Interior; this access must appear seamless.

 

·        Lack of robust network architecture will impact the success of distributed applications.

 

Implications:

1.      Coordination across Bureau boundaries for network control will be significant (e.g., DOINet routers were not under bureau control).

2.      Resources to support a “virtual” network will be in addition to current Bureaus network support.

3.      Network will need to be scalable (e.g., unlike DOINet).

4.      Need to determine appropriate service levels for participants and have capability for variable service levels.

5.      Coordination mechanisms for network security will need to be created (e.g., policies, procedures, processes).

6.      Operational sharing of information will increase the complexity of network management (e.g., router down in another bureau’s sub-network which is not seen at point of customer contact).

7.      Need to increase the coordination among the operations groups (Network Operations Centers (NOC)) (e.g., published and available contact points).