EVALUATION CRITERIA FOR MEETING

EVALUATION CRITERIA FOR MEETING

THE DEPARTMENT OF COMMERCE INFORMATION TECHNOLOGY ARCHITECTURE REQUIREMENTS

The following are the evaluation criteria against which: (1) Operating Unit Information Technology (IT) Architecture efforts and status will be measured, and (2) individual IT Architectures will be evaluated. An Architecture Development Checklist and selected definitions are also provided.

General Operating Unit Requirements

1. Each Operating Unit must have one or more IT Architecture(s) in place to cover all of its organizations and operations.

2. Where the Operating Unit does not use one IT Architecture for all of its organizations and operations, the Architectures used should be based on business processes within the Operating Unit. If the business process in question involves other Operating Units, organizations, or portions of the same Operating Unit, the Architecture should be developed with the entirety of the operation in mind. If one Architecture for an inter-organizational business process is not possible (e.g., due to non-cooperation of other organizations), the Operating Unit's business process Architecture should be coordinated with those organizations to the greatest degree possible. Operating Units need mechanisms to review their multiple architectures as a whole to look for linkages and even consolidation if appropriate; the use of multiple Architectures cannot be viewed as a way of allowing sub-organizations to maintain isolated Architectures that are not analyzed as part of the overall organization's business process and needs.

3. To be compliant with Departmental requirements an organization or process must have an IT Architecture "in place." This does not mean that it must have fully migrated to a target architecture. Since an IT Architecture needs to be frequently updated, full "implementation" of the contents of a changing target architecture may never take place. Compliance will entail developing the required architectural documents and showing clear progress in migrating towards the target architecture.

4. Each Operating Unit must provide IT Architecture documentation to the Departmental Chief Information Officer (CIO) upon request.

5. Each Operating Unit must include a governance plan as part of its periodic architectural submissions to the Departmental CIO. A governance system addresses how the Architecture is kept up-to-date; how the agency ensures that plans, procurements, and system development are done in accordance with the Architecture; how to determine when exceptions to the Architecture are needed; and how implementation of the Migration Plan will be tracked.There should be evidence of Senior Management support for the use of the Architecture.

6. There must to be effective mechanisms for communicating the Architecture to affected personnel. The Architecture should guide IT and business behaviors, and investment and acquisition planning, and not be "shelfware" or something only a few specialists know about.

7. A mature Architecture process needs an effective feedback mechanism between the business and IT processes; each should help guide the actions of the other.

8. Individual IT Architecture(s) must comply with the requirements set forth below.

IT Architecture Requirements

The following are the elements or characteristics an IT Architecture must have to meet the Departmental Requirements.

1. The IT Architecture must be documented. A de facto Architecture is not sufficient.

2. To be complete an Architecture must deal with the following components:

• the business processes performed including performance measures, how they are organized, and where they take place;

• the data sets and information flows needed to perform the activities;

• the applications and software needed to capture and manipulate the information sets; and

• the technology (computer hardware, network, telecommunications) needed to run the applications.

An IT Architecture that only deals with hardware and software standards will be considered as only minimally complete. The involvement of programmatic people, rather than just information technology staff, is necessary for the development of a complete and effective architecture. A good Business Continuity and Contingency Plan should have already identified much of the business process information needed.

Security is an important factor in developing all aspects of an Architecture and must be reflected in the documentation and plans.

3. To be complete the Architecture must cover all of the organization or business process(es) within the defined scope for that Architecture. Architectures reflecting only part of the organization or process(es) within the scope will be considered only minimally complete.

4. The IT Architecture must be consistent with the organization's Strategic Plan, Strategic IT Plan, and Operational IT Plan, as well as with the Department's Annual Performance Plan and the goal of an electronic government.

5. IT Architecture documentation should normally include the documents listed below or equivalents. Alternative or minimized forms of documentation must obtain the prior approval of the Departmental Chief Information Officer.

• IT Principles to provide basic ground rules for the designing, building, acquiring, or re-engineering of IT systems.

• A Baseline Architecture showing the architecture at the start of the process.

• A Target Architecture showing the desired architecture.

• A Migration Plan that shows how the organization or business operation intends to implement its Architectural goals (e.g., how a Target Architecture will be implemented). Since an IT Architecture should be periodically revised (see below), it is unlikely that many Architectures will ever be implemented so completely that no Migration Plan at all would be needed. Such a situation would probably be an indicator that the Architecture needs review.

