U.S. Department of State
Other State Department Archive SitesU.S. Department of State
U.S. Department of State
U.S. Department of State
U.S. Department of State
U.S. Department of State
The State Department web site below is a permanent electronic archive of information released online from January 1, 1997 to January 20, 2001. Please see www.state.gov for current material from the Department of State. Or visit http://2001-2009.state.gov for information from that period. Archive sites are not updated, so external links may no longer function. Contact us with any questions about finding information. NOTE: External links to other Internet sites should not be construed as an endorsement of the views contained therein.
U.S. Department of State

United States Department of State
Information Technology Architecture
State Dept. Logo
Volume One

April 16, 1999
Version 2.2

Table of Contents

Message from the CIO


ES-1.1 ITA Structure *
ES-1.2 Benefits of the Department's ITA *
ES-1.3 Target Technical Architecture *
ES-1.4 Technical Reference Model and Standards Profile *
ES-1.5 Summary/Conclusion *
ES-1.6 Next Steps *
1.1 What is an Architecture? *
1.2 Why Have an Architecture? *
1.3 Benefits of the ITA *
1.4 Architecture Management and Development Process *
3.1 Architecture Layers *
3.2 Technical Reference Model and Standards Profile *
3.3 ITA Integration *
4.1 ITA Support for Strategic Department IT Goals *
4.2 Guiding Principles *
4.3 Functional Model of Target ITA *
5.1 Business Architecture Layer *
5.2 Department Mission and Priorities *
5.3 Business Drivers *
5.4 Common Business and Information Flows *
5.5 Technical Architectural Layers *
5.5.1 Overview of Target Technical Architecture *
5.5.2 Technical Reference Model *
5.5.3 Information Architecture Layer *
5.5.4 Description *
5.5.5 Applications Architecture Layer *
5.5.6 Description *
5.5.7 Infrastructure Architecture Layer *
5.5.8 Description *
5.5.9 Hardware Platforms *
5.5.10 Infrastructure Services *
6.1 Users' View *
6.2 Executives' View *
6.3 System Managers' View *
7.1 Review Process *
7.2 Detailing of the Architectural Layers *
7.3 Development of Key Segment Architectures *
Annex A, Glossary A-*
Annex B, Current Issue Paper Candidates B-*
Annex C, Architecture Segments C-*

Table of Figures

Figure 1, Relationships between the ITA and Other Department Processes *
Figure 2, The Baseline -- Islands of Automation *
Figure 3, Modest Improvement in IT Integration *
Figure 4, ITA Structure *
Figure 5, Example of Relationships among ITA Segments and Layers *
Table 1, IT Goals Linked to Representative Architectural Features *
Table 2, Guiding Principles *
Figure 6, Functional View of Target Architecture *
Figure 7, Department of State Business Processes *
Figure 8, Business and Information Flows -- Transactional *
Figure 9, Business and Information Flows -- Collaborative *
Figure 10, Target Environment -- Emphasizing Commonality *
Figure 11, Overview of Target Technical Architecture *
Figure 12, Technical Reference Model *
Figure 13, Overview of the Information Architecture Layer *
Figure 14, Structure of the Information Architecture Layer *
Figure 15, Structure of the Applications Architecture Layer *
Figure 16, Conceptual View of the Infrastructure Architecture Layer *
Figure 17, Infrastructure Components *

The Department of State is modernizing its Information Technology (IT) infrastructure to support changing business needs and to take advantage of new technologies. In pursuit of this goal, the IRM Bureau has developed a high-level Information Technology Architecture (ITA) to guide the acquisition, development, and implementation of information technology, both domestically and at posts. The ITA is intended to be an evolutionary process, as standards and architecture specifications adapt to changing requirements, technology, and input from Department bureaus.

An ITA is a guiding strategy or framework. As in constructing a building, the architecture is the bridge between the customer's requirements and the technical design that will effectively satisfy those requirements. The Department's ITA provides guiding principles and standards to be applied when designing and implementing information services and specific systems for Department users. The ITA also specifies the major components of the technology infrastructure that need to be built to support the business requirements.

ES-1.1 ITA Structure

As we have conceptualized it for the State Department, the ITA consists of four layers as well as several crosscutting issue areas. It is structured to provide a clear specification of a target information technology environment that will meet future IRM goals and requirements. Over the next year, the architecture standards profile will be expanded to further assist system managers and users to make the appropriate technology decisions necessary to achieve the target environment. The architecture describes at a high level the IT infrastructure that underlies the future vision of the Department's information systems and is linked explicitly to the Department's recently adopted paper that presented IRM's strategic vision and five IT goals for the new millennium.

Figure ES-1 shows the structure of the ITA.

Architecture Segments

Figure ES-1, ITA Structure

The ITA is structured to provide a framework for linking technical solutions to Department of State business requirements in two ways. First, business requirements drive technology through top-down planning and analysis. Second, bottom-up analysis identifies emerging technologies that can further business goals and objectives.

The ITA contains the following architecture layers:

Additionally, architecture segments, such as Security, Enterprise Network Management, Information Exchange, and many others as needed, will be developed to address high priority, dynamic technology issues that are vital to Department of State requirements. The architectural segments will address such items as the requirements to protect Department information and system assets (Security), enable network fault management, improved IT configuration management, asset tool procurement, (Enterprise Network Management), and replace existing cable and email systems (Information Exchange). Additional segments will be added as new requirements are identified and analyzed.

ES-1.2 Benefits of the Department's ITA

The Department's information management environment that is based on this ITA will have considerable benefits. For instance, it will promote:

Figure ES-2 shows a key benefit of the Department's ITA. As seen on the left, the Department's information systems have been characterized as islands of automation -- that is, historically fragmented, inconsistent, and duplicative, and not supportive of information integration and sharing. The target environment, shown on the right, is characterized by consistent use of common components, greater integration, and interoperability. This environment promotes maximum value of the Department's information assets, and provides end-users around the world with ready access to the information they need. It will help contain escalating IT costs by encouraging standardization and re-use, and by minimizing the training and support burdens. The ALMA effort has already provided the Department with a positive step towards achieving the target architecture by providing standards, common hardware and software systems, communications capacity, and a network management system for posts.

Islands of AutomationIslands of Automation

Figure ES-2, Contrast of Current and Target Environment

ES-1.3 Target Technical Architecture

The Department's target technical architecture, as seen on the right of Figure ES-2, emphasizes commonality, interoperability, and a significant reduction in the prevalence of stovepipe solutions in favor of an integrated suite of business applications sharing a common data environment. This target will be accomplished through the adoption and implementation of ITA guiding principles and standards that guide technology decisions and IT procurements.

Figure ES-3, below, is a high level representation of the Department's architecture. Following this architecture, the Department plans to establish a robust, reliable, and maintainable IT environment that supports the interconnected diplomacy of the 21st century -- that is e-Diplomacy. The ITA specifies the following key features that will facilitate the creation of this environment:

Target Architecture

Figure ES-3, Target Architecture

ES-1.4 Technical Reference Model and Standards Profile

The Technical Reference Model (TRM) serves as the bridge between what is described in the technical architectural layers and the specific IT Department guidance that will appear in the Standards Profile. These two ITA documents link the Department's business requirements to the specific products and standards that will guide all systems acquisition and development efforts.

ES-1.5 Summary/Conclusion

