RFP_Attachment_04_-_Technical_Data_Package_(TDP)_Base_Document.docx

IMLCI RFP Attachment 4 – TDP Base Document AFLCMC/HIAR Requirements System Section

Wright Patterson AFB, OH 45433-5006

TECHNICAL DATA PACKAGE

For Item Master Logistics Capability Initiative

(IMLCI)

Solicitation Number FA8770-20-R-0004 21 July 2019

Table of Contents

Introduction This Technical Data Package (TDP) is a collection of all information needed to understand the business and technical architecture of the Item Master Logistics Capability Initiative (IMLCI).

The six main sections to this TDP are Introduction, Mission Description, IMLCI Capabilities, Contextual Model, Application Delivery and DevSecOps Management, Hosting/Infrastructure Requirements, and TDP Attachments. The Mission Description and Contextual Model, Bounded User Requirements describe the functionality and business capabilities of IMLCI. The Application Delivery and DevSecOps Management Section summarizes the Technical Management Approach to product development and release. Hosting/Infrastructure Requirements section describes the Cloud Computing Service Requirements. The TDP Attachments section contains reference materials and standards, cited in the requirements List, providing compliance requirements and guidance to support Product, Security and Auditing readiness and compliance.

Mission Description System Name and Identification IMLCI provides the Air Force (AF) enterprise with a capability to generate and manage comprehensive, accurate, and reliable item specific data within the AF Logistics enterprise. It will provide enterprise users with the breadth and depth of accurate item data necessary to support and enable dependent processes, initiatives, programs and transformational concepts.

The IMLCI is a Business System Category II program and follows all phases of the Business Capability Acquisition Cycle (BCAC) using an Agile approach for acquisition, development and deployment as discussed in Department of Defense (DoD) 5000.75 Business Systems Requirements and Acquisition.

The list below outlines the high level rationale for IMLCI:

· The management and accuracy of Item Master data required attention. Specifically, problems centered around the following:

· No single source for Item – various definitions of the truth across legacy systems

· No clearly defined Item structure and Item definition

· Inability to provide a complete Item record to stakeholders

· Lack of stakeholder coordination for Item record changes

· Absence of Item record configuration management

· The IMLCI has been developed to create a single authoritative source of item data for use by all AF logistics systems. IMLCI will:

· Standardize data attribute formats and definitions

· Provide configuration management to AF item data

· Deliver a flexible technical solution, readily adaptable to the changing business needs of the logistics enterprise

· Specific capabilities of IMLCI include:

· Receipt of engineering technical data from Product Lifecycle Management (PLM)

· Adding Logistics Management Information to the engineering content

· Providing standardized item data to other logistics business areas supported by Logistics Capability Initiatives (LCI) and legacy applications throughout the logistics enterprise, including:

· Enterprise Supply Chain Analysis, Planning & Execution (ESCAPE)

· Supply Chain Management

· Maintenance, Repair and Overhaul initiative (MROi)

· Field Maintenance

· Munitions

· AF Working Capital Fund Air Force Logistics Information systems are aging and disparate. Prior efforts to upgrade the full array of logistics capabilities all at once were unsuccessful. To address these issues, HQ AFMC/A4 launched the A4 LCIs to enhance logistics capabilities and associated information systems in a standard incremental approach.

System Description IMLCI establishes a standardized AF Item Master structure which includes metadata requirements, data architecture and flow, cognizant authorities and standardized reporting. It supports Bill of Material (BOM) management, maintenance programs, and item supply chain data by enabling Item Unique Identification (IUID), congressionally mandated Financial Improvement and Audit Readiness (FIAR) readiness and compliance, and In-Transit and Total Asset Visibility (ITV/TAV). See TDP Attachment IMLCI 101 Brief (4.A) for more information on the Problem Statement, Transformation, Future State and other Capability Initiatives.

IMLCI Capabilities: Item Standardization, Item Configuration Management, Single Authoritative Source Item Standardization Item Standardization provides the normalization and transformation of Item cataloging and provisioning processes, structure, and content for all applicable item types. Item types include but are not limited to: National Stock Number (NSN), BOM, Logistics Bill of Material (LBOM), Foreign Military Sales (FMS), Non-definitive (ND), Kit, Software, etc. Additionally, this expands the total number of records used in sustainment to include the non-stocklisted/non-cataloged items required for a specified level for repair and capacity to include all future acquisition items.

Item Configuration Management Item Configuration Management capability provides consistency of item product structure, attributes, propagation, and standardized views through a single organization comprised of logistics enterprise experts, and coordinates item changes with all affected AF Logistics stakeholders.

Item Authoritative Source IMLCI provides a single authoritative Item Master record to the AF logistics enterprise and allows for enhancement of the Item record (new attributes). This will include changes and improvements to item content, classification and business rules; while providing capability and flexibility to support future item requirements and types.

