Inventory Management

In most organizations, the application inventory is large, complex, and always changing. Today's applications have graduated beyond standard source to include a wide variety of components -- most outstripping traditional 80-character storage limitations.
18-0
 
In most organizations, the application inventory is large, complex, and always changing. Today's applications have graduated beyond standard source to include a wide variety of components -- most outstripping traditional 80-character storage limitations.
In addition to the changing complexion of the inventory's physical structure, there is a growing proliferation of physical libraries and functional environments (Test, QA, Production, and so on). Programmers and IS support personnel typically require intimate knowledge of those library structures as they relate logically to business units within an organization.
This logical view, divorced from the physical storage structure, is required to ensure that logically related inventory elements are being manipulated consistently and correctly, and to provide a common user interface regardless of physical structures. An effective inventory management structure also forms the foundation for change control, configuration management, and release management activities.
2
Automated Inventory Manager
Traditional software classification systems (PDSs, library management systems, and so forth) provide limited inventory classification capabilities and highly restrictive methods for storing and recreating prior versions of software modules.
When using these traditional systems, IS departments resort to complex naming conventions and physical separate libraries to obtain a semblance of organization. This indirect naming and storage technique is error-prone and inflexible.
Consequently, as programmers move from project team to project team, they are forced to learn and relearn the peculiarities of manipulating the software inventory as applied by each project team. Clearly, a common technique is required for classifying software throughout the IS organization, one that provides consistency and flexibility.
Logical Structure
Endevor
employs advanced classification techniques that form the necessary foundation for categorizing, viewing, and manipulating the application software inventory in a consistent manner. An inventory item (element) is identified to
Endevor
's Inventory manager by a fully-qualified name consisting of its environment, stage (location), system, subsystem, type, and element name.
  • Environment, Stage
    As an application is modified and its elements are moved throughout the software development lifecycle, those elements may reside in different functional locations (Test, QA, Production, Backup, and so on) at different times. Within
    Endevor
    's inventory classification scheme, the location of an element is part of the identification of that element.
  • System
    Systems represent the logical grouping of inventory elements as they apply to major applications, departments, or work areas within an organization. Typically, a system is the "organizational owner" of a portion of the inventory. For example, the systems in an organization might include Finance, Personnel, and Manufacturing.
  • Subsystem
    Subsystems are logical sub-classifications within systems. For example, the Finance system might be divided into logical subsystems such as General Ledger, Accounts Receivable, Accounts Payable, Common Routines, and Reports.
  • Type
    Within the application inventory, types represent the form of the element, indicating how the element is created (the source language used) and how it is manipulated. For example, the Finance system might have several types of elements, including COBOL programs, Assembler programs, C programs, PL/I programs, copy members, Assembler macros, screen definitions, and linkage editor statements.
  • Element Name
    The element name is the existing name of the element because it is already established. This logical classification scheme, as illustrated in the following diagram, provides a consistent view of the inventory without requiring the user to understand the inner workings of the inventory's physical structure.
Logical Structure
Logical Structure
In
Endevor
, the logical attributes, which are used to classify an element, include its location, system, subsystem, and type. These attributes are a direct part of the identification of that element. This eliminates the need to establish additional libraries, rename elements, or use cryptic naming conventions to define and maintain a classification scheme. Because these classification attributes are used in addition to the existing element name, there is no need to rename elements to bring them under the control of the
Endevor
Inventory Manager.
Physical Structure
In today's IT environment, the physical requirements of a properly managed inventory have grown beyond the capabilities of older library management systems and conventional PDS-based systems. Many library management systems are unable to store source that is longer than 80 characters, despite the fact that many modern-day languages do not conform to this format.
Conventional PDSs do not restrict record length, but elements of different record lengths must reside in physically separate libraries. Using these structures, the only way to keep multiple revisions of an element is to replicate libraries to hold prior revisions or use a naming convention in which the revision is part of the element name.
  • Physical repository
    Endevor
    's Inventory Manager has the flexibility to manage the physical data sets in which elements are stored, without regard to logical classification boundaries or trivial physical differences between the inventory elements. It can do the following:
    • Handle unrestricted source record lengths
    • Store elements of different record lengths in the same repository
    • Store multiple revisions of an element in a single repository
    • Store elements of the same name in the same repository, regardless of differences in logical classification
    • Change the underlying physical library structure without affecting the logical view of the inventory
  • Base and Delta
    Endevor
    employs advanced base and delta technology to store the elements within the application inventory. The first time an element is added into
    Endevor
    , it is stored in its entirety as the base. Subsequent updates to that element create records containing only the changes to the element. These deltas are automatically assigned level numbers and stored by
    Endevor
    , as shown in the following illustration:
Physical Structure
Physical Structure
This method yields substantial savings in storage overhead by providing an efficient means of storing multiple revisions of an element. It also provides a wide variety of ways to view change information, including current, historical or changes only, available online or in hardcopy format. All change displays identify what changes were made and by whom, when and why. This is known as the forward delta format. Reverse delta format processing is similar; however, the delta source is kept in the current format and deltas are used to recreate prior iterations of the source.
Interfaces to
Panvalet
and
Librarian
Interfaces are available that allow
Endevor
to read directly from and write directly to
Panvalet
and
Librarian
files. Additionally, these interfaces allow you to use
Panvalet
and
Librarian
files to contain base/delta source within
Endevor
. In this way, your initial investment in library management systems is enhanced rather than rendered obsolete.