Two key trends affect the future strategy for IT use in the Department: (1) The globalization of accurate, timely, and usable information, enabled by the worldwide availability of modern commercial networks; and (2) The decentralization of computer resources, as reflected in the pervasiveness of the personal computer and the networks that interconnect them. These two trends create a unique challenge for the Department, to manage resources in ways that support the mission and business needs of the Department's end users, which gives rise to an urgent need for this enterprise-wide ITA. We hope you agree and participate and support its adoption and implementation.

ES-1.6 Next Steps

This ITA has been circulated throughout the Department for review and comment. The IRM Bureau continually needs broad input to ensure that the standards specified in the ITA provide clear and adequate guidance to Bureau system managers. To be effective the ITA must reflect the Department's current and projected business requirements. Following an iterative process of obtaining input and refining the ITA, IRM will produce refined versions of this material, develop architectural segments, and add detail to the business and technical architecture layers. The Department's ITA is modeled upon a framework adopted by the Federal CIO Council. This framework is pragmatic and suggests that all Federal agencies focus their architectural efforts on issues of most importance to their specific situations -- that is, concentrate on key issues rather than try to achieve consistent detail in all areas. IRM has adopted this approach in the pages that follow.


  2. The Department of State is pursuing the modernization of its Information Technology (IT) infrastructure to improve the technical support it provides to overseas posts and domestic mission and administrative operations while taking advantage of new information technologies.

    Two key trends affect the future strategy of IT use at the Department: (1) the globalization of accurate, timely, and usable information, enabled by worldwide availability of modern commercial networks; and (2) the decentralization of computer resources, as reflected in the pervasiveness of the personal computer and networks that interconnect them. These two trends create a challenge for the Department in managing decentralized resources in a way that supports the global access needed to support the mission and business needs of end users. This challenge gives rise to an urgent need for an enterprise-wide Information Technology Architecture (ITA).

    1. What is an Architecture?

    2. An architecture is a guiding strategy or framework. As in a building project, the architecture represents the bridge between the customer's requirements and the technical design that will effectively satisfy those requirements. It is not a detailed blueprint or wiring diagram, understandable only to technicians, but rather more like the city planning codes, zoning laws, and high level plans that constrain the design, and enable the objective to be realized. The Department's ITA provides guiding principles and standards to be applied when designing and implementing information services for Department users. The ITA also specifies the major components of the technology infrastructure to be built to support business requirements.
    3. Why Have an Architecture?

    4. An architecture is a prudent management tool that will help ensure that IT is responsive to Department business requirements. It will help the Department achieve technology goals and objectives cost-effectively by providing the basis for Department-wide coordination of IT activities, and a set of standards and common technical services that will foster interoperability and information sharing, while lowering total cost of ownership. In particular, the architecture will promote such benefits as broad access to information, efficient re-use of IT components and solutions, and effective global management of IT support. In addition, Federal law mandates an ITA for the above reasons in the Information Technology Management Reform Act of 1996 also known as the Clinger-Cohen Act.

      The Department of State's ITA adapts the architectural model endorsed by the CIO Council as described in the document, "Federal Enterprise Architecture Conceptual Framework," dated August 1998.

      The ITA has also been influenced by examples cited by OMB and the Gartner Group. Gartner defines an Architecture as a ". . .framework and a set of principles, guidelines or rules to direct the process of acquiring, building, modifying, and interfacing IT resources throughout the Enterprise. These resources can include equipment, software, communications protocols, application development methodologies, database systems, modeling tools, IT governmental organizational structures and more." This definition is in keeping with the guidance presented in the 25 Oct 1996 OMB Raines memorandum "Funding Information Systems Investments."
    5. Benefits of the ITA

A system and information management environment based on this ITA will have considerable benefits for the Department. It will promote the following:

    1. Architecture Management and Development Process

Over the past few years, the Department has put a series of planning and management processes in place to govern IT investments. These efforts have been successful in putting the current modernization program on track, and have produced significant results, such as the worldwide deployment of the ALMA-based infrastructure.

The IRM Office of Architecture and Planning (IRM/APR/IAP/AE), working with senior management and Bureau representatives, will establish and document a set of interrelated processes for planning and managing development projects to ensure conformance with the ITA. The overall systems life-cycle portion of this process is illustrated by Figure 1, Relationships between the ITA and Other Department Processes, which includes the following key elements:

ITA and Other Department Processes

Figure 1, Relationships between the ITA and Other Department Processes

As shown in the figure, the ITA is tightly integrated with the Department's planning, engineering, design, and development processes. Strategic goals and plans specify what the Department intends to accomplish in IT and how those accomplishments will support business and mission operations. These plans also identify IT-related issues that must be analyzed and resolved in the course of developing and maintaining the ITA. Since the ITA is an "evolving description of an approach to achieving a desired mission," as defined by the GAO, it is necessary to guide the evolution of that description in a structured, predictable way. The exploration of topics that will result in updates to the architecture is maintained in a separate series of documents -- issue papers or "white papers" -- only a few of which may be active at any time. The topics that influence the architecture derive from the major system drivers -- mission or requirements changes that must be addressed and technology opportunities that may be exploited.

The following issues illustrate the types of architectural issues to be addressed:

The issues to be addressed will result in decision support papers to be presented to appropriate levels of management for action. When a decision has been made, the ITA will be adjusted appropriately.

The ITA is the foundation on which IT solutions of the future will be designed, developed, and deployed within the Department. A key element in the Department's modernization program is establishing a modern, flexible, "open" platform or infrastructure to support all requirements. This will be done through platform engineering, which refers to the development of a common infrastructure for all applications in the Department. The platform is the stable, cross-project base of both infrastructure hardware and software provided to (and evolved for) all projects in the Department. Note that this contrasts with some commonly held definitions that consider "platform" to include only the hardware base.

Engineering leads into design, implementation, deployment, and operations. These activities are the responsibility of operational units in IRM (for infrastructure components) and the bureaus (for business applications). Guided by the Department's strategic plan, IRM plans, and ITA, these activities will promote a rational and integrated IT environment that responds to Department goals and priorities.

The processes for maintaining the ITA and for ensuring conformance will be documented in a separate IAP document that describes the roles of the Architecture and Planning Divisions, the capital planning boards, and other organizations. The general approach is for all projects to be reviewed for compliance with the ITA prior to submission to the IRM Program Board for approval and funding. Deviations from the ITA must be addressed by the project manager to the CIO. This review process will explore necessary changes to project plans as well as needed revisions to the ITA. The ITA will also be reviewed on a regular basis to ensure that it remains current with Department direction and priorities and with technology trends of industry and other agencies.


Analysis of the Department's information technology baseline has identified several key issues that can be addressed by this ITA. These issues are discussed in this chapter.

IRM activities in the Department have historically been carried out on a decentralized basis and without the benefit of continuing centralized management attention. As a result, many development efforts have not been fully synchronized and the systems produced have not been fully interoperable. Figure 2, The Baseline -- Islands of Automation, presents a conceptual view of the past environment.

The current infrastructure, databases, and application systems have not been driven by an enterprise-wide architecture, and exhibit lack of commonality, interoperability, or portability, as one would expect. Such systems are described as "islands of automation" and "stovepiped" -- two metaphors that refer to their fragmentation and independence both in lack of commonality and in interoperability. The structure of the software that runs on the hardware platform is not guided by any perceivable enterprise-wide guidance.

Islands of Automation

Figure 2, The Baseline -- Islands of Automation