• A Governance Plan documenting how the Architecture will be kept up-to-date and enforced.

6. There is no set requirement for the number of years that Target Architectures and Migration Plans must address. Target Architectures usually should cover from three to five years into the future. Migration Plans, detailing more specific information, may deal with a shorter time frame.

7. IT Architectures must be updated on a periodic basis. Presentation of an Architecture last updated years ago would be unacceptable. Architectures should move towards the use of metrics to evaluate and document results and guide future actions. The Department's Architecture Capability Maturity Model provides a tool for self-evaluating the current status of the architecture effort and guiding the development of priorities.

8. An IT Architecture must conform with any Department-wide standards unless waivers have been granted. If an organization has multiple architectures, lower-level architectures must be consistent with those at a higher level.

9. Individual IT Architectures will be evaluated on the basis of whether they: are complete, take into account changing technology and business drivers, contain realistic migration plans, and reflect a true commitment to implementation by the organization or processes. The objective is to improve Departmental services and products through optimal use of Information Technology, not to produce sets of documents. Given this objective, there will be some subjectivity involved in analyzing specific IT Architectures.

Definitions

IT Architectural Principles - Statements that provide basic ground rules for the designing, building, acquiring, and re-engineering of IT systems. These can help to provide a context for specific architectural decisions made later in the process and also help to make those decisions consistent. A few examples of principles follow:

• that open systems must be used to the maximum extent possible and that proposals for proprietary systems must be approved at a higher (defined) authority;

• that COTS (commercial off-the-shelf software) be given preference; and

• that any development activity must consider the impact of the activity on existing networks.

Baseline Architecture - A characterization of the current architectural status that provides enough data to understand the current IT situation and the related problems that exist. The word "characterization" is used because it usually is unnecessary to identify and analyze everything IT or information-related in the organization.

Business Process - A defined business activity with clearly defined inputs and outputs, which usually delivers a product or service or suite of products and services to the public, other agencies, or other portions of the agency. Within NOAA, for example, the management of commercial fisheries could be considered one business process, while the development and distribution of nautical charts could be another.

Migration Plan - A document identifying how the gap between the Baseline Architecture and Target Architecture will be bridged. It should identify the processes for making the migration, assign responsibilities, set priorities, and contain a schedule. Sometimes called a Sequencing Plan.

Target Architecture - A model of how the architecture should look in the future (three to five years), taking into account business and technology drivers. The model identifies the general types and attributes of data, IT equipment, software, etc., needed to support the current and planned business process, and how they inter-relate.

Understanding the concept of a Target Architecture is key to the architectural process. It is the concept most likely to be misunderstood, and if it is, then the architecture effort is unlikely to produce real benefits. So it is important to first understand what a Target Architecture is not. It is not a procurement plan listing the specific IT equipment, software, services, etc., the organization wants to buy in the future. It is not a list of standards for equipment or software acquisition.

As stated above, a Target Architecture is a model of the general types and attributes of IT equipment, software, etc., needed to support the current and planned business process, and how they inter-relate. Any procurement list that extends beyond a year or so is of dubious value for most organizations, but a model showing the functionality needed and sought will usually have the long-term value of guiding the development of specific standards or procurement decisions and clearly keeping in mind the essential roles of and relationships between IT resources. If newer versions of software being used are released, for instance, the Target Architecture would probably remain unchanged unless the capabilities of the software would change the way in which work processes take place. This is because the Target Architecture focuses on the role of that software rather than the specific version or even brand name.

Technical Reference Model (TRM) - An organization should create a Technical Reference Model (TRM) and Standards Profile as part of the migration and implementation plans for an IT Architecture. A TRM generically identifies the various software, hardware, and interface services needed for the organization or business operation. The TRM shows how everything fits together, guides the acquisition of IT products and services, and helps provide a base for future architectural changes. It also serves as the basis for developing a Standards Profile, which identifies acceptable options within the IT Architecture for filling the needs of the TRM's services and progressing toward the Target Architecture. These options are specific types of equipment, software products, protocols, etc. There may be a single standard for some elements and a range of acceptable options for others. It is important to be aware of situations where higher-level organizations or outside business needs may constrain choices, such as where a higher organization level has already defined a standard for something throughout the organization. A Standards Profile should guide acquisition and development activities.