3.3 Common Use Case

Within the AF, it has become common to refactor and migrate applications from older, more expensive, on-premise hosting environments into the commercial cloud using the AF CCE and other environments (refer to the latest AF CCE documentation for details). The mission of AF CCE is to migrate applications to the cloud and comply with technical requirements. The AF CCE performs enough technical application refactoring, so the application will technically operate in the AF CCE cloud environment (AWS or Azure). AF CCE’s initial strategy was to start by refactoring and migrating simpler applications first (those that require less refactoring and transformation) and then build on their success and lessons learned to tackle more complex legacy application refactoring and migrations. The AF CCE does not perform refactoring beyond what is required to migrate the application to one of the AF CCE environments (currently AWS and Azure). This means that in general AF CCE will not perform code conversion transformations, database transformations, functional improvements, and so on (unless required for migration).

Before any AAM project is undertaken, the application PMO should consult with the AF CCE PMO to understand what they can do for your application in terms of refactoring, modernization, and migration. Also, it is important to understand which PMO will pay for which activities, tasks, architectural components (e.g. the DISA SCCA security tier), and solution development and deployment tools. Application PMO’s should consider what it makes sense for AF CCE to do, and when, so the application modernization project goals are achieved.

More complex legacy application modernization projects, include mainframe applications, those using older coding languages, those using older or specialized client server/hardware or operating systems require a modernization project to transform the application from its legacy state to a desired modern state.

An example of a project that applied AAM to transform an application is the PEO BES AF Logistics project that transformed the AF Standard Base Supply System (SBSS) to the AF Integrated Logistics System – Supply (ILS-S). The SBSS transformation consisted of a series of projects that led to a transformed state and a refactored state. Looking at SBSS to ILS-S from a broad perspective over time, the legacy AF SBSS was a complex UNISYS 2200-based COBOL application running in DISA DECC, through the series of projects this application was re-factored into the ILS-S which is now an improved Java application that runs on the X86 platform and is being migrated into AF CCE’s AWS GovCloud.

Another example is the AF Integrated Maintenance Data System (IMDS), using a simpler approach, which is currently being refactored and re-platformed from a UNISYS 2200 Mainframe, UNISYS COBOL application hosted in DISA DECC to a Windows Server operating system-based Microfocus COBOL application running in AF CCE’s Azure Government cloud on native Azure SQL Database.

Both the ILS-S and IMDS modernization examples were driven by AF domain needs and a portfolio application rationalization assessment. The AF determined, at the point of time when decisions were made, that ILS-S needed a more complete overhaul, while IMDS would best benefit by re-platforming the application.