Although the Department has made significant progress through the ALMA modernization efforts, the older environment remains plagued by components that are non-standard and not fully interoperable. As a result, end-users find it difficult to identify and locate information of interest, and collaborative processing is severely limited. Transaction processing systems use non-standard approaches and user interfaces, increasing the training and maintenance burdens for the Department. The following limitations characterize the current baseline environment:

As noted above, the Department has begun to move purposefully into a "common component" architecture, with the adoption of ALMA. Figure 3, Modest Improvement in IT Integration, shows this modest level of commonality being achieved by the Department's current initiatives, which reduces the isolation of the former "islands of automation" by providing the benefits of common components, and the adoption of the software layering described later in the reference model. The earliest effects of platform engineering are starting to emerge for the Department as the layers above hardware are intentionally managed across all systems, and standard software building blocks, based on the standards profile, are adopted for common use.

Improvement in IT Integration

Figure 3, Modest Improvement in IT Integration

In the overall migration of ITA-based systems, additional commonality can be attained, at least to the level of common infrastructure services. This may be the highest level at which enterprise-wide commonality can or should be achieved, although common support applications will find use in several-to-many projects, but probably not all.

A major goal of the ITA and follow-on platform engineering is to increase the commonality across information systems. The target architecture presented in the next section provides a conceptual view of an environment with high levels of commonality that can support broad information access and greatly reduce the fragmentation caused by islands of automation.


  2. The ITA is structured to provide a clear specification of a target environment that will meet Department of State goals and requirements. The architecture describes, at a high level, the IT environment that underlies the future vision of the Department's information systems.

Figure 4 shows the structure of the ITA.

Architecture Segments

Figure 4, ITA Structure

  1. Architecture Layers

The core of the ITA is the four architecture layers shown in Figure 4. These layers provide a framework for linking technical solutions to Department of State business requirements. The ITA supports both top-down and bottom-up planning and development of IT solutions. The top-down process links the business model directly to technical needs and solutions. Through bottom-up planning, the technical layers support identification of emerging technology trends and application of new technologies to mission needs.

As shown, the ITA contains the following architecture layers:

The following provides an example of how the ITA conceptual model can be applied to a familiar, mission critical business function carried out by the Department every business day.

A core Business of the State Department is the Non-Immigrant Visa Function, i.e. screening and providing proper documentation to aliens desiring temporary visitation to the United States. An objective of the Bureau of Consular Affairs is the speedy processing of legitimate travelers to facilitate travel to the U.S., but, as part of our Border Security function, to identify undesirables (including terrorists, drug traffickers, etc.) and refuse travel documentation to these undesirables.
Visa processing is an Information driven process. The key data required is the applicant record that is collected from the applicant at the time of Visa application. Also, the Department maintains a database of people who are considered undesirables and who, barring special circumstances, should be denied entry into the United States. The database is populated from not only the Department's records, but also from information gathered from intelligence sources, law enforcement agencies, and other external sources. All Visa applicants must be checked against this database prior to being issued a Visa.
CA has developed the Non-Immigrant Visa (NIV) software Application installed at all Visa issuing overseas posts. This software is a case tracking application that facilitates Visa processing by interfacing with the CLASS (Consular Lookout and Support System) database and other databases to help identify undesirables and, in so doing, enable Consular Officers to make informed decisions concerning Visa applications. Associated software applications provide long-term storage and retrieval of Visa records, and these applications also provide backup capabilities in the event that CLASS, which is accessed by long-distance telecommunication links, is unavailable.
The NIV application installed at posts is an open system, standards-based application that complies with ALMA data processing, desktop, and communication standards. In fact, installation of the ALMA Infrastructure at an overseas post is a prerequisite to using the NIV application. NIV connects to the Washington-based CLASS application through OpenNet. Thus, OpenNet infrastructure is a requirement for effective Visa processing.

The Visa issuance process, and many others like it, will continue to reap benefits through increased efficiency and sensible technology investments as specific ITA standards are articulated and implemented.

Architecture Segments -- The Department's ITA incorporates the concept of architecture segments, through which "hot topics" are addressed within the disciplined context and structure of the ITA. Not all architecture segments must be done at the same time or at the same level of detail. This allows "quicker returns" and early introduction of promising technologies. Figure 4 shows three initial segment architectures on the left side of the graphic. Additional segments will be identified as requirements become further refined.

    1. Technical Reference Model and Standards Profile

    2. The ITA also includes a Technical Reference Model (TRM) and Standards Profile. The TRM provides a linkage between the three technical layers and the set of standards contained in the Standards Profile. The TRM and active set of standards provide specific guidance to Bureau system managers and developers in the planning, acquisition, and implementation of IT solutions. In essence, they provide the most detailed and specific manifestation of the relationship between business requirements and technical standards.

      The TRM provides the organization for the Standards Profile. Within each TRM category, the Department indicates the standards it has adopted. These may be true industry-wide standards, which transcend proprietary product boundaries, or they may be "product standards" -- solutions that the Department has chosen where no industry-wide standard exists. The latter are less desirable because they limit long-term flexibility and potential interoperability.
    3. ITA Integration

The multiple components of the ITA are tightly interconnected, as illustrated in Figure 5, Example of Relationships among ITA Segments and Layers, which elaborates on the notion of segment architectures and illustrates areas in which segments overlap with the ITA layers. For example, the Security Segment focuses on delivering services such as encryption and user authentication, which can be used by systems across all architectural layers. While these services would be specified and developed within the Security Segment, their implementation is manifested in conjunction with specific infrastructure, applications, and information components.

Architecture Components Relationships

Figure 5, Example of Relationships among ITA Segments and Layers

    1. ITA Support for Strategic Department IT Goals

The target Information Technology Architecture supports the Department's vision for IT in the new millennium. This vision calls for a robust, global, and secure information technology infrastructure that will support the growing and evolving demands of diplomacy in the 21st century. The core of the vision is a set of five goals:

The key elements of the ITA are derived directly from these goals. The business and technical architecture layers and architecture segments enable deployment of IT solutions that support these goals. Table 1 links the five goals and a representative set of architectural elements, showing how technical components contained in the ITA support achievement of the goals. The features shown are illustrative, rather than comprehensive. As the architecture evolves based on bureau feedback, the set of key features will expand and evolve as well. This table demonstrates how the ITA helps infrastructure engineers and designers identify technical solutions that address Department goals and priorities.

Table 1, IT Goals Linked to Representative Architectural Features

IT Goal

Applicable Architectural Features

Secure Global Network

  • Robust, secure worldwide communications infrastructure
  • Commercial technology and protocols so network can evolve with requirements
  • VPN, PKI, satellite, Internet, and other technologies
  • Integration of all types of communications
  • Robust network security infrastructure

Suite of Foreign Policy Applications

  • Consolidated information centers - "super servers" for access to corporate information
  • Knowledge management tools for highly intelligent user profiling
  • Web-enabled applications for ease of use
  • Searchable, accessible, secure data warehouse

Information Exchange -- "Messaging Plus"

  • Business quality electronic exchange of messages and other information
  • Document and correspondence management products
  • Standards-based directory services
  • Security solutions for classified and unclassified information
  • "Thin client" enhances information security

Streamlined Operations

  • Consolidation and standardization will yield efficiencies
  • Intelligent applications will simplify and streamline much administrative processing
  • Web-based processing will reduce complexity, especially at post
  • Infrastructure management will be automated and simplified
  • The IT infrastructure will be simplified through thin clients, centralized services, and standardization

