Consolidated Guidance: Describing the Platforms, Equipments, and Solutions

Synopsis

The descriptions of key or unique platforms, equipment, and prepackaged solutions allow the architects to manage the proliferation of the system building block configurations and to define standard automated configurations and their constituent parts. This helps IT projects plan life-cycle acquisition, use, and retirement of the system elements. This document provides some suggestions for what to consider when creating and updating these descriptions.

Guidelines

• Consider the user of the information when deciding what to include. The following individuals may use the descriptions:

  • System Designers. These individuals refer to these descriptions for standard configurations to incorporate into their designs.

  • Procurement Specialist. These individuals refer to these descriptions when purchasing compliant, commercially available items or developing specifications for contracting the development of custom items.

  • Quality Assurance. These individuals confirm that the items used on the project conform to these descriptions.

• Consider all three usage environments .

• Consider items already in the Enterprise's inventory, such as programmable and nonprogrammable platforms, devices, networking, interfaces, and prepackaged applications and components. Reference descriptions of existing inventories, such as legacy computer systems or key parts (e.g., applications, components, and data sources) that are being adopted as part of the overall technical architecture (see strategic planning Analyze the Situation activities). The Services , Data Sources and Business Rules , or Networking Reference Sets may reference items here as preferred (but not mandatory) implementations.

• The items described here should cover the types of processing elements and equipment identified in the Integrated Technology and Technology Boundary descriptions.
• Include growth and adaptation requirements in these descriptions. This may include characterizing the minimum, maximum, or typical processor speed, memory, peripherals, or configurations to be supported on a future platform by consulting vendors.
• In some cases, specific vendor software or hardware products may be ubiquitous throughout the Enterprise. Document the essential characteristics of these products (e.g., file format for an office application suite, style of user interface, or API ). Identify preferred vendor products (or existing enterprise implementations), when necessary. Separate technical considerations from commercial. Provide guidelines on how to use or build on top of commercial products to limit the risk of vendor lock-in (e.g., hiding a product behind an Agency-defined interface).
• Consider characterizing these two general types of platforms or equipments:
  • Programmable. These platforms are flexible to allow custom or commercial application software to be designed and loaded onto them.
  • Limited-programmable. These platforms have limited or no capability to load custom software (e.g., information appliances , network equipments, UPS , PBX ). This type also includes legacy systems that are encapsulated and treated as abstract services (i.e., on their way to retirement where limited maintenance will be performed).
• Consider the following when describing the equipment and /or platforms:
  • Unique platform classification (e.g., small desktop, engineering workstation, point-of-sales terminal, personal information device, kiosk, application server, Web server, or data server)
  • Processing technologies (e.g., CPU types (32/64-bit), clock speed, and benchmark ratings)
  • Input/output technologies (e.g., legacy I/O devices, USB , digital TV/video, touch screens, audio, printers, displays, scanners, voice, and touch panel)
  • Local storage (e.g., memory, DASD , DVD , RAID , and CD-RW )
  • Physical characteristics (e.g., size, weight, durability, hot swappable, and power consumption)
  • Expansion capabilities, utilization margins (e.g., free processor slots, CPU utilization, and disk utilization)
  • Other essential peripheral devices, interfaces, and essential characteristics (e.g., mouse, keyboard, monitor display dimensions, bus)
  • Standards that apply to the elements and how they have been adapted, referencing (or adding to) the Agency Standards Reference Set, as needed
  • Reference implementations, as necessary, to illustrate typical configurations
  • Ranges or options that can be configured and default settings
  • Likely changes (e.g., merging technology, shifts in price/performance, competition, and declining markets)
  • Quality factors (e.g., warranties, reliability, availability (hot swappable components), usability, and upward compatibility). You can deduce these from the systems properties allocated to the item (see Establish Agency Systems Properties activities).
  • General guidelines (e.g., configuring, purchasing, maintaining), which you can provide here or reference in the Technical Guidelines portion of the A-TARS
  • Expected useful lifetime and evolution strategy (upgrade, retire).
• Consider the following when describing the prepackaged solutions.
  • Minimize references to a specific product to only the most essential few. When practical, reference the features or characteristics of the product that are of interest and note the vendor implementation as an instance. As vendor products change, evaluate the need for the features and determine whether they are essential. Provide guidance to help application designers limit how tightly they integrate products into Agency-wide solutions.
  • Provide guidance for how applications are built using these solutions, especially if the products allow programming (e.g., VBA for office products). Provide guidelines to manage how tightly coupled an application can be to a vendor's programmable product.
  • Consult the descriptions from the inventory compiled during the Analyze the Situation activities, noting which applications will most likely continue to be effective in the future.
  • Services that are described in the Services Reference Set (see Describe Services activities) may assume these prepackaged solutions. Note these assumptions in the service descriptions.
  • Reference and make available documentation such as user, reference, operating, installation, maintenance, or other guides, if necessary.
  • Identify any configuration options that should be taken.
• For all the descriptions, consider including the following information:
  • Identify the standards upon which the items are described, such as those for devices or networking from the IEEE . This includes any adaptation the Agency has made. The list of standards and how they are to be used can be compiled within the Standards Reference Set , and referenced from each description.
  • When necessary, preferred implementations can be suggested.
  • Provide any expected modifications to the definitions and the expected timeframe. This is particularly necessary for early adopters of a technology, especially if the basis for the description (the standards) is still under review or multiple, competing implementations are struggling for market share.
  • Specify guidelines to help ensure conformance to the definitions.
  • Reference the specific instances of source documents (e.g., vendor materials) that provide insight into the definitions.
  • The descriptions should be formally reviewed before finally approved. Techniques such as Peer Reviews ( CMU SEI 1995 ) can be used to structure these reviews. Individuals representing the users of the descriptions should attend.
  • Changes to the any part of the description need to be evaluated to assess impact to the applications implemented to the description, such as maintaining backward compatibility when a new version of a platform is provided.
  • Place all descriptions under change control, allowing for different versions of each description to be tracked (e.g., upgrading a platform or its equipment, while retaining the previous version's description).

Top