Contextual Model (Bounded User Requirements) The Contextual Model describes, in functional terms, the Item Master business processes supported by a Material-Solution (M-Solution). These models place into context the activities associated with delivery of discrete capability. In particular, these models:

· Provide the context for understanding and applying the Functional, Lifecycle Support, and Technical Requirements

· Identify the high level roles required to execute each activity

· Depict the flow of information (Information Assets) between activities within and external to the proposed M-Solution

· Serve as the Functional (customer) business baseline, from which all detailed models are derived and associated.

Business Process Models and Activity Descriptions Process models with associated activities were developed to demonstrate the required capability.

· Item Master Process Descriptions: The Processes describe each model, summarizing the key business functions depicted on the Contextual Model charts. See TDP Attachments for process models and descriptions:

· 4.B - ManageItemMaster

· 4.C - ManageItemMasterAssistanceRequest

· 4.D - AssignManagementInformationToIM_ARLineItem

· 4.E - ManageFederalCatalogAction

· 4.F - ExecuteProvisioning

· 4.G - ProcessNames Item Master Activity Descriptions: The Activities describe the behavior of each step in the models from a functional perspective, explaining the business requirements in terms of the processes they serve. See TDP Attachment for activity descriptions (4.H - Activities) Data Reference Model The Data Reference Model (DRM) identifies the Information Assets, conceptual data structures, and roles required to implement the M-Solution; these information requirements outline the “data” structures and concepts captured in the Contextual Model, requirements workbook, and related artifacts.

The vocabulary worksheet lists:

· The Information Assets and definitions (4.I - InformationAssets)

· All data elements and definitions (4.K - TermsDefinitionsAcronyms)

· Specific data structures (Info Assets + elements) with high level business rules and notions around use

· A simple Create, Read, Update, Delete Matrix by Info Asset

· Business Level description of the Roles and Permissions See TDP Attachments for the DRM:

· TDP Attachment Data Reference Model (4.J - DataReferenceModel) The diagram below depicts the relationship of the Information Assets.

Figure 1: Information Asset Relationships Wire Diagrams – Exchanges and Interface Layouts The diagrams below reflect the planned interface work to support IMLCI Minimum Viable Product (MVP).

Figure 2: High Level Wire Diagram

Figure 3: IMLCI Inbound Interfaces

Figure 4: IMLCI Outbound Interfaces The interfaces documented above represent only the as-is interfaces with the existing cataloging and provisioning system and are subject to updates with the IMLCI implementation. The documented interfaces with AFEMS will not be implemented as AFEMS has been sunset. There will be additional interfaces implemented with other systems under development but the implementation details and projected schedule are currently undetermined. See 4.L - InterfaceInformation for additional information.

User Base

Figure 5: End User Stakeholders Information Technology Functional Requirements (ITFRs) User requirements have been documented into ITFRs. ITFRs are statements that define activities and capabilities from a functional perspective. As part of the Agile process, ITFRs align to Epics, Features and User Stories and have been written in functional terms to describe the desired behaviors of the transformed business processes. Stories and related requirements will be prioritized during the Sprint planning process; features and product capability will be iteratively developed and tested and released incrementally.

Refer to the IM ITFRs tab, of the Requirements List (RFP Attachment 3) for more details.

Information Technology Technical Requirements (ITTRs) The ITTRs for IMLCI identify the technical criteria to which the system must comply. ITTRs focus on Enterprise Architecture Infrastructure, information assurance, auditability, performance, design, interfaces, and reporting.

In concert with policy and legal directives, the Technical Requirements identify the constraints, boundaries, and minimally acceptable criteria to which the M-Solution must comply. These statement address topology, infrastructure, distributed computing, and compliance.

Refer to the IMLCI ITTRs tab, of the Requirements List (RFP Attachment 3) for more details.

Lifecycle Support Requirements (LSRs) IMLCI uses LSRs to describe the core competencies and services required to meet business standards defined by the functional community. Overall, LSRs address the general system “ilities” or concepts: Maintainability, Re-configurability/Adaptability, Scalability, Implementability, Data Management Flexibility, Reusability, and Usability.

At the operational level, LSRs define the fundamental technologies around access control, the business rule engine, the data exchange framework, solution architecture and user interface business concepts.

Refer to the IM LSRs tab, of the Requirements List (RFP Attachment 3) for more details.

Laws, Regulations and Policies (LRPs) Refer to the LRP tab, of the Requirements List (RFP Attachment 3) for details governing the constraints of the IMLCI Solution.

Minimum Viable Product (MVP) and Product Roadmap The IMLCI vision includes:

· Item standardization and configuration management from a single authoritative source, ensuring foundational logistics processes are executed in concert to support the A4 logistics baseline.