Trained, Productive Workforce

  • Centralization/regionalization will permit rational deployment of scarce personnel resources
  • Training will be enhanced through web-based technologies, distance learning, etc.
  • Simplified IT infrastructure management will reduce personnel burden
  • Global network may reduce need for on-site experts

    1. Guiding Principles

The ITA will guide and support technology related decision-making throughout the Department. Bureaus will be guided by the standards, and guiding principles, and general approach in planning and deploying their IT infrastructures and specific applications and databases. Plus, corporate planners and senior management decision-makers, such as the IRM Program Board, will use components of the ITA to guide their deliberations.

Table 2, Guiding Principles, presents a set of guiding principles that underlie the ITA and subsequent systems acquisition and development.

Table 2, Guiding Principles

Architecture Layer

Guiding Principles

All Layers -- Overarching Principles

  • Deploy and reuse modular components
  • Integrate security into all architectural elements, balancing accessibility and ease of use with protection of data
  • Strive for universal access to information
  • Limit complexity, especially at overseas posts.
  • Use off-the-shelf solutions where feasible
  • Focus on total cost of ownership and life cycle costs and benefits in planning and assessing IT solutions

Business Layer

  • Allow mission needs and priorities to drive IT investments
  • Standardize business processes to gain efficiencies and ease the training burden

Information Layer

  • Establish a corporate data model to enhance the value of the Department's information assets
  • Validate information once as close to its source as possible
  • Establish and use data warehouse(s) and corporate repositories
  • Minimize paper

Applications Layer

  • Seek to reuse components from the Department's standard application libraries before developing or acquiring new systems
  • Employ Independent Verification and Validation (IV&V) for all applications before production deployment
  • Use web and similar technology to promote information access and standard user interface
  • Use the Department's standard suite of desktop and office automation products

Infrastructure Layer

  • Establish a secure, integrated, reliable, high performance, global network
  • Provide all users with a common, standardized desktop
  • Migrate major assets such as servers into centralized facilities where they can be managed and secured cost-effectively
  • Provide a centrally managed Enterprise wide network infrastructure comprising LANs, MANs, and the WAN
  • Provide central facilities for help desk, network operations, security infrastructure, messaging, and other "core" services

    1. Functional Model of Target ITA

Figure 6, Functional View of Target Architecture, is a high level model of the target integrated architecture that provides a view of the functional capabilities the target architecture will support. As shown, the target will provide universal access to corporate information assets, and will also provide the security and technical infrastructure needed for internal and external connectivity. In short, the target positions the Department to meet its IT goals for the 21st century.

Target Architecture

Figure 6, Functional View of Target Architecture


  2. This section presents the two basic architectural divisions shown in the pyramid diagram presented as Figure 4, ITA Structure, above. The Business Architecture layer specifies the Department's major mission areas and business processes the Department performs. The business model leads directly to the establishment of a set of technical architecture layers, which consist of an Information layer, an Applications layer, and an Infrastructure layer.

    Together these three layers specify a technical environment driven by and supportive of the Business Architecture Layer. The Business Architecture Layer drives the establishment of a corporate data model that is at the heart of the Information layer; a set of robust tools and application interfaces specified in the Applications layer; and an Infrastructure layer that enables the global connectivity and security so vital to State's effectiveness.
    1. Business Architecture Layer

    2. The Business Architecture Layer is a description of the mission-related activities and management functions performed by the Department of State, as depicted in Figure 7, below. It is based on the International Affairs Strategic Plan, the Department of State Strategic Plan, and Bureau and Mission Performance Plans, which identify United States national interests, strategic goals, and priorities for Department activities and investments. The Department's Strategic Plan provides the context for the future use of IT, which must be focused on furthering diplomatic readiness and the Department's mission and strategic goals.
    3. Department Mission and Priorities

    4. The Department of State's mission, derived from the President's constitutional authority, is to formulate and conduct the foreign relations of the United States. Within this broad context, the Department's focus has broadened considerably in the post-cold war era. While much activity continues to stress traditional nation-to-nation diplomacy, increasing attention is devoted to multi-lateral relations and global issues, such as international law enforcement, the environment, population, and terrorism.

      Business Processes

      Figure 7, Department of State Business Processes
    5. Business Drivers

    6. The Department's mission and business environment is changing dramatically as we approach the new millennium. As documented in several recent studies, the key challenge is to provide an environment that supports the new multi-faceted diplomacy in an electronic age -- e-diplomacy. To be effective in the next century, our diplomats will require access at their fingertips to a wealth of information and effective tools to manipulate that information and share it with others. To keep up with the issues of the day, they will require Internet-like networks and intelligent automated agents that can help them find and organize critical information. They will need the ability to collaborate with counterparts in other agencies, foreign governments, non-governmental organizations, and the public. Their work will become increasingly more dependent on information and IT networks.
    7. Common Business and Information Flows

    8. All of the Department's business processes can be represented by one of two information flow models: transactional, as illustrated in Figure 8, Business and Information Flows -- Transactional, and collaborative, as depicted in Figure 9, Business and Information Flows -- Collaborative, below. Transactional flows tend to be structured and Collaborative flows tend to be relatively unstructured and unscheduled, often resulting in free-form reports, presentations, issue papers, policy statements, and similar products.

      The ITA's goal is to standardize common business processes and supporting technologies to the maximum extent possible. The ITA approach enables the Department to acquire and deploy common, general purpose "utilities" that can be used by any bureau or system manager to accomplish an identified business requirement.

      This approach is analogous to industry-wide efforts to use and re-use web-enabled applications, or applets. General-purpose components can be plugged in or linked together to form complete system solutions with minimal programming and maintenance. The Department will accomplish this through applets and larger utilities -- for example, workflow, image and document management, search and retrieval -- which support business information flows and requirements.

      Business and Information Flows

      Figure 8, Business and Information Flows -- Transactional

      Business and Information Flows

      Figure 9, Business and Information Flows -- Collaborative
    9. Technical Architectural Layers
      1. Overview of Target Technical Architecture

The Technical Architecture describes the Department's information systems from a technical perspective. The systems correspond to and are driven by the requirements articulated in the Business Layer Architecture.

In contrast to the baseline and current transitional environment described in Section 2, Figure 2, The Baseline -- Islands of Automation (page *), and Figure 3, Modest Improvement in IT Integration (page *), the target technical architecture emphasizes commonality, a consistent use of standards, interoperability, and significant reduction in the prevalence of stovepipe solutions. Figure 10, Target Environment -- Emphasizing Commonality, illustrates the desired end state.

Target Environment

Figure 10, Target Environment -- Emphasizing Commonality

Figure 11, Overview of Target Technical Architecture, provides a high level representation of information, applications, and infrastructure components supporting the target business architecture. This architecture is described in Section 5.1, Business Architecture Layer. The Department plans to establish a robust, reliable, and maintainable IT environment that provides the following key features:

Target Technical Architecture

Figure 11, Overview of Target Technical Architecture

