Checklist - Establish the IT Inventory

Synopsis

When analyzing the situation or evaluating the Current IT capability to identify improvement opportunities or gaps, insight into the IT and it's use will need to be collected and organized. The focus is on quickly representing the types of technology that is in use, how much of it exists, and who uses it and where it is used. This data is therefore at a summary level, with details provides only to address specific strategy related issues when needed.  The following checklists can guide this collection process.

Business Area/Function Characterization

	Collect information about the environments in which the Agencies Automated Information Systems (AIS) as used, built, or maintained. This includes the program usage environments (case workers and managers/supervisors for the TANF program), the development environment (system developers and management), and the operational environment (operators, help desk).
	The characterization provides the architecture and program teams the ability to identify critical environmental drivers that influence the AIS design characteristics as the IT evolves. Example considerations are training, labor shortages, union obligations, and so forth.
	The business data that is collected may be readily available from published documents. Specific data in those documents should be referenced and not replicated. If the documents are available online, you may wish to employ hyperlinks. Because some of this information may be business sensitive, ensure that those that need to see it (the core Strategy Team or the Architecture Development Team) have adequate access.
	Because documentation may be out of date, all data should be validated with senior, middle, or operation level management to make sure that it accurately describes the current situation. Note any discrepancies.
	The amount of detail put into the description can vary, but initially simple lists with one-line descriptions should suffice
	State the complete (i.e., formal) name and abbreviations for the HS Agency function (e.g., program) or organization
	Describe the mission for each organization, including the reason for the organization's existence. Include the products, services, and markets. This may be available directly from the organization's senior or executive management.
	Identify key processes or activities performed by individuals within the function. For each key process, describe key characteristics of workflows and interfaces with other internal or external manual or automated systems. Identify the key actors (human or automated) that take part in these processes.
	Identify the key locations or settings in which the activity is performed. This may include the office, home, mobile, customer sites, or global locations. An organizational directory or phone book may help identify these locations. This may help identify general system needs for internationalization, security-privacy, robustness, etc.
	Identify the key customers or users of the products and services. These may be direct or indirect customers or users. For example, individuals at home may execute the applications via a browser on the Web to place orders - in this case they are both customers, and users of the information technology
	Identify the key suppliers used to create or deliver the products or services. For IT support, this may include vendors and mechanisms to update purchased products or applications, such as updates through the Web
	Identify the major competitors or threats internal and external to the function. The actions of competitors may influence the features/functionality of the migrated AIS's and the deployment schedule.
	Indicate how large an organization is affected. Smaller organizations may be able to endure a more rapid change. Include organization charts showing staffing, if available. Measures may be based on headcount (permanent - full time, part time, consulting). You may wish to classify these individuals into the types of roles they perform.
	Note any characteristics about the available budget or budgeting process that may affect the deployment or maintenance of the migrated systems.
	Identify any time-specific aspects of the function that affects how it operates, such as periodic audits or reports, business cycles (holiday shopping, customer budgeting), mergers, consolidations, etc. These time lines could influence when and how the migrated systems are deployed.

Data Inventory

	Collect information about the data used or stored in databases or files to support each function. Usage includes all data processing primitive operations (create, read, update, delete). Although the emphasis is on electronically stored data, key manual data stores can be described. Note interfaces between functions that share data.
	Provide the unique identifier, full (formal) name, and abbreviation for the data store
	Provide a short (one sentence) description of the contents.
	Provide a list of the key entities maintained in the stores (e.g., client, order, product)
	Note which function/organization has administrative control over the store.
	Describe the type of data store, and the database management system or file system technology used to access the store. State these in product-neutral terms if possible, such as relational, hierarchical, networked,  flat file, etc. Products should identify the common name for the technology used to reference the store, such as a commercially available DBMS. Include version-specific information for the store or access software. Identify any standards or conventions that are followed to describe or access the data.
	Identify and characterize the computer platform on which the data resides. This may include the type of computer (PC, mini, mainframe), model type, operating system, network address, or type of media (e.g., RAID, CD, DVD, floppy).
	Note the geographic location where the data store resides. Include replicas.
	Provide additional information to characterize the data, including how the data is accessed or administered.  For example, note sensitive data or approximate transaction rates (min, max, average).
	Identify the documentation consulted, if operational data stores can be examined; include version numbers.
	The characterization should be validated by those familiar with the data content (e.g., Database Administrator).