· Enables key integration and transformation capabilities such as Item Unique Identification (IUID) associations to business transactions

· Streamlines management of part item attributes across supply, finance, engineering, technology, transportation, maintenance, and vendor communities; provides translation capabilities between functional and technical business communities and systems

· Supports End User experience that is intuitive, requires little to no user training, Functional Team management and control of business rules, data configurations/data validation values, and exchanges (Turbo Tax model), simplified issue, bug, and enhancement reporting mechanisms built into the tool

· Tying the “Logistics Tail” to Product Configurations

· Enables enterprise wide features such as: FIAR; Serialized Asset Control and Management; Total Asset and In-Transit Asset Visibility; Defense Logistics Management Standards (DLMS) Integration and Compliance; Delivery of Master Configurations and Unit Configuration Support; Streamlined Provisioning and Cataloging Management at the service and Federal levels; Supports Improved Demand Forecasting and Purchasing Accuracy; Enables Condition Based Maintenance Plus (CBM+) Scope (MVP Release1 (R1))

· MVP – What:

· Establishes a full Item Master Catalog and Parts Provisioning capability

· Includes subsumption of legacy mainframe Parts Catalog functionality

· Addresses the legal constraints of 1 catalog per Service/Agency

· MVP – How:

· Implements an enterprise Platform as a Service (PaaS) and/or Infrastructure as a Service (IaaS) model as a federated architecture foundation (Release 2 (R2) and beyond)

· Use of SaaS and/or PaaS components to address business needs (i.e., Functional and Life Cycle Support Requirements); use of a cloud-managed service (an IaaS) to satisfy technical requirements

· Uses a risk reduction mindset, cost and schedule impacts through phased incremental builds that maximize investment dollars

· MVP – Why:

· Enables Item of Supply, e.g., NSN, access in a modern tool suite

· Focuses on service re-use within and across DoD components and other Service/Agencies

· Complies with the requirement to have one AF Item Catalog MVP Determination

· Implement a small, manageable, R1 Scope; roughly 20% of total IMLCI vision

· Begin with the end in mind

· Item Master as a finished product ties the Logistics Tail to Product Configurations

· This occurs only after the core legacy Parts Catalog and over-arching cataloging/provisioning processes have been re-architected into a new tool

· Based upon a BCAC Limited Deployment Decision (LDD) Analysis, outlining the MVP Options

· Assesses the logical, technical and legal constraints associated with deployment Roadmap The figures below outline the IMLCI Product Roadmap - Release 1 and Release 2+ Figure 6: IMLCI Product Roadmap

· Release 1 is IM Core (MVP)

· Release 2+ is IM Core + BOM, IM Core + Future (Total IMLCI Vision) Legend:

· Blue identifies functional business capabilities

· Grey denotes supporting features/functions that enable the business capabilities

Figure 7: Release 1 – Item Master MVP

Figure 8: Release 2+ - Full IMLCI Vision example Application Delivery and DevSecOps Management Application Delivery and DevSecOps Overview IMCLI has been mandated to host our production environment with the Common Computing Environment (CCE), which has been rebranded to CloudOne, but for the purposes of this document CCE has been used throughout. IMLCI has also been directed to implement an Application and Development Security Operations (DevSecOps) Continuous Integration/Continuous Delivery (CI/CD) pipeline. Refer to Section 6 for additional hosting details.

The Integrated Program Office (IPO) intends to pursue a multi-pipeline approach to implementing Application Delivery and DevSecOps over the lifecycle of the IMLCI program. Pipeline builds and integration will occur as part of Agile Epic/Story process; components will be built in conjunction with the technical and business needs iteratively, in accordance with the solution architecture roadmap. Pipeline components will include, but not be limited to, the following constructs:

· Commercial Off The Shelf (COTS) Application Delivery pipeline

· Custom Code Delivery Pipeline

· Database/Data Storage Delivery pipeline

· Extract Transform and Load (ETL) Delivery pipeline Solution development will include 2 phases: Product Build and Assemble; Product Delivery and Test.

Product Build and Assemble

· In this development phase, each pipeline will account for the following “build and assemble” states: Build, Deploy, environmental changes, Unit Test, System Test, Artifact Ready for Storage.

· Artifacts that successfully meet the “storage” requirements (i.e., built and assembled error free, as well as validated for Security Compliance) will be “committed”.

· The commit event places artifacts in the appropriate repository (i.e., source code, test, other) and triggers environment build and product delivery testing.

Product Delivery and Test

· In this step executables, new builds, integration services, data migration services, and database changes are deployed and tested as appropriate

· Testing will address UAT, system, integration, regression, security and performance testing as appropriate based on the item being released