"Secure Access to Information Assets from Around the World"

      1. Technical Reference Model

      2. The Technical Reference Model (TRM) serves as a bridge between the Technical Architectural Layers and the Standards Profile. Figure 12, Technical Reference Model, is a depiction of the Department's TRM.

        Technical Reference Model
        Figure 12, Technical Reference Model

        The purpose of the TRM is to show the categories of entities in each technical architectural layer. That is, it shows the basic structure of the Information Layer and how it interfaces with the Business Architecture Layer, represented by the arrows on top of the figure, which identifies the major categories of information requirements. The Applications Layer portion of the TRM shows the top-level categories of applications to be used, both mission/administrative applications and support applications. Either mission or administrative applications may use the support applications area. The support applications may also supply common services to application software built on top of them.

        The Infrastructure level of the Department's TRM shows both hardware and software components of the standardized system platforms. This includes all identified system services, broken out into ten categories that cover the full spectrum of platform services, including those not yet in the scope of the ITA, such as integrated voice and video. The hardware platforms themselves are shown as the lowest level, supporting the software levels above, typically through the operating system. These services are shown spanning the width of the diagram to suggest that they are typically the direct interface to hardware functionality.

        An additional feature of the TRM diagram is the "striping" between layers to indicate the standardization of interfaces across the enterprise. Thus, it is envisioned that a service level API will be established to invoke all system services in a consistent way. Managing this standardization and accepting or modifying existing software service interfaces are two of the ongoing architecture jobs over the system's life cycle.

        The manner in which the TRM is used as a bridge to the Standards Profile is that each box in the TRM diagram represents a category subject to standardization. These are the niches into which related standards are grouped. While not all areas will have the same number of standards -- some, in fact, may not exist -- they identify areas of potential standardization.

        Each level of the TRM can be accessed from whatever level above it that requires the services provided by that level. That is, this is not an "ISO-style" protocol diagram, where each layer may call only the layer immediately below it.
      3. Information Architecture Layer

The Information Architecture Layer is constructed to satisfy the requirements outlined in the Business Architecture Layer. That is, the organization and hierarchy of data in the information architecture standards and descriptions are determined by the mission structure. The business requirements' data flows drive the allocation, replication, and other characteristics of the databases defined for the enterprise. The Information Layer is a framework that contains the individual data models developed for each mission area, and also defines the interrelationships between those models. Thus, it can be used to standardize data for sharing across the entire Department. This layer also contains Department business rules based on process analysis and on the interaction of processes and data. Focusing on both data and process enables Department organizations to reengineer and streamline their operations and better align them with mission objectives and priorities. Finally, the Information Layer is a key driver in defining system and infrastructure requirements in the application and infrastructure layers.

Figure 13, below, is an overview of the Information Architecture Layer, which focuses on supporting the following business requirements:

One key element of this layer is the specification of a corporate or enterprise data model. The Department's decentralized environment increases the need for a corporate data model to promote information sharing and full exploitation of data as a critical resource. At the same time, the decentralization of State programs and systems imposes challenges for obtaining commitment to the development of an enterprise-wide data model. The IRM Data Administration Office has developed an initial EDM that is the foundation of the Data Administration program. This model is a continuous work in progress, evolving as Department programs and requirements change. An issue paper is contemplated to determine the best approach to the ongoing evolution and most effective application of the data model.

Each of the individual databases utilizes the Department's SDEs to ensure the ability to effectively share data across the enterprise. Each data steward is responsible for complying with the data standardization effort, to promote interoperability with other corporate databases and with the enterprise-wide data warehouse, which is created from the EDM.

Information Architecture Layer

Figure 13, Overview of the Information Architecture Layer

The Data Warehouse must reflect the multiple views of data stewards who contribute to these stores, and deal with the potential that there are multiple sets of SDEs. The location of the data warehouse may be central, or geographically distributed, for reasons of operational efficiency, redundancy, security, and safety. A key feature is that the warehouse(s) do not represent the superset of all corporate data, but rather a subset of critical data which may include data currently external to the Department that is of interest across the user community of individual databases.

      1. Description

The top-level view of the Information Layer is a decomposition of the various subsets of data holdings in the Department as they relate to the separate mission areas defined in the Business model. Thus, Figure 14, Structure of the Information Architecture Layer, shown below, inherits its structure from the existing organizational and functional hierarchy. The Information Layer also contains additional components of the target architecture, notably cross-function data integration, multimedia (ensuring that the ITA addresses different formats for representing data, such as graphics, images, and video), and metadata (which contains information about the data and about the structure of specific data environments).

Structure of the Information Architecture Layer

Figure 14, Structure of the Information Architecture Layer

The target information environment will provide enhanced support for Department requirements in user profiling and information access. Intelligent solutions will assist users in searching corporate data repositories and identifying information of interest. The system will be far more dynamic, flexible, and powerful than today's user profiling, and will ensure that end-users have timely access to the information they need and are authorized to receive. The profiling capability will incorporate appropriate security safeguards to limit access to authorized users on a need to know basis.

The target environment will also support multiple techniques for viewing and presenting information. Thus, existing initiatives in geographic information and mapping would be extended to embrace new approaches and expanded data sets, as needed for Department programs and requirements.

When the Information Layer and its constituent data and process models are in place, individual database developers will apply these models to ensure interoperability with other databases and to guarantee the proper relationships with the data warehouse when it is instituted. All database designers and developers are to comply with the following guidance:

The Information Layer also contains process models that capture a clear understanding of the flow of work and information between and within organizations that combine with data models to accomplish the following:

As noted above, this Layer also contains business rules, which are relatively permanent policies or constraints that govern and/or support business processes. Business rules are defined and recorded apart from the procedures and applications that use them.

      1. Applications Architecture Layer