Application Inventory

	Collects information about each application used to support the Business Area/Function (e.g., the three environments - TANF users and management, development, and technical operations). Include function specific applications as well as support applications (e.g., office productivity tools).
	Include the full (formal) name, any abbreviations, and current version number for the application so it can be uniquely identified.
	Briefly describe what the application does and how it is used.
	Identify the major data stores that the application manipulates, either creating, reading, updating, or deleting. Use the exact name indicated in the data characterization sheets.
	Provide the approximate number of users of the application. If the number of users changes with the business cycle (e.g., holiday or summer periods), then also characterize these differences
	Identify the computer platforms on which the application executes. Include the operating system environment and any other unique aspects of the platform that the application depends upon to operate (e.g., a forms package, database query preprocessors, graphics packages, internet Web browser, etc.)
	Identify the date when the application was first released into production. This is a good indicator of the overarching design decisions embodied in the application (e.g., coding of dates or use of limited memory or disk).
	Indicate how many versions of the application have been made since the original release.
	State the number/magnitude of changes over the past year (e.g., number of modules, Source Lines of Code, problem reports, or other measure). State the approximate number of changes since the initial release. This gives insight into how much this application has to be adapted.
	Characterize the overall quality of the application in as objective a measure as possible, such as the number of operational failures that have been attributed to the application (e.g., crash, had to be restarted, returned incorrect results).
	Approximate size of the application in source lines of code, function points, modules, or some other measure. As size measurements are language and counting tool/method specific, this should only be used to get the relative size for comparison reasons. If size cannot be easily estimated, a scale with guidelines for small, medium, large, very large can be used.
	The organization or company that developed / supplied the application, and those that maintain/support it after initial delivery.
	Note the geographic location where the application is accessed.
	Identify the documentation consulted. This may include design specifications, test records, change control information, or quality records.
	The application characterization should be validated by someone familiar with the applications, such as the programmers responsible for maintaining them.
	Identify any Standards that were the basis of the applications design or functionality. This is needed when one considers that some applications may have been built to guidelines long since retired.

Technology Inventory

	Collects information about the types of platforms in use across the Business Areas/Functions and the technology they currently support. This includes the platforms used to conduct TANF functions as well as develop and administer the systems (e.g., engineering workstations).
	This information may be directly  available from configuration management records. All details of the platforms do not need to be cataloged. The purpose is to form an impression of what existing platforms are capable of and how much they may need to be upgraded to support any migrated functionality.
	For platforms that a decision has been made to retire, information on those may not necessarily be needed. They should be noted but not described.
	To reduce duplication, this data can be collected at the same time the applications are inventoried and cross-references made to operating environment information
	For each distinct type of platform, provide a unique identifier. Platforms may be generic, or specific to a particular role. Role-specific platforms may build on a generic platform. For example, a standard PC and basic application suite may be issued to all caseworkers, with additional applications or devices depending on use (e.g., multimedia capabilities). Possible technology platforms are: User workstations Peripheral servers Local/wide are network equipment Application servers Data servers Specialty processors (e.g., graphics)
	Indicate the number of platforms and their type at a geographic location
	Describe the general processing capabilities of the platform, e.g., multimedia, video, average disk available, available memory, LAN connectivity, CPU Mhz, etc.
	This is similar to the application inventory, sorted by technology platform. Identify the basic services available and the standards that describe their implementation. The intention is to begin to qualify the basis upon which the existing platforms and applications have evolved, even if in an ad hoc manner.

IT Costs 

	Collects information about the total life-cycle costs associated with the development and use of IT. These costs are part of the analysis to determine the near-tem disposition of the applications and platforms, judging the investment.
	Separate costs into categories, such as development, operations, management, contract oversight, change/problem report, maintenance, purchased software, licenses, etc. This provides fidelity into identifying cost drivers.