· In this phase, successfully tested product is automatically released to one or more environments IMLCI Agile, Application Delivery and DevSecOps The following principles and guidelines from the Chief Software Officer (CSO) inform all IMLCI solution work. Pipeline delivery is the next evolution of agile and builds on the agile principles by adding the following:

· Leverages Containers and Microservice concepts

· Leverages Cloud deployment for scalability and prototyping

· CI/CD to rapidly prototype, test and deploy

· Leverages A/B testing and canary deployment for rapid feedback loops

· Embeds security in the pipeline instead of an after-thought The IPO plans for an automated Application and DevSecOps culture that uses test automation tools to verify sprint functions, product features and security. The DevSecOps pipeline will support automated testing and automated software build and delivery, etc.

Figure 9: DevSecOps Pipeline DevSecOps will promote and encourage security related discussions to happen very early in the program, during the software development process. Security conversations begin at the start of the project and never stop.

Figure 10: DevSecOps Triad DevSecOps will embrace automated functional and security testing and include tests authored by the development teams. Early adoption of cybersecurity by the Authorization Authority (AA) will ensure delivery of viable products as quickly as possible to the warfighter, in months or weeks instead of years. DevSecOps includes real-time feedback from the end-user and allows for the continuous upgrading of system capabilities to address user needs, known as an iteration.

DevSecOps Tenets:

· Automated DevOps and DevSecOps culture

· Test Coverage

· eXtreme Programming Framework using Test Driven Development to automate unit, integration, and acceptance testing

· Cybersecurity and Test and Evaluation (T&E) will be done in parallel (DevSecOps) with functional testing

· Release 1 Integration with the existing Federal Logistics Information System (FLIS) will leverage the extensive formal protocols, controls, test beds, test sets, and test regions set by the Defense Logistics Agency (DLA) community for Application Program Interface (API) integration, thereby ensuring joint certification of inter-operability prior to Go Live

· Continuous Integration (CI)

· Version Control

· Centralization of source code with revision history

· Trunk-Based development for custom features/enhancements

· Code Quality

· Automated code quality scans on check-in to review source code to determine if any regressions have occurred, and to assess if the code is understandable, maintainable, and follows coding practices to avoid vulnerabilities or weaknesses

· Continuous Delivery (CD)

· Code changes will be automatically built, tested, and packaged for deployment to identified environments

· Automation of the release/deployment process

· Automated promotion of builds from development through the pipeline

· Continuous Monitoring & Feedback

· Application Performance

· Optimization

· Pre-Commit Checks

· Review changes to the code and configuration before committing to source code control system

· Commit-Time Checks

· Able to be compiled and built at all times

· Static Application Security Testing (SAST) with pre-defined rules

· Automated reporting of issues related to build failures and SAST issues

· Build-Time Checks

· Code compilation failures

· Unit/Integration Test failures

· Automated SAST with more comprehensive rule set defined

· Risk-Based security testing

· Automated reporting of issues related to build failures and SAST issues

· Test-Time Checks

· Deployment of the latest ‘good’ build to a staging or test environment

· Execute all functional, integration, performance, advanced SAST, and Dynamic Application Security Testing (DAST) tests against build

· Deploy-Time Checks

· Post production deployment testing to ensure changes to the production environment haven’t introduced issues Specific considerations and/or areas of focus include:

· DevSecOps cybersecurity and T&E will be done in parallel with functional testing. Early discovery and assessment of system vulnerabilities can facilitate remediation, reduce mission risk, and reduce impact on cost, schedule, and performance, as well as increase likelihood of a successful operational test and mission effectiveness.

· The use of automated tools to validate product code and scripts will be used instead of relying upon outdated, often wordy documentation, allowing for faster delivery of new capabilities to the warfighter.

· Test automation allows for a fast, repeatable and inexpensive means to ensure confidence that changes in a system have not introduced unwanted behavior. Tests during code development are automated as a part of the continuous integration process. Tests that fail during the continuous integration process fail the build process. Developers are required to fix the build by either issuing a fix or reverting the changes introduced. Fixes, recorded in Jira, will be triaged, prioritized, managed as stories, assigned to sprints, and placed into release packages as appropriate.

· Cybersecurity Subject Matter Experts (SMEs) will work closely with the authorization and accreditation (A&A) team.

Pipeline View

Figure 11: Product Pipeline

Approved Open Source Tools for Application Delivery and DevSecOps The 4 tables below outline the tools currently approved for use in the CCE as of the release of this RFP and are subject to change. The use of Kubernetes, Docker, Jenkins, Artifactory, and Ansible are highly recommended. Final tool selection to support Application and DevSecOps management will occur after contract award.

Figure 12: Approved Product Stack – Part 1

Figure 13: Approved Product Stack – Part 2

Figure 14: Approved Product Stack – Part 3

Figure 15: Approved Product Stack – Part 4

