United States Department of Agriculture (USDA) eGovernment Program
Technical Architecture
December 2002
Technological Profile –eDeployment Technical Architecture
Table of Contents
Revision History iii
Previous Change History iii
Document Sign-off iii
1 Introduction 1
1.1 The Enabler Technology Vision 3
1.2 Approach to Define the Technical Architecture 5
2 Current Capabilities 6
2.1 Overview 6
2.2 Applications 6
2.3 Network 11
2.4 Facilities and Operations 11
2.4.1 NITC 11
2.4.2 Service Centers 16
2.4.3 Human Resources 17
3 Proposed Architecture 19
3.1 Overview 19
3.2 Architecture Drivers 19
3.3 Logical Architecture 23
3.3.1 Conceptual Model 23
3.3.2 Use Cases 30
3.3.3 Logical Architecture 34
3.4 Physical Architecture 43
3.4.1 Execution Architecture 43
3.4.2 Development Architecture 48
3.4.3 Operations Architecture 51
3.4.4 Legacy System Integration 53
3.4.5 Security 55
3.5 Performance Measures 55
4 Agency rollout 57
4.1 Subscriber Agencies 57
4.2 Hosting Agencies 57
5 Impact Analysis 59
5.1 Organizational Impacts 59
5.2 Impact of Enterprise Architecture 59
5.3 Impact of eGovernment 59
5.4 Impact of Cyber Security Architecture 59
5.5 Impact of Universal Telecommunications Network (UTN) Initiative 60
5.6 Impact of Information Collection Process 62
5.7 Impact of CPIC Processes 62
5.8 Impact of Service Center Modernization Initiative 64
6 Risk Mitigation 65
7 Next Steps 72
Revision History iii
Previous Change History iii
Document Sign-off iii
1 Introduction 1
1.1 The Enabler Technology Vision 3
1.2 Approach to Define the Technical Architecture 5
2 Current Capabilities 6
2.1 Overview 6
2.2 Applications 6
2.3 Network 11
2.4 Facilities and Operations 11
2.4.1 NITC 11
2.4.2 Service Centers 16
2.4.3 Human Resources 17
3 Proposed Architecture 19
3.1 Overview 19
3.2 Architecture Drivers 19
3.3 Logical Architecture 23
3.3.1 Conceptual Model 23
3.3.2 Use Cases 30
3.3.3 Logical Architecture 34
3.4 Physical Architecture 43
3.4.1 Execution Architecture 43
3.4.2 Development Architecture 48
3.4.3 Operations Architecture 51
3.4.4 Legacy System Integration 53
3.4.5 Security 55
3.5 Performance Measures 55
4 Agency rollout 57
4.1 Subscriber Agencies 57
4.2 Hosting Agencies 57
5 Impact Analysis 59
5.1 Organizational Impacts 59
5.2 Impact of Enterprise Architecture 59
5.3 Impact of eGovernment 59
5.4 Impact of Cyber Security Architecture 59
5.5 Impact of Universal Telecommunications Network (UTN) Initiative 60
5.6 Impact of Information Collection Process 62
5.7 Impact of CPIC Processes 62
5.8 Impact of Service Center Modernization Initiative 64
6 Risk Mitigation 65
7 Next Steps 72
Revision History iii
Previous Change History iii
Document Sign-off iii
1 Introduction 1
1.1 The Enabler Technology Vision 3
1.2 Approach to Define the Technical Architecture 5
2 Current Capabilities 6
2.1 Overview 6
2.2 Applications 6
2.3 Network 12
2.4 Facilities and Operations 12
2.4.1 NITC 12
2.4.2 Service Centers 17
2.4.3 Human Resources 18
3 Proposed Architecture 20
3.1 Overview 20
3.2 Architecture Drivers 20
3.3 Logical Architecture 24
3.3.1 Conceptual Model 24
3.3.2 Use Cases 31
3.3.3 Logical Architecture 35
3.4 Physical Architecture 44
3.4.1 Execution Architecture 44
3.4.2 Development Architecture 49
3.4.3 Operations Architecture 51
3.4.4 Legacy System Integration 53
3.4.5 Security 55
3.5 Performance Measures 55
4 Agency Roll-out 57
4.1 Subscriber Agencies 57
4.2 Hosting Agencies 57
5 Impact Analysis 59
5.1 Organizational Impacts 59
5.2 Impact of Enterprise Architecture and its initiatives 59
5.2.1 Impact of Enterprise Architecture 59
5.2.2 Impact of eGovernment 59
5.2.3 Impact of Cyber Security Architecture 60
5.2.4 Impact of Universal Telecommunications Network (UTN) Initiative 61
5.2.5 Impact of Information Collection Process 62
5.2.6 Impact of CPIC Processes 63
5.2.7 Impact of Service Center Modernization Initiative 65
6 Risk Mitigation 65
7 Next Steps 73
Revision History
Previous Change History
Table a – Previous Change History
Version / Date / Author / Comment10 / 12/05/2002 / Amanuel Kiros / Update Draft
11 / 12/06/2002 / Richard L. Sun / Final Update before Initial Posting
12 / 12/20/2002 / Liesl M. Awalt / Updated formatting
Document Sign-off
Table b – Document Sign-off
Date / Name / TitleUSDA eGovernment Program iii
Technical_Architecture_v12.docTechnical_Architecture_v11.1.docTechnical_Architecture_v11.doc
Technological Profile –eDeployment Technical Architecture
1 Introduction
USDA developed an eGovernment Strategic Plan to establish a comprehensive vision and direction for the DepartmentUSDA and its agencies for electronic commerce for thein fiscal years (FY 2002- through 2006). The Plan strategy was developed to:
· Break down organizational silos by taking a “citizen-centered” view of program and service delivery;,
· Avoid redundant approaches and save money by leveraging resources — and seeking opportunities to collaborate across USDA agencies, throughout the enterprise, and with other Federal departments; (including Presidential Initiatives under the auspices of the Office of Management and Budget (OMB),
· Prioritize opportunities and devote resources to those initiatives with the largest impact, ; and
· Create a sense of ownership and a shared vision for the Department as a means to foster cultural change.
To realize the goals set forth in the Strategystrategy, USDA has undertaken several Departmententerprise-wide initiatives. These include “strategic” initiatives intended to improve the delivery of USDA programs and services, and “enabling” initiatives that provide the underpinning people, technology, processes, and standards to support these strategic initiatives. Among the enabling initiatives are a suite of technology services and standards called “eDeployment.” eDeployment gives USDA and its respective agencies the ability to create net-centric applications that enhance program and service delivery according to the goals defined in the eGovernment strategy. Specifically, eDeployment makes possible the following:
· A consistent and easy to use interface for all online applications;,
· The discoverycreation, sharing, and management of online content, documents, records, and other electronic media;,
· The consolidation and sharing of data;,
· The ability to Accessing access information and services by area of interest versus USDA’s organizational structure;,
· The ability to leverage existing technology investments, ; and
· Adherence to legislative mandates and participation in the Presidential Initiatives.
The purpose of this document is to outline the Technologyical Architecture for the implementation of the enabler initiatives. The enabler initiatives identified initiatives include address:
· Web Content Management,;
· Document/Record Management,;
· Data Management,;
· Portal, Services;
· Web Presence,;
· eLearning,; and
· eAuthentication.
Please note that Aalthough strategic initiatives (such as eLoans and eGrants) will be touched upon in context of how they fit into the enabler architecture, they will not be addressed in detail in this document.
It is also important to mention that Please note that this is a business case phase document is preliminary to. It should be expected that through out the vendor selection, design, and development phases of the enabler initiatives. , cContents of this document may change and evolve in response to additional information, design decisions, vendor product limitation, implementation events and user requirements.
1.1 The Enabler Technology Vision
The enabler initiatives focus on addressing common needs across the Department. Once delivered, the enabler initiatives will make availableprovide a suite of capabilities that can be leveraged by agency/cross-agency applications and business processes which would have otherwise been developed separately by agencies separately. By using components from the enabler framework, agencies can deploy better quality applications quicker and cheaper at a lower cost while fulfilling the USDA goal of maximizing onleveraging IT investments.
Figure 11
Figure 11
Figure 11 presents a simplified representation of the enablers’ vision.
Figure 11: eGovernment Enablers
The left portion of
Figure 11Figure 11
Figure 11 depicts the current state of affairssituation. It illustrates duplication of capabilities across Agency 1 and Agency 2 to address a common technology need. The right side demonstrates a scenario where the enabler initiatives would facilitate the sharing of components, eliminating redundancies. Please note that the term “component” refers to any application, group of applications or module of code that is either built custom or uses off-the-shelf software. The specifics of the scenario are as follows:
Current Scenario:
· Agency 1 builds a system that contains components A and B, which are not specific to the business process of the Agency. An example would be a capability that allows the management of files within a given application. This capability is generic and is not specific to any business process.
· Agency 1 also builds and integrates Agency-specific component x with components A and B to deliver a complete system that addresses a business need.
· Agency 2 faces a different business problem and builds a system to address its respective business need. However to deliver a solution, Agency 2 has to build components that are not unique to Agency 2’s business.
· In addition, Agency 2 builds business specific component y and integrates it with A and B to deliver a complete solution.
Future Scenario:
· In the future scenario, since components A and B are common across multiple agencies, they are offered as eGovernment enablers.
· Agency 1 would leverage enabler components A and B and integrate them with the business specific component x to address a unique business problem.
· Agency 2 would also leverage component B and integrate it with y to address its respective, unique business need.
· As the eGovernment program matures and more common technology needs are identified, more and more components could be made available to be used cross agencythe enterprise. In the diagram, components D and E represent future capabilities to be made available to the agencies.
Besides the cost savings and speed to deployment that is evident through sharing of components, as illustrated in the above scenario, common services also promote a more fluid sharing of data and applications across agencies. This will heighten customer and partneruser experience by allowing the delivery of comprehensive, relevant and timely information and services while enhancing employee productivity.
It is critical to stress that the eGovernment enabler effortinitiatives recognizes that services offered by an agency and the business processes that support those services are greatly varied. The effort does not envision building a one-size-fits-all solution but rather focuses on addressing common, fundamental needs across the Department. An agency would build its business specific end-to-end solution using the core capabilities made available by the enablers.
1.2 Approach to Define the Technical Architecture
In defining a technical architecture for the enablers, a process was followed to ensure that the architecture suits the functional needs of the department as well as fit in the current USDA technology environment. The key steps in the process are listed below. Steps one through four have already been performed as part of the select level business case.
- AssessDefine functional requirements
2. Identify technical requirements
3. Assess current capabilities
4. Create logical architecture
5. Perform vendor selection (software, hardware, application platform, etc.)
6. Outline architecture guiding principles
7. Create physical architecture
8. Continual modification of architecture
Working groups comprised of representatives from each multiple agency agencies collectively identified functional requirements for the shared enabler servicesinitiatives. Through meetings and deliverable reviews, the working group members refined the list of requirements that will ensure that their respective agency needs are addressed by the proposed enabler capabilities. These functional requirements served as the most critical input to the development of the enabler technical architecture. The architecture effort will design a system to address these functional requirements. In addition to functional requirements, technical requirements were identified to ensure that components of the architecture are fulfilling the functional requirements in “the right way”. Technical requirements pertain to the inner-workings of a solution to ensure ease of integration, optimal performance, adherence to industry standards etc, and synergy with the overall USDA technological direction.
Another activity performed in formulating the enabler technical architecture is an assessment of current capabilities within USDA. This activity helps identify assets within USDA that can be leveraged in the implementation of the enablers. The enabler architecture team researched existing agency applications in the areas that pertain to the enablers as well as assessed USDA hosting facilities that may be used to house the solutions. Based on the results of steps 1 through 43, a logical technical architecture was created. The logical architecture represents the key components of the architecture and how they interact with one another.
2 Current Capabilities
2.1 Overview
In designing a new solution, it is necessary to assess the current environment that the solution will be deployed to. The makeup of the existing technology will drive the design of the solution as well as help identify technology components that can be leveraged. Some due diligence was performed as part of the select phase business case effort to evaluate the current capabilities of at USDA. This exercise focused on existing applications, hosting facilities, and skill sets within USDA in the areas that the enabler initiatives seek to address. The results of this assessment were used to shape elements of this document such as execution architecture and hosting facilities.
2.2 Applications
Currently, USDA Agencies are individually addressing the areas of Web Content Management, Document/Records ManagementDocument Management, Portal Services, Web Presence, Data Management, eLearning and Authentication. Agency solutions range from manual processes to custom and third party software. Table 2a provides an inventory of some of the key existing applications in the relevant areas. Although these different applications may be effective in addressing their respective agency’s business needs, they are not shared assets across the Department. Table 22Table 22 provides an inventory of some of the key existing applications in the relevant areas.
(Please note that the intent of the list is to provide a sample of some of the major efforts and does not serve as a comprehensive listing of all applications within the Department.)
A few of the applications that are currently in place are:
§ FileNet – Document Management