App Factories and the Transformation of Legacy Systems

As government organizations in the defense, intelligence, security and law enforcement sectors take stock of their existing information technology (IT) portfolios, a debacle begins to emerge.  Due to design-time architectural decisions, the sustainment burdens associated with many legacy systems are becoming unsupportable.  This may be due to the use of obsolete programming languages, monolithic architectures, tight coupling between components, the extensive use of proprietary interfaces or some combination of all four.  In the end, the reasons matter less than the fact that we live in time of shrinking budgets.  Program offices that migrate their systems to sustainable architectures will be successful; program offices that do not will fail.

There is general agreement as to the path that this migration will take.  Service oriented architectures (SOA) and Cloud capabilities provide a technical framework supporting the way ahead.  More specifically, it is expected that programs will migrate to a bifurcated environment consisting of an integration platform upon which sets of modular, composable and interoperable domain (or “warfighting”) services will operate.  The integration platforms are well understood, providing generic core functionality such as storage, data access, transport, identity and access management (IdAM), application and service hosting, runtime governance and monitoring and analytics.  At first blush, the domain services effort seem similarly straightforward.  And, from a program management perspective, the basic process is well understood: 

• Business process modeling is conducted to analyze the warfighting capabilities of each legacy system;
• Atomic functions are identified as candidate services;
• User stories are written describing each service and attendant acceptance criteria and access control rules; and
• The service is coded, tested and deployed.   

Unfortunately, the larger problems associated with the migration to domain services are less technical and more programmatic.  Fortunately, there are tools and mechanisms available to program offices that both solve these problems and offer the promise of overall development and sustainment cost reduction. 

The acquisitions environment in which these services will be (and are being) developed is complex:  A single program can have literally dozens of developer organizations, some of which are from industry and some of which are from government.  Each organization may be tasked with the scheduled production of domain services, infrastructure capabilities, the integration of legacy systems or some combination of all three.  At the top of the pyramid is the program office, which struggles to manage the spectrum of lifecycle activities ranging from project and team management to software development, verification, validation and integration, deployment and retirement across a geographically, organizationally and culturally diverse programmatic landscape.  In sum, the challenge facing acquisitions commands seeking to migrate and modernize legacy systems is one of organization and governance.

Unlike the case of the integration platform, the issue with the migration to domain services is less one of WHAT software should be produced and more of HOW the software production should be managed.  The elements of the software production process are generally common across organizations:  Projects are created and kicked off.  A cycle of continuous build followed by testing, migration between development, test and operational environments is followed.   What is required is a mechanism to ensure that production process is common across the entire program and subject to the oversight and control of the government program manager.

Fortunately, there are Cloud-based development toolkits available designed to improve distributed production processes and software delivery through the provision of automation and governance structures that promote architectural best practices, encourage collaboration, reduce process friction, and monitor compliance with organizational and regulatory requirements.  Typically these toolkits are deployed in a secure Cloud environment that allows all authorized team members managed access to the development environment. 

Among the features provided by these Cloud tools are on-demand, self-service and Cloud provisioning, continuous build, continuous integration, continuous test and continuous delivery to user self-service portals and app stores.  The result is a significantly simplified developer experience leading to increased developer productivity, shorter project cycle times and more efficient resource usage.

The tools also provide for governed, iterative lifecycle management across the scope of the program.  They do this by providing a standardized set of architectural templates and application platform services as well as a common – and customizable - set of software performance metrics and analytics.  The well governed environment fosters cross-organizational development collaboration.

By imposing the use of a governed distributed development tool, the government program manager can ensure critical programmatic predictability, reducing risks inherent to assumed communication, and, therefore, total programmatic cost.  Among the governance controls supported by these tools are:

• Enforcement of the use of the standard infrastructure services provided by the integration platform;
• Enforcement of the use of a common development process (e.g., continuous build, continuous test, code coverage, discrepancy reporting, etc.);
• Compliance with DoD and service component security and information assurance (IA) instructions;
• Implementation of a program or service component standard provisioning lifecycle (e.g., deployment to test environments followed by promotion to operational app store); and
• Enforcement of a man-in-the-loop application approval process including developer submission, review gates and approval checklists and automated test execution.

Similar to the exemplar integration platform, there are open source offerings meeting the requirements for a Cloud-based distributed development toolkit.  An excellent example is the WSO2 App Factory.  The WSO2 App Factory provides complete enterprise-level DevOps support inlcluding:

·        Project and team management;

·        Software development workflow;

·        Governance and compliance;

·        Development dashboards;

·        Code development;

·        Issue tracking;

·        Source and version control;

·        Continuous build;

·        Continuous integration;

·        Test automation; and

·        Continuous deployment.

The WSO2 App Factory is Cloud-based, operating as a set of pluggable applications on top of a runtime Platform-as-a-Service (PaaS) framework.  It integrates a development forge, enterprise best practices and a Cloud runtime.  Additionally, it ships with open source version control (Subversion, Git), continuous integration (Jenkins, Bamboo), continuous build (Ant, Maven),Test Automation (Selenium) and project management and bug tracking (Redmine) tools.

Additionally, the WSO2 App Factory provides a customizable, extensible governance and compliance modeling framework, project and portfolio dashboards and an App Store for deploying services and applications built within the WSO2 App Factory framework.  As with other open source products, there is zero acquisition cost associated with the WSO2 App Factory.

Through the use of such distributed development toolkits, overall control of the project is placed squarely back in the hands of the program manager.  Technical and programmatic governance is automated, freeing up valuable management resources.  Additionally, visibility and situational awareness are dramatically improved across both horizontal and vertical dimensions of the program. The bottom line, however, is the efficiency gains offered by these toolkits:  Well governed programs result in an overall reduction in both development and sustainment costs.