Standard Desktop Configuration All products on the Air Force network must comply and stay current with the USAF Standard Desktop Configuration (SDC). The most recent SDC product list (SDC 5.5.1) is summarized in the table below. The software versions listed are only at a point in time, evolving as needed to meet business objectives. The application will maintain compatibility with current and future updates to SDC, including Chrome, Firefox and Edge web browsers. Internet Explorer will be deprecated in the future (projected for FY25).

Table 1: SDC Product List (at this time)

OneNote V1R2, PowerPoint V1R1, Project V1R1, Publisher V1R3, Skype for Business V1R1, Visio V1R1, Word V1R1, Outlook V1R2

V1R13

Product Compliance Risk Management Framework The IMLCI will utilize the Risk Management Framework (RMF) as well as the National Institute of Standard and Technology (NIST) SP 800-53. Further guidance will come from the Cloud Computing Security Requirements Guide (SRG), the FIAR controls overlay and the Application Security and Development Security Technical Implementation Guide (STIG). IMLCI has been deemed to not be a National Security System (NSS) per guidelines outlined in NIST SP 800-59, which defines the phrase “national security system” and provides government-wide requirements for information security.

Refer to the ITTRs and LRPs (Excel file Tabs) in the Requirements List (RFP Attachment 3) for details.

Authorizing Official (AO) IMLCI will follow migration activities that occur in sprints with the A4 Authorizing Official (AO). The process will involve all participants with clearly defined roles and responsibilities with A4 AO cybersecurity oversight.

Agile Program Roles and Responsibilities Product Development and Deployment include functions that address software configuration, Product Engineering, Integrated Testing, Product Architecture, and Integration; this approach uses IMLCI team IPO resources, aligning member skillsets to minimize gaps in knowledge and to maximize project team consistency. Key IPO roles and responsibilities associated with program execution and solution development include:

· Program Manager: Responsible for overall program success IAW Section 873 guidance and coordination/approval of interfaces

· Product Owner/Manager: Have content authority and the understanding of how people will actually use the system. Roles include managing backlog, communicating user stories and determining release dates and functionality

· Agile Coach: Provides feedback to help team adopt and improve Agile methods

· Scrum Master: Keeps team accountable to their commitments and removes roadblocks that might impede the team’s productivity

· Team Member roles include:

· Developer/Designer: Configures the product to meet customer needs. Performs analysis, estimating, design, coding and testing of software processes with shared aim to deliver software by adhering to best practice standards

· Systems Engineer: Ensures team is following best practices and software meets the intent of the User’s requirements; also responsible for coordination on and approval of interfaces

· Solutions Architect: Makes Agile architectural decisions to define and maintain the structure of the solution and assembles team’s ideas into a coherent whole

· Cloud Infrastructure Architect: Provides solutions for the virtual infrastructure that is delivered or accessed via a network or the internet.

· Testers: Generates and provides feedback on test status and progress, acceptance criteria, defect resolution, test environment and data, and process and product quality, and coordination/approval of interfaces

· Information System Security Manager (ISSM): Ensures the application and network reach and remain in a secure state and works with the accreditation authority to ensure the system can maintain authority to operate

· Functional Users: Represents one or more roles within the Air Force the system was developed to support. Shares functional knowledge to ensure end product is highly useful

· Organization Change Management (OCM)/Customer Management: Considers the full organization and what needs to change and be communicated. Manages the effect of new business processes and cultural changes to the enterprise

· Scheduler: Provides project scheduling in an Agile environment and decides how to commit resources between various tasks

· Functional Data SME: Provides representative from AFMC data team

· Training Manager: Selects and creates best training to meet the needs of the organization.

Hosting/Infrastructure Requirements IMLCI will primarily be built using a COTS software product hosted in a cloud environment. The production cloud environment will be a DoD approved IL-4 cloud environment currently planned to be sourced through the USAF Common Computing Environment (CCE). The baseline cloud computing requirements the solution must comply with are summarized in the CCE 2.0 materials (4.M_CCE_Services Description_V4.1_MAR_2019). Additional information can be found at CCE link: https://intelshare.intelink.gov/sites/afcce/SitePages/Welcome.aspx Cloud Computing Cloud Services IMLCI plans to use AF repackaged Amazon Web Services (AWS) or Azure cloud environments to host all environments within their DevSecOps CI/CD pipeline. IMLCI will require the selected COTS product be hostable within AWS or Microsoft Azure as implemented by the CCE.

