Describe Integrated Technology Blueprint

Describe how the technology elements will work together at the application and systems levels.

	A-TARS: - Agency-Wide System Properties - Technology Boundaries Descriptions - TRM Description - Integrated Technology Descriptions - Technical Architecture Work Plans and Direction - AIS Design and Implementation Info. - Strategic Analysis and Data - Changes
Describe Integration Scheme Update Integrated Technology Descriptions		- A-TARS: Integrated Technology Descriptions - Ancillary Design Information - Changes - Status
	- Technical Architecture Team

Introduction

These activities create and maintain the highest-level design of the HS Agency's systems: the Integrated Technology Descriptions portion of the A-TARS. These descriptions serve as the context for how technology elements are integrated across the HS Agency. Similar in purpose to the construction industry's use of blueprints, these descriptions identify the IT architectural elements, the functionality and other properties required of them, and their arrangement. This includes computer platform configurations and their function, connections and access paths, and data sources and data exchange.

The highest-level contextual view (the system architecture) is portrayed. Generally, top-level design diagrams identify the types of:

Computer processing nodes (clusters of computers or individual platforms such as servers or legacy systems)
Enterprise-wide data stores and communications devices (e.g., switches and routers)
Network links (e.g., LANs or point-to-point)

The architect's key design concerns are the allocation of functionality to processing elements, the identification of key interfaces and access paths, and the essential properties of key components and the composite system (e.g., reliability, maintainability, performance, scalability). Different arrangements may be necessary based on the environments of interest and the setting in which the equipment is used.

In addition to the highest level contextual view, models for partitioning the applications are also provided. These out-of-context views detail the application's structure - the applicaton's architecutre. The structuring can be based on many strategies, such as centralized host-based, n-tier layering, or peer-to-peer. Techniques such as using components or Web service -based approaches can be employed. Application architecture descriptions at the HS Agency level provide guidance to the application designers for partitioning and allocating functionality and identifying the service interfaces for each part of the application. This may include application layers such as presentation, business logic, data access, or data storage.

Parts of the applications are allocated across the platforms in the contextual descriptions, each part providing services to other parts, or to external users and automated systems. For example, the client presentation logic can execute on the client PC platform or a handheld device, business rule logic can execute on an application server, data access and storage can reside on a data server, and so forth.

As the contextual and application -level descriptions are elaborated, design activities to detail the elemental building blocks can be initiated. The contextual and application design descriptions are therefore used to index these elemental building blocks. Each type of building block is further described in other parts of the A-TARS, by activities that Describe Services, Describe Data Source and Business Rules, Describe Platforms, Equipments, and Packaged Solutions, or Describe Networking. For example, the API and behavioral characteristics for a data access service used by the business logic layer (executing on a data access/store server platform) can be specified in the services portion of the A-TARS.

TANF Example:

The highest level contextual view (the system architecture) may be portrayed in many States as one or more diagrams denoting an existing Mainframe and the statewide SNA, Frame Relay, or ATM backbone networks. These diagrams may depict the central processing in a computer center and the various regions with routers, hubs, etc. External systems that the Mainframe may access, or provide services to, may also be shown. As necessary, the desktops in use in a multi-office distributed platform environment may be indicated. The position of critical switching equipment may also be included.

An analysis of items noted in these diagrams would be the basis of specifying the generic system architecture descriptions. The essential technical characteristics of these items and their relationships would be abstracted to describe the types of computer systems, their characteristics, and interconnections envisioned for the future, based on the IT Strategic Plan. For example, a common front-end may be envisioned, where applications will be integrated across back-end systems with access through a common portal. If the strategy is to retain the Mainframe, then the new role for the Mainframe would therefore be defined. The essential characteristics of the mainframe platforms, such as amount of DASD required, or network throughput via the ISP would be specified. The Architects would concentrate on the System-level interfaces.

The application-level models (application architectures) could be deduced from the design documentation of existing applications. New models, such as those defined using the J2EE platform could also be included. This would show how existing and new applications are structured. Guidelines on how to migrate portions of the existing applications and associated data to a new application architecture could be prepared.

Top

Activities

Consolidated guidelines are available to perform the following key activities:

Describe Integration Schemes. These actions build the descriptions by iteratively performing the following:
- Establish Application Models. At the center of the design process are decisions governing the logical partitioning of functionality within the applications (the application arhcitecture). These application design models determine how the application will be decomposed and packaged, the underlying technologies to use for each portion, and how the application parts will interact with one another. The application models and the distribution schemes identify the services to be provided and the capabilities of the platforms needed to support each portion of the application (e.g., data access services that hide the data store platforms from an application's business logic).
- Establish System Models. As the design structure of the application materializes, decisions on how parts of the application will be physically deployed and interact across the processing elements are made. This is the contextual view, the system architecture. Agency-wide data stores are identified. Specialty platforms and their functional assignments are defined, such as client-based browser, Web servers, application services, mail servers, integration servers, data servers, and a host of others. Existing legacy systems that will be retained will be incorporated into the integrated design. Strategies such as Enterprise Application Integration may be considered to extend the lifetime of existing systems. The design at this level takes into consideration the overall system properties needed, such as reliability, maintainability, and scalability.
- Define Architectural Plateaus. Intermediate steps ( plateaus) may be necessary. The architects should define the intermediate plateaus that will be achieved, including any scaffolding, adapter, or integration technologies. This requires coordinating with the Planning and Managing the Technical Evolution activities to determine what technologies will be in place to support the initiatives called out in the HS IT Strategic Plan. The application and system architectures for the next plateau are defined in detail, while the following plateaus are outlined in sufficient detail to show the overall evolutionary path. They, in turn, will be detailed as the HS Agency business and technology matures.
- Identify Building Blocks. As the application and system designs unfold, the individual elements needed to support them will be identified. Specialists can then be assembled and assigned to elaborate each element. This requires coordinating with the Manage Technical Architecture Activities to incorporate element definition activities into the Technical Architecture Work Plans and Directions.
- Integrate, Review, and Publish Draft. As the application and overall system structures become defined, they can be reviewed and released for others on the Architecture Team to use. They are used to guide the elaboration of the individual elements, helping to assure they integrate. As elements are detailed, changes of the integrated descriptions can be made, as needed. The integrated descriptions and the accompanying element descriptions are released together as part of the activities to Integrate, Review, and Release the A-TARS.
When necessary, the team members can Conduct Architectural Studies to determine design parameters, such as expected performance.
Update Integrated Technology Descriptions. The integrated technology descriptions serve as a blueprint to the rest of the A-TARS. These descriptions must therefore be kept consistent with the lower-level building block descriptions. This occurs when either the application or system structures change or the underlying elements change as new technologies become available or are retired, such as moving from component to Web service derived application models. Changes must be evaluated, and the appropriate portions of the A-TARS must be identified and modified.

Top

Roles and Responsibilities

The key roles and their responsibilities for these activities are:

Technical Architecture Team. These individuals are responsible for producing the integrated design descriptions. The team members must have firsthand experience with the application models and system design structures they propose. Outside experts (consultants) or individuals from the project teams can be enlisted to provide this experience. The Chief Architect has a significant responsibility in determining, reviewing, and approving the design approaches.

Top

Artifacts

The following information is used or produced by these activities. Templates, examples, and checklists for identifying and documenting items are available through the Additional Resources section at the end of this page.

A-TARS. The previous version of the A-TARS (if it exists) is used to determine the scope of the changes for an iteration of these activities. The following key parts are used:
- Agency-Wide System Properties. These properties are used to guide the design. They must be satisfied for the design to be approved.
- Technology Boundaries Descriptions. The descriptions of the usage environment guide the design of the types of platforms, their capabilities, and the interconnectivity needed.
- TRM Description. This description guides the decisions on the application and system structure by indicating the types of technologies that need to be considered.
- Integrated Technology Descriptions. These descriptions are the main product of these activities, updating the previous version (if it exists). Draft descriptions are used by the Technical Architecture Team to identify the elementary building blocks to be elaborated.
Technical Architecture Work Plans. These work plans guide the execution of these activities, coordinating the individuals performing these activities with other Technical Architecture tasks and the IT projects.
AIS Design and Implementation Info. An understanding of the existing technology is used when defining the application or system architectures, especially if the legacy systems will be retained in the next version of the A-TARS. This provides a ready source of detailed design information, such as interface documentation.
Strategic Analysis and Data. The strategic direction, specifically the decisions to keep, replace, renovate, or build on existing IT assets, guides the choice of technology and the integration of legacy system applications into the overall Technical Architecture.
Changes - Changes provided to these activities represents those things in the current integration descriptions that must change. Changes for other parts of the A-TARS also can be generated, such as updates to the services, data stores, equipment, or networking.
Ancillary Design Information - Information associated with the design is retained, as needed, such as results of architectural studies that trade off design approaches. This information may be used to produce guidelines that users of the integrated descriptions can reference.
Status. Progress and issues in developing the integrated descriptions are forwarded to the Manage Technical Architecture activities to ensure coordination between these activities and other Technical Architecture and IT project activities.

Top

Additional Resources

Items that can be used to perform these and other activities are consolidated in the Resources portion of the IT Planning and Management Guides. Resources specific to this activity are cataloged below.

Consolidated Guidance: Describing the Integrated Technology
Some general guidelines on preparing and managing the descriptions. 9/04/01

Top