The Applications Architecture Layer describes the approach to be taken and services to be supported in acquiring, developing, and implementing application systems. The principles and strategies that underlie this layer reflect the business requirements and are intended to exploit the information architecture layer and modern IT technology effectively and efficiently. Features of this layer include standard utilities for the two modes of business process flows presented in the Business Architecture Layer -- transactional and collaborative. Some of the components of this layer are:

      1. Description

      2. Figure 15, Structure of the Applications Architecture Layer, depicts the structure of the Applications Layer and suggests how it can be further refined as specific business and support applications are defined and developed. The overall structure involves two layers, or stripes. The "top" stripe is organized by business area, and the applications in each of those areas are constructed to satisfy specific functional requirements. These areas are not described in detail in this section -- they are included to reflect the link between the Applications Layer and the Information and Business Layers.

        Applications Architecture Layer

        Figure 15, Structure of the Applications Architecture Layer

        The lower stripe of the Applications Architecture Layer comprises the support application areas. These are sets of software products and services that are not structured along mission or functional lines. They may be commonly used in several, many, or all mission and administrative application areas. For instance, all users use email, and there is to be only one common email system in use across the Department. Others, such as case management might support only a few case-oriented user applications, such as in Consular Affairs, Legal, and Personnel. The same support application packages are available for use both in mission and administrative areas, and their use is strongly encouraged.

        The Application Layer contains the standard utilities and tools needed to support the two basic types of business flows presented in the Business Architecture Layer. Bureau system developers will be able to use these utilities as building blocks to construct applications that meet specific functional requirements, resulting in a high level of standardization. This should reduce development cost and training burdens, and facilitate interoperability and information exchange.

        Support applications may be used directly by users, as with email and office automation. Or they may be building blocks for developing user applications. Workflow management and case management would fit in this category. Some support applications like document management might fall in either category, depending on how they are adopted. The applications layer makes these sets of support applications available to application development efforts, and designers must determine how best to use these assets. For example, message handling might be based on email and document management support applications, or it might find a more suitable mix of tools by using workflow management and collaborative work support applications.

        A key feature of the set of support applications is that it is continually evolving. It is dependent on advances in technology and availability of workable tools that support Department business requirements. Indeed, Figure 15, above, shows a notional set of support applications. There may not be any immediate need for certain of the technologies shown in the figure until future projects require them. But, they should be evaluated and selected in an architectural and enterprise-wide context.

        The Applications Layer also includes two types of Application Program Interfaces (APIs), shown as the "stripes" in Figure 15. These APIs define standard interfaces between sets of software functions. The architectural concept behind an API is that standardizing the set of calls provides better enterprise-wide interoperability, supports portability across platforms, and protects the information systems from being captured by proprietary product suites. To the extent that industry standards are available they will be used. In other cases, the Department would define its own standards for the API.

        The following paragraphs describe the currently defined Support Application areas.

        Office Automation -- an integrated suite of desktop software available to end users (client software), providing basic non-mission-specific capabilities. Typically this includes network and file browsers, word processing, presentation-level graphics, spreadsheets, image viewers, personal (local) database management systems, media players, and utilities like calendars, schedulers, meeting planners, directories, calculators, file conversion and compression. The suite should be integrated and support linking between file types, such as seamless embedding of figures and spreadsheets in text, and creation of multimedia and hypermedia files.

        Email -- the standardization of formats, protocols, and applications for sending, receiving, and manipulating electronic mail among individuals, organizations, and processes (programs). Email may be embedded in higher-level business-oriented applications, such as formal record message handling or administrative applications. It is also used directly as a utility user function, universally both within the Department and with external parties. And it may be used by other support applications as its communications mechanism of choice, for example, to move documents under a document management paradigm.

        Workflow Management -- standards-based utilities that provide for creation, management, manipulation, and communication of work objects. Workflow management provides a high-level set of tools for dealing with sets of data and activities as they are described in systematic, transaction-oriented workflow models. Workflow management may be useful for supply chain and other external party interactions, as well as structured internal functions like personnel and logistics.

        Document Management -- the integrated collection of all functionality relating to creation, coordination, distribution, dissemination, storage, retrieval, version control, and disposition of documents; supporting a wide variety of transaction and document types. Rather than address different document types with separate systems, document management seeks to integrate data holdings, and provide consistent tools to monitor and manage the enterprise document structure. The full range of modern content and formatting options is available without regard to the historical accident of particular message or document formats or mechanisms.

        Collaborative Work -- tools for interactivity among parties who need to share data or functions are contained in this category. They work on the holdings of the document or case management software, and they provide the underlying tools to manage the diversity of media that are managed by the document and workflow managers. This support application area addresses sharing, coordination, and presentation aspects of the shared work environment. The tools may be used as embedded features of other support applications, or they may be used as stand-alone programs, such as video teleconferencing support.

        Case Management -- high-level management functionality focused on handling sets of related transactions against case folders. These would be applicable to personnel, legal, or consular affairs applications that must coordinate and consolidate sets of transactions and processing made in various places by multiple agents regarding an individual or situation. Case processing would also be useful for crisis, event, or topic-oriented situations where multiple parties take independent actions against a single set of related files.

        Additional areas will be defined as required, and others may be eliminated when we reach a consensus that their functionality has been subsumed by other areas or is no longer of interest to the Department.
      3. Infrastructure Architecture Layer

The Infrastructure Architecture Layer organizes and provides guidelines for the technical underpinnings of the enterprise set of information systems. It describes the services upon which the applications are built and the platforms that provide those services. As with the other "layers" of the overall architecture, it interfaces with whatever layer or level that requires its services, not just with the layer immediately above it. For example, operators may directly interface with operating system services, and any user may directly invoke security services, as well as support applications and user applications using system services via the service application program interface (API).

Figure 16, Conceptual View of the Infrastructure Architecture Layer shows the conceptual topology of the Infrastructure Layer.

Infrastructure Architecture Layer

Figure 16, Conceptual View of the Infrastructure Architecture Layer

The Infrastructure provides the hardware and software platforms, network facilities, and associated services. The infrastructure reflects the target architecture and business requirements presented in preceding sections, including the following features:

The infrastructure will have inherent attributes of reliability, scalability, flexibility, availability, manageability and maintainability. All these attributes presuppose commonality across the entire architecture from the user platforms to the Infrastructure required to support the Department mission.

      1. Description

      2. Figure 17, Infrastructure Architecture Components, depicts the components of the Infrastructure and their interrelationships. The basic organization involves two levels, a set of Platform Services (software functions) which are supported by the underlying Hardware Platforms. Platform components include all the hardware components of the system, from mainframes to PCs and everything in between, plus networking components.
        Infrastructure Architecture Components
        Figure 17, Infrastructure Architecture Components
        The key interfaces are between the services and the applications that invoke them, and between the hardware platforms and the external world. The first is the Department-standard API that was discussed above in the context of the Applications Architecture Layer. As noted, it consists of standardized interfaces to the greatest extent possible, proprietary interfaces to the most limited extent possible, and additional interface modifications made by the Department to standardize the API where applicable. Part of the job of those who implement the Department's Infrastructure Architecture is deciding on the level of API standardization appropriate for the required interoperability and portability needed.

        As Figure 17 shows, the Infrastructure Layer contains two broad categories of components: hardware platforms, and platform services. The basic types of hardware platforms are derived from the Department's current environment. The number and organization of categories and components may change over time as Department requirements change and technologies emerge and change. The currently defined components are described below:
      3. Hardware Platforms

Hardware platforms provide the physical component of the Infrastructure Layer. This includes all system components necessary to support the infrastructure services, and encompasses all physical interfaces between system components and external systems. These components include:

      1. Infrastructure Services

The Infrastructure Layer provides services either directly to end-users or to other IT components, such as applications and data repositories. The currently defined infrastructure services are:

Operating System -- Operating systems services provide the software environment and basic interfaces within all computing hardware platforms. They are the core services needed to operate and administer the platform and provide an interface between application software and the platform.

Communications -- This service group is a collection of platform services that are not supported by the Network Services group. For baseline and transition systems (prior to achieving a fully standards-based network system as defined in the target architecture), a number of other communications services must be provided, especially to interface with external, non-networked systems. Besides legacy and non-standard communications interfaces, this group supports other non-digital data communications, such as voice and video, which are not fully integrated into the target network architecture

Data Management -- Central to information systems is data management, which is independent of the processes that create or use that data, maintained independently, and shared by an evolving set of processes. This service group encompasses the procedures, practices, methods, and software used to manage data, including data dictionary/directory, database management systems, and distributed data. The service group also encompasses any explicit data-oriented modeling tools not already provided by the Development Services group.

Client Services -- These services include user and applications interfaces that are often the most complex part of a system to develop and maintain. Within the past few years, significant advances have been made in user/application interface technology to enhance ease-of-use and to reduce the development effort required.

Security -- Security services support two common goals: Confidentiality and Integrity. Confidentiality provides the assurance that information will be held in confidence with access limited to appropriate persons. Integrity provides the confidence that information will not be accidentally or maliciously altered or destroyed. Security services provide functions to support both embedded functions (used by and within applications while they are running) and off-line, security analysis functions.

Directory Services -- This service group provides a common access point to user and other information for email, security, and other systems such as an electronic phone book. While formerly considered only a segment of network services, directory services are now recognized to have broader applicability across the application layer, and should be identified clearly for their role in security and enterprise management.