Environments The proposed design should include the ability to establish and remove environments on demand to support the application and DevSecOps pipelines with functions such as development, test, or integration environments as indicated in the Statement of Objectives (SOO) for Software Licenses and Support. The cloud services host will provide tools to facilitate the rapid creation and deprecation of testing and development environments as needed to support the day-to-day operation of multiple teams of development and configuration. These tools include the draft CCE Bootstrap, which is a set of Ansible scripts that configure each newly provisioned CCE environment to meet Federal Risk and Authorization Management Program (FedRAMP) requirements. The CCE Bootstrap does not include any warrantees and the CCE will not be held contractually liable for the contents of the bootstraps. The bootstraps are subject to change. The CCE Bootstrap provides services and restrictions as follows:

· Ports: Traffic is limited to port 443 https in and out. Traffic going out must also be white-listed to pass through our egress firewalls. Internal to the environment, we do not impose port/protocol restrictions

· Services: See attached / high level services available in CCE - https://intelshare.intelink.gov/sites/afcce/SitePages/ServiceCatalog.aspx

· For AWS: You can go here - https://aws.amazon.com/compliance/services-in-scope and scroll down and pick DoD CC SRG

· For Azure: You can go here - https://azure.microsoft.com/en-us/global-infrastructure/services/?products=databox&regions=usgov-non-regional,us-dod-central,us-dod-east,usgov-arizona,usgov-iowa,usgov-texas,usgov-virginia and focus on US DoD East mostly and also US DoD Central

· Ansible: primarily used on the AWS side to script out infrastructure (IaC). Mission teams are free to use either ansible or cloudformation for their automation code.

· System requirements and Dependencies

· Privileged access is for users who can do read/write (admin) duties within their MA area as in provision services, stop/start services, administer database and other things.

· Admin users must have clearance / Sec+, SAML auth for user access (via CAC)

· Cloud One/CCE complies with all government IT and IA regulations

Development Environments The CCE Dev Lab (CDL), which has been rebranded to CloudOne Dev Lab (C1DL), is the projected Dev Environment if it becomes achieves an IL-4 certification.

Figure 16: BES Dev Zone Architecture

TDP Attachments 4.A - IMLCI101Brief 4.B - ManageItemMaster 4.C - ManageItemMasterAssistanceRequest 4.D - AssignManagementInformationToIM_ARLineItem 4.E - ManageFederalCatalogAction 4.F - ExecuteProvisioning 4.G - ProcessNames 4.H - Activities 4.I - InformationAssets 4.J - DataReferenceModel 4.K - TermsDefinitionsAcronyms 4.L - InterfaceInformation 4.M_CCE_Services Description_V4.1_MAR_2019

Distribution A. Approved For Public Release image1.jpg image2.png image3.emf

Microsoft_Visio_2003-2010_Drawing.vsd Title

Double-click to type notes. Subselect "Title" to edit the title.

Company Name notes. Subselect "Company Name" to edit the title.

Title notes. Subselect "Title" to edit the title.

Double-click here and type notes.

SUPPLY

D035A/M024B/D043-A v.5 (Manager Designator Add or Change File) (Multiple Times per Day) D035A/D043-C v.3 (Manager Designator Add or Change File) (Quarterly) D035A/D043A-A v.2 (IM Office Address Record) (Daily) D035A/D169-A v.3 (IM Wholesale Requisition Process)(Daily) D035C/M024B/D043-A v.3 (Reparable Item Movement Data) (Daily) D035K/M024B/D046-A v.3 (Triple X Queries) (Multiple Times per Day) D002A/M024B/D046-A v.4 (SNUD Maintenance) (Daily) D002A/M024B/D043A-A v.5 (Inactive Item Notification) (As Required) CAVAF/D043-A v.1 (S/N CMD Data Query) (Weekly)

MUNITIONS

D078W/M024B/D043-A v.1 (NSN Addition or Deletion) (Weekly) D078W/M024B/D043-B v.1 (Munitions Data Changes) (Weekly)

PLANNING

D200E/D043-A v.1 (Last Stock List Change Query) (Weekly) D200A/D043-A v.1 (Airlift Code Data Update) (Quarterly) D200A/D043-B v.1 (Defense Inactive Item Program (DIIP) Update) (Annual) A400/D043A-A v.1(A400 NIINS) (Monthly) D040/M024B/D046-A v.1(Stock Number Directory Reconciliation)(Daily) D087H/ESB/D046-A v.1 (Interrogation by S/N, MMAC/FSC) (Weekly)

MAINTENANCE

Q302/D046-A v.1 (S/N Reconciliation Query) (Monthly) Q302/M024B/D046-A v.1 (Add or Deletion of S/N Query) (Daily)

CONTRACTING

