Consolidated Guidance: Describing the Integrated Technology

Synopsis

The integrated technology descriptions provide the highest level design of the application structures and the processing configurations on which applications will run. Lower-level, more detailed parts of the A-TARS elaborate these elements (the building blocks) as needed to specify their detailed design characteristics. This document provides some suggestions for what to consider when documenting the high-level integration schemes.

Guidelines

• The primary purpose of the integrated descriptions is to show the synthesis of the design elements, where each element is a fundamental building block specified elsewhere in the A-TARS. Each element should therefore be uniquely identified, allowing it to be traced to its descriptions. The major types of elements that will be identified are:
  • Platforms, including programmable client and server systems, as well as nonprogrammable information appliances or other special purpose devices (e.g., cell phone, PDA ). Platforms may be generic (an Internet browser-based platform) or vendor-specific when constrained to existing legacy systems.
  • Interconnections, such as cable or wireless-based networking and associated communications or networking devices.
  • Data sources, such as structured or unstructured data repositories (relational databases, flat files, Web content).
• Often architectural descriptions rely on pseudoformal diagrams to communicate the system and application structures. These diagrams may be based on an ad hoc notation of boxes and arrows. Tools and notations such as those provided by the Visio® toolset or based on UML ( Booch, Rumbaugh, and Jacobson 1999 ) can be used to render the descriptions to make them less ambiguous. Regardless of the notation chosen, its semantics should be carefully described. For example, does a line on a diagram indicate control flow, data flow, or both, and in what direction; is a box a module or a process or machine boundary? If the notation is ambiguous, then descriptions of the diagrams may be necessary to ensure they are not misinterpreted.
• The application and system structures should be as vendor-neutral as possible. Include them only when constrained to a specific implementation. For example, is a Win32 platform required or just an HTML V4.01-compliant browser? Leave as much discretion as possible to those that implement the architecture elements, allowing for them to meet price/performance/functionality tradeoffs. When necessary, use architectural studies of vendor products to specify representative design parameters, such as expected transaction performance available from the Transaction Processing Performance Council ( TPC 2001 ).
• The design should incorporate the essential properties defined early in the technical architecture process (see the Establish Agency Systems Properties activities). Perform simulation, inspection, test, or analysis to ensure that the design supports these properties. Allocate all or part of these properties to the individual elements to achieve the overall system value, such as availability for a web server to ensure total system availability.
• The IT Strategic Plan and associated data is a controlling document governing the design approach. You should assess the architectures against the plan's strategic objectives.
• The overall technical architecture addresses long-range (strategic) objectives. Short-term accomplishments (3-6 month plateaus) allow for the agency to move toward these objectives. Each version of the A-TARS corresponds to one or more plateaus. Scaffolding may need to be designed and constructed to bridge between plateaus. For example, when a legacy system will be retired within the next 2 years, Enterprise integration techniques may be used to abstract and encapsulate the application services without modifying the legacy system programs, while its COBOL applications are slowly migrated to another (e.g., EJB ) implementation.
• When preparing this portion of the A-TARS the following individuals or groups are primary users of this information.
  • Specialists on the Architecture Team. To establish context for defining the individual building blocks for which they are responsible.
  • System Designers. To identify the specifications for the technology elements and how they will be connected for the application systems they design.
  • Procurement. Provides minimum criteria to identify and procure compliant products, such as a Web server.
• The TRM (produced by the Establish Agency Technical Reference Models activities), and the boundaries descriptions (produced by the Describe Technology Boundaries activities) can help to identify the types of application level and platform services that should be provided for each processing configuration. These become the high-level functional requirements for the design of each platform, and may drive (and be driven by) the technology selected to support the application architecture.
• Write the descriptions to reflect their main purpose and to show how the technology elements work together. Include details of each element's design in the lower-level building block descriptions, referenced from these higher-level descriptions. Additional guidance or background information can be compiled and used when enacting the Develop Technical Guidelines activities. Guidelines for the integrated descriptions should help the reader understand the rationale behind some of the design decisions.

Top