Network -- Network services provide connectivity and basic services to foster communications across workgroups and sites, supporting distributed data access and interoperability in a heterogeneous environment. Components of this category include data communications, electronic mail, transparent file access/transfer, remote network access, remote procedure call, and any other forms of inter-process communications.

Network Services is sub-divided as follows:

Data Interchange -- Data interchange services provide specialized support for information exchange among applications on the same or different platforms. Components of this category include text data, spreadsheet data interchange, desktop publishing interchange, graphic interchange, image compression/decompression, and calendar data. Extensions to full multimedia, and the metadata required to manage it and create hypermedia, are growing service areas within this group.

Transaction Processing -- Depending on the approach adopted by the Department, the transaction processing service group may or may not be an explicit component of the Infrastructure Layer. If an explicit transaction-oriented approach is adopted for those applications in the Department that are based on that sort of data interchange and processing model, then this service group would be used. A number of mature robust packages are available that could be adopted for Department-wide use, and significant savings could be achieved.

Enterprise Management -- Management services are integral to the operation of the Department's open systems environment. System management across the enterprise includes mechanisms to monitor and control the operation of individual applications, databases, systems, platforms, networks, and user interactions with these components. Management services enable users and systems to become more efficient in performing required work.

In addition to the embedded system management services, this category of platform services also encompasses Fault Management (including Help Desk), Configuration Management, Storage Management, and Capacity Management

Development -- Development services provide the structure to develop and maintain software that exhibits desired characteristics. This includes languages, tools, and methodologies, use of portable, scaleable, interoperable software. Development Services provide the infrastructure to develop and maintain software that exhibits the required characteristics.

In addition to software development and the support environment for code development, programming services provides the following support tools:


  2. While the ITA is primarily a technical document that guides IRM activities, it will have a profound effect on everyone in the Department of State. The following paragraphs discuss the ITA from the perspective or "view" of three different Department roles: end-users, executives, and system managers.
    1. Users' View

    2. By standardizing the Business Architecture Layer, users will find the Department of State's future IT environment more integrated and flexible than what is in place today. Through standardization, business processes at State will mirror many of the functions employees can now do at home via the Internet. A more open environment will encourage greater information exchange, thus improving the quality and timeliness of information that is available to State users. In general, the user will see an IT environment that is less fragmented, more robust, more standardized, and more effective than what their workplace provide them currently.

      The Information Architecture Layer will ensure that users have broad access to corporate information repositories, and that needed information will be represented in standard, easy-to-understand ways. Information needed to perform your job will be consistent, reliable, and organized as a mirror of the structure of your business processes and associated data flows. Web-based search engines will provide transparent access to the vast storehouse of information available within the Department and elsewhere on the World Wide Web.

      Users will see the structure of the Applications Architecture Layer reflected in their own bureau applications (either mission or administrative functions for each user's needs). This would include direct access to support applications like office automation and email, and indirect use of other support applications, such as workflow management and collaborative work tools. Applications will be highly standardized throughout the Department -- when moving from Bureau to Bureau, the learning curve will be much less steep than it is today.

      The Infrastructure Architecture Layer ensures proper security to authenticate users, some data management functions, and network directory services. The routine interactions that users have with the services provided on their workstations (PCs) will shape their view of the Department's IT Infrastructure. All other services will be (and should be) transparent to users.
    3. Executives' View

    4. Due to standardization within the Business Architecture Layer, Department managers will experience an environment that is more efficient, performance-driven, and competitive. While resource limitations will continue to put pressure on managers to deliver more with less, streamlined processes and reduced bureaucracy will increase each manager's control and potential effectiveness. To accomplish these ideals, managers will have access to powerful tools for resource planning and management.

      Managers will expect the Information Architecture Layer to enable cost-effective use and access to corporate information. They will be able to obtain timely and accurate management information, as well as substantive data related to foreign policy research and analysis.

      Through improvements in the Applications Architecture Layer, managers are concerned primarily with consistency, functional coverage, and training issues. Managers will be stakeholders in defining future functionality (more with upper levels than with support applications), but also will be able to influence decisions about application efficiency, interoperability, and change management. This architecture layer offers the potential to enhance the value of information systems, while reducing total costs.

      Managers will use the Infrastructure Architecture Layer as the "whatever it takes to get the job done" aspect of the system. That is, managers will not care about how the needed functionality is accomplished, but only that, in the aggregate, the services are provided that support their users. This layer will ensure efficiency of operations, usability, and have an impact the selection of software and training requirements.

    5. System Managers' View

    Adoption of a standard Business Architecture Layer will allow system managers and developers to become solution integrators and consultants. As the Department embraces commercial technology and off-the-shelf solutions, we will do little custom software development. We will also integrate the Department's information assets by designing, developing, and maintaining one or more corporate data warehouses. IT professionals and users will need to develop the skills to support and utilize new approaches to accessing and leveraging information.

    The Information Architecture Layer will provide system developers and IT project managers a basis for database design as well as applications and infrastructure development. The information layer establishes most of the service needs that must be provided. System managers will be required to coordinate database planning and design activities with the IRM/OPS/SIO Data Administration, to ensure standards compliance and conformance with the EDM, data interoperability, and warehouse standards.

    The Applications Architecture Layer affects system managers most directly, since they are responsible for implementation and system operations. System managers will use standard utilities and other components and services available in this layer. As the Department moves toward standardization in application development and components re-use, system managers are expected to support these goals.

    The Infrastructure Architecture Layer provides the basis for all platform engineering and development efforts of system managers and technicians for the required operational characteristics of the system, including its functionality, performance, availability, usability, manageability, security, interoperability, and flexibility. System managers are expected to ensure that their specific solutions conform to the standards and approaches specified in the Infrastructure Architecture.

This document is the first version of the Department's ITA. During the next six months IRM/APR/IAP/AE plans to transform this document via several iterations into the Department's official ITA. It plans to effect this transformation through three concurrent processes:

  1. Extensive review of each version of the ITA document by IRM, Technical Review Advisory Board, bureaus, and IV&V reviewers, followed by modifications to the document based on comments and suggestions received.
  2. Further detailing of the four architectural layers (Business, Information, Applications, Infrastructure), beginning with input from USIA and ACDA, but extending to whatever architectural details bureaus wish to have addressed.
  3. Development of key segment architectures, such as Security, Enterprise Network Management, and Information Exchange that cut across the architectural layers and are considered important enough to the Department's IT activities to warrant special treatment.

The following paragraphs describe generally how these three processes will proceed and set forth target months for completing major elements of the ITA.

    1. Review Process

As a general rule, reviews of the ITA document will proceed sequentially. This will begin with an internal review with the IRM bureau, and continuing through the Technical Review Advisory Board, bureaus, and IV&V. Depending on reviewer needs, IAP/AE will provide versions of the ITA in hard copy and electronic forms, make presentations, and arrange for group and individual discussions. Additionally, IRM/APR/IAP/AE will collect information and suggestions via questionnaires, interviews, and the Intranet.

Each new set of reviewers will see whatever improvements have been made to the document by the previous set of reviewers. In addition, whatever version of the ITA document being reviewed will include:

In other words, over the next six months the ITA will be an extremely dynamic document, but reviewers will always have the most up-to-date and complete version of that document for their review.

We anticipate that bureaus will have several opportunities to review the ITA document and offer suggestions for its improvement:

    1. Detailing of the Architectural Layers

    2. IRM/APR/IAP/AE will add substantial detail to the descriptions of the four architectural layers that are set forth in this version of the document. The ITA will also be available on the IRM/APR/IAP Web site. This version of the ITA does not yet fully address the reorganization issues of ACDA and USIA, which will be addressed in the Business Architecture, nor does it necessarily include all issues of interest and importance to DoS bureaus. IAP/AE is holding discussions with bureau representatives to inform them of future enhancements of the ITA and to complete these four architectural layers

      Target months for completing draft versions of the architectural layers are as follows:

      Business Layer May

      Information Layer July

      Applications Layer August

      Infrastructure Layer October

    3. Development of Key Segment Architectures

IAP/AE plans to develop two segment architectures -- Security and Enterprise Network Management -in time for inclusion in the official ITA document to be published in October. Other segment architectures -- e.g. Information Exchange -- will be developed and added to the ITA document at a later time.

Target months for completing draft versions of the segment architectures are as follows:

Security May

Enterprise Network Management August

After the ITA is published its maintenance will be an ongoing process. As technology develops and provides improved methods for conducting business, the Department's ITA and associated standards will inevitably change. It is important that all elements of the Department contribute to the development and on-going maintenance of the ITA, thereby assuring that the ITA and standards remain relevant to their needs in managing and using technology. Since this document represents the first step in shaping the ITA, it is particularly important that all bureaus participate fully in reviewing this document and suggesting improvements to it. For further information please contact the Architecture & Engineering Division Chief Greg Linden, IRM/APR/IAP/AE, at (202)776-8987 or email LindenGS2@state.gov.


The effort to create this ITA was a significant team effort that required the dedication of the following individuals and their organizations:

Department of State Managers

Don Hunter, DCIO/APR

Greg Linden, APR/IAP/AE

Ken Alms, APR/IAP/PL

Contractor Support


Kevin Kavanaugh


Barry Finklestein

J.G. Van Dyke

Craig Jenkins

Tom Meier

Angie Spencer

Andy Tainter

ManTech International

Richard Lee Doty


Wally Francis

Karl Sanger

Annex A, Glossary


A Logical Modernization Approach -- Department model for automated information systems and telecommunications modernization based on use of Information Technology (IT) standards and commercial products.


Application Program Interface


Term used to identify, or "measure" the capacity of a telecommunications circuit or local area network (LAN).


Black Router Network. A DTS-PO IP-based network in pilot phase -- The "Intranet" of the Foreign Affairs Community.


Configuration Management


Common Operating Environment. A term used to refer to a specific configuration for platforms such that all users utilize the same configuration thereby lowering management and troubleshooting effort and costs.


Communities of Interest. In the context of this document, this term refers to a set of information, and the users, to which a group of users needs access. This concept is an extension of "need to know."


The new multi-faceted diplomacy in an electronic age. To be effective in the next century, our diplomats will require access at their fingertips to a wealth of information and effective tools to manipulate that information and share it with others. To keep up with the issues of the day, they will require Internet-like networks and intelligent automated agents that can help them find and organize critical information. They will need the ability to collaborate with counterparts in other agencies, foreign governments, non-governmental organizations, and the public. Their work will become increasingly dependent on information and IT networks.


The use of electronic coding techniques to protect information from disclosure to unauthorized readers, to prevent undetected modification of the information, and to support reader to writer identification and authentication.


Any telecommunications or network device used to regulate/control the flow of information packets between networks. The firewall, or firewalls, implement an IT security policy by screening packets to verify they comply with policy, do not contain malicious code, and are not otherwise attempting to intrude on the protected network side or disrupt its operations.


File Transfer Protocol



An internal IP network. Open Net and Class Net are the "Intranets" of the Department.


Internet Protocol - the basic standard established for data exchange over the worldwide Internet and widely adopted by organizations operating private networks, such as the Department's Open Net and ALMA-based LANs.


Local Area Network. A small network that serves a group of users. Typically confined to a single facility. Most LANs in the Department are built using Ethernet (10BaseT) hubs.


Metropolitan Area Network. A regional network that connects building LANs and backbones together and typically serves as a collection point to interconnect with a WAN.


Operating System


Open Systems Interconnect


Public Key Infrastructure. The term used to refer the system required to supply and manage certificates for public key encryption and digital signature used by clients and servers


In the context of this document, the platform is the stable, cross-project base of both hardware and infrastructure software provided to (and evolved for) all projects in the Department. Note that this contrasts with some commonly held definitions that consider "platform" to include only the hardware base.


A defined structure, content, and flow for communications between computers and other networked devices.


Problem Tracking Resolution. The business of tracking the process and information by which a help desk or other operational entity troubleshoots and resolves a user or infrastructure problem.


Secure/Multipurpose Internet Mail Extension. Provides a consistent way to exchange secure MIME data. Based on the popular Internet MIME standard, S/MIME provides cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and privacy and data security (using encryption). S/MIME is used by traditional mail user agents to secure the text and attachments. However, S/MIME is not restricted to mail; it can be used with any transport protocol that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems. Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet.


Standard Data Element


Secure Hypertext Transfer Protocol. A means of securely transmitting HTTP formatted information.


Service Level Agreement - a definition of the type, quality, and quantity of network services agreed to by the provider and the customer.


Secure Socket Layer. A means of securely transmitting Web pages.


Agreement on the rules, procedures, and content of AIS and telecommunications exchanges to include open standards, industry standards, and de facto standards


Transmission Control Protocol/Internet Protocol

Thin Client

In the context of this document, "thin client" refers to minimizing the amount of processing logic and data manipulation on a client to the maximum extent possible. The "thinnest" client is nothing more than a terminal.


Virtual Private Network - a capability to 'split' a physical network or circuit path into two or more sub-paths that use various protocols to define the circuit path and protect the data being transported.


Wide Area Network. This refers to a collection of circuits that interconnect a widely dispersed set of facilities, and other networks such as a MAN.


A CCITT protocol, X.500 is a family of standards and uses a distributed approach to realize a global directory service. Information of an organization is maintained in one or more so-called directory system agendas (DSAs). The X.500 directory supports a variety of services including security (certificates), e-mail (addressing), and "white pages" (name and phone number).


One of the X.500 standards that defines a security certificate to provide a vehicle for associating users with their encryption keys. All of the user's "public" information is stored in a X.509 certificate for use when exchanging information securely with that user. Other information such as to whom does the user belong, what authority issued the keys, when do the keys expire, what levels of information classification is this user allowed to access, and how can the certificate be validated is also included.

Annex B, Current Issue Paper Candidates

  1. Corporate Data Model

  2. Determine the best way to establish a corporate data model given the decentralized environment at State. Consider a phased approach in which immediate benefit is achieved and value demonstrated to management, thus building momentum and support for future efforts. Link corporate data model to business needs, such as broad access to critical data, data warehouse, and need to share data with other foreign affairs agencies.
  3. Application Tools Suitable for Messaging Replacement

Explore available tools and technologies for supporting the diverse requirements now addressed by the outmoded cable system. Document all uses of the cable system (e.g., organizational messaging, individual messaging, document management, transaction processing), and the range of potential technology components of a reengineered messaging solution (e.g., groupware, email, transaction brokers, document management, correspondence management, web-enabled tools). Map technologies with business requirements and flows, and formulate a comprehensive messaging architecture segment.

Annex C, Architecture Segments

C-1: Security Segment


C-2: Enterprise Network Management Segment


C-3: Information Exchange Segment



[End of Document]