J018R/D043-A v.1 (Transaction for get NIIN) (XML) (As Required) D203/D043-A v.3 (NIIN Data) (As Required) D203/D143C-A v. 3 (Valid Screening Data (AMC/AMSC Codes and Expiration Date) (As Required)

FEDERAL CATALOGING

FLIS/D043A-B v.3 (Master Cross Reference Data Query) (Quarterly) FLIS/D043A-A v.1 (Cage/Manufacturer Update) (Monthly) DLA/M024B/D043-A v.1(Inactive Item Review Notification Update) (Daily)

* FLIS/M024B/D043B-B v.1(FLIS Responses) (Daily) FLIS/D169-A v.1 (Draft) (DLIS Replies (PDSSR/LISSR) (Quarterly)

* FLIS/M024B/D155-A v.1 (CMD, Item Identification Data)(Daily)

* FLIS/D143C-A v.2 (Overflow Data) (As Required)

* FLIS/M024B/D143C-B v.2 (K-Document Identifier Data) (Daily)

Note: will be subsumed by the DLA provided webservice (API)

TRANSPORTATION

D035T/M024B/D043-A v.3 (Packaging & Transportation Data Update) (Weekly)

ASSET MANAGEMENT

C001/D043-A v.2 (Freeze Code/Equipment Management Code Update)(S/N, Reference Number Interrogation (Daily)

FINANCIAL MANAGEMENT

D035J/D043-A v.2 (Moving Average Cost (MAC) Update) (Daily) D200N/D043-A v.1 (Stock Fund Credit Indicators) (Quarterly) D200N/D043-B v.1 (MSD Price Distribution) ( Quarterly) D200N/D043-C v.1 (Stock Fund Credit Indicator Update (Quarterly) D200N/D043-D V.1 (MSD Price Update) (Weekly)

KEY * = Notes

ITEM MASTER INBOUND

Interfaces from IMCS Suite of Systems

ENGINEERING

Product Structure - ICDs TBD

VENDOR

Provisioning Data (LSA-036) (ICDs TBD) as of 9/21/18

MISC

Q111A/D043A-A v.4 (Draft) (Definitions and Legal Code Values for Cataloging) (Monthly)

SUPPLY

D043/D035A-A v.2 (Air Logistics Center Validation Tables) (Weekly) D043/D035A-B v.2 (Air Logistics Center Maintenance and Replies) (Daily) D043/M024B/D035A-A v.3 (Advance Decapitalization Notice) (As Required) D169/D035A-A v.2 (Supply Support Interrogation File) (Daily) D143C/M024B/D002A-A v.6 (Response Format for Short and Long AF Form 86) (Daily) D046/M024B/D002A-A v.5 (Replies to SBSS Interrogations) (Daily) D043/CAVAF-B v.1 (S/N Catalog Management Data File) (Weekly) D071/M024B/D002A-B v.4 (MSD Price Distribution Record) (Weekly) D043B/M024B/D035K-A v.3 (BVS Stock List Change Data) (Daily) D046/M024B/D035K-A v.4 (BVD Stock List Change Data) (Daily) D046/M024B/D002A-B v.4 (MSD Price Distribution) (Daily) D071/M024B/D002A-A v.2 (Stock List Change Distribution) (As Required)

CONTRACTING

D043/J018R-A v.1 (XML Stock List Change Record) (As Required) D043/D203-XX v.2 (Valid Cage/Part Combination) ( (Weekly) D043/D203-X v.2 (Valid FSC Data) (Weekly) D043/D203-B v.2 (Catalog Confirmation for D203) (Event Driven) D043/D203-A v.3 (Catalog Data Pertaining to NIIN) (Event Driven) D086/D203-X v.2 (Valid MMAC Data) (Weekly) D220/J041 – A v.2 (Acquisitions AND Due-Ins) (Daily) Note:D220 just passes the information, does not store the information

MAINTENANCE

D046/Q302-A v.1 (SNUD Reconciliation for G005M) (2x per Quarter) D071/M024B/Q302-A v.1 (Catalog Changes, MSD Price Update) (Weekly) D046/M024B/Q302-A v.1 (SNUD Responses) (Daily) D043/Q310-C v.1 (Catalog Master) (Daily)

FEDERAL CATALOGING

* D043/M024B/DLA-A v.1 (Inactive Item Review Notification) (Daily)

* D143C/M024B/FLIS-A v.1 (DLSC DATA) (Daily)

* D036/M024B/FLIS-A v.1 (D036 Data) (Daily)

* D036/M024B/FLIS-B v.1 (Add/Change MOE Rules, CMD) Standardization Relationship) (Daily)

* D155/M024B/FLIS-A v.1 (LSR Record) (Daily)

Note: will be subsumed by the DLA provided webservice (API)

PLANNING

D043/D087W-C v.2 (Priority Stock List Change Record) (Weekly) D043/D087W-D v.1 (I&S File Maintenance) (Monthly) D043/D101-A v.1 (Catalog Data) (Monthly) D043/D040-AM v.2 (Catalog Screening for All WS1 Transactions) (As Required) D046/M024B/D040-A v.2 (Reply to D040 File) (Daily) D071/M024B/D040-A v.2 (Distribution Data) (Weekly) D169/M024B/D040-AM v.1 (D169 Input File) (Weekly) D043/D072-A v.1 (Stock List Change Output) (Monthly) D043/D087X-A v.2 (I&S File Maintenance) (Monthly) D043/D035G-AM v.2 (Stock Number Part Data) (Weekly) D043A/A400-A v.1 (CMD, I&S, P/N Data) (Monthly) D043/D200E-A v.2 (Stock List Change File) (Weekly) D043/D200N-A v.2 (ERRC N, P, C &T and Budget Code 8) (Weekly) D043/D200N-A v.2 (Weekly Feed of New NSNs) (Weekly) D220/D200F-A v.1 (Provisioning Parts List Breakdown) (Weekly) D220/D200H-A v.1 (Initial Requirements Determination Req-Comp Data for All ALCs) (Daily) D043/D087X/ESB/D087H-B v.1 (Item Name Data) (Weekly) D043/D087X/ESB/D087H-C v.1 (Stock List Change Output) (Weekly) D043/D087X/ESB/D087H-D v.1 (I&S File Maintenance) (Monthly) D043/D087H-B v.2 (Item Name Record) (Weekly) D046/D087X/ESB/D087H-A v.1 (Interrogation Replies) (Weekly) D043/D087X/ESB/D087H-A v.1 (Parts Number Data) (Weekly)

FINANCIAL MANAGEMENT

D043/D035J-A v.2 (Moving Average Cost Error Record) (Daily) D043/H303-A v.5 (MSD & GSD Extract) (Monthly) D043/H036C-A v.3 (Unit Price Information) (Quarterly/Annual) D043/H036C-B v.2 I&S for Weapon System Cost Retrieval System) (Annual) D043/CRIS-A v.1 (Extract D043 Data) (Monthly) D043/D160-A v.1 (Quarterly and Annual Unit Price Data) (Other) D043/D160-AA v.1 (Item Identification AFTOC Data) (Monthly 25th) D043/D160-B v.1 (I&S for AFTOC) (Annual) D043/D160-BB v.1 (Cost -for AFTOC) (Monthly)

Other Services or Agencies (OSVCS)

D071/M024B/OSVCS-A v.1 (Note: Details not provided in CDRS)

FOREIGN MILITARY SALES (FMS)

D043/W001-H v.4 (Manager Designator Changes) (As Required) D043/W001-G v.4 (D043 Sorted Cross Reference) (Weekly) D043/W001-A v.4 (Stock Number Data) (Daily) D043/W001-B v.4 (Stock List Change Data) (Daily) D043/W001-C v.4 (Item Name Data) (Daily) D043/W001-D v.4 (Managing Activity Codes (MMAC/IM/SOS, FSC) (Weekly) D043/W001-E v.4 (Nonconsumable Item Material Support Data) (Daily) D043/W001-F v.4 (RIMCS Data) (Daily) D043/W001-J v.3 (Item Manager Office Address Record) (Weekly) D043/W001-I v.3 (MSD Price Data) (Daily) D043/W001-K v.3 (Special Cross Reference) (Weekly) D043A/W001-A v.4 (Item Manager Office Address File) (Weekly)

ASSET MANAGEMENT

D043/C001-A V.2 (Catalog Management Data) (Daily)

TRANSPORTATION

D043/M024B/D035T-A v.3 (Freight Data) (Weekly) D043/D087T-A v.1 (D043 extract for Tracker/TAC Validation) (Monthly)

MISC

D043/D075-A v.1 (Catalog Management Data Extract) (Monthly) D043/M024B/D075-C v.1 (XAC Tape Extract) (Weekly) D043/D075-B v.1 (Extracted I&S Data) (Monthly) D043/Q072R-A v.1 (D043 Data Elements) (Monthly) D043/RIPIT-A v.1 (D043 Catalog Data) (Quarterly) D043/EAGLE-A v.2 (F-15 Parts Extract)(Monthly)

VENDOR

D043/D375-A v.1 (Catalog Data for ICP Contractor Managed Weapon System Items) (Daily) D043/D375-B v.1 (CSWS) (NSN Information) (As Required) Provisioning Data (LSA-036) (ICD TBD)

ENGINEERING

Product Structure - ICDs TBD

ITEM MASTER OUTBOUND

Interfaces from IMCS Suite of Systems

KEY * = Note

MUNITIONS

ICDs TBD as of 9/21/18 image4.emf

Microsoft_Visio_Drawing.vsdx image5.emf

Microsoft_Visio_Drawing1.vsdx image6.png image7.png image8.png image9.png image10.jpeg image11.png image12.png image13.emf image14.emf image15.emf image16.emf image17.png