A “pre-corollary” to the Cheshire cat’s advice is: “If you don’t know where you are, you certainly can’t know if any road choice will go anywhere of value.”
The Problem
In 2013, a study was undertaken to identify the key root causes of the United States Air Force’s failure to successfully develop a $1 Billion Expeditionary Combat Support System.
The audit, developed through a special USAF effort, was required by and submitted to the senior staff of the Air Force and to Congress.
The root cause failure findings, taken from the Acquisition Incident Review Team’s Executive Summary, were:
Understanding the Data. The Air Force must thoroughly understand its data. It didn’t in the Expeditionary Combat Support System. All of the data must be understood, not just the data we thought we had, and not just the data we wanted to address, but all of it.
This matter cannot be solved by doing Legacy Deconstruction at the same time as blueprinting, at the same time as building the new “To-Be” solution. It needs to be done first. It needs to be a coordinated effort combined with an understanding that accomplishing this will take time.
Understanding the “As-is” and “To-be” Architectures: The Air Force didn’t understand the “As-Is” or the “To-Be” architectures. After exposing and understanding all the data, knowledge is needed on how it is connected or put together. This allows a better assessment on whether the “To-Be” architecture is complete.
With the Expeditionary Combat Support System, the lack of detailed knowledge of the “As-ls” resulted in an incomplete assessment of what the “To-Be” represented for the Expeditionary Combat Support System.
As of the date of the 2013 report, the number of systems Expeditionary Combat Support System was to replace is unknown. Unlike traditional weapon system acquisition, which focuses primarily on the “To-Be” and increasing capability, in business systems, one must understand the “As-Is,” since much of it is critical in order for the field to accomplish the logistics mission.
A Transition Plan from “As-is” to “To-be:” The Air Force lacked a transition plan for resolving the differences between the “As-Is” and ‘To Be.” This resulted in an inability for Expeditionary Combat Support System to successfully accomplish its goal.
The process is similar to a construction project where temporary structures must be built, then later torn down in order to make way for the new road. This transition is the heart of the effort, and takes time. However, since the Air Force did not understand the “As-Is” or “To Be” architectures, arriving at a transition plan was impossible.
The Right Execution Plan: Even if the Air Force had a transition plan from the “As-Is” to the “To-Be” architecture, it lacked a way to properly execute it. The Air Force needed to obtain a software package that could accomplish the “To-Be,” however, the Air Force knew from market research that no single, stand-alone product could satisfy its need (the AF permitted “bolt on” applications), but there existed no follow through on exactly how the Expeditionary Combat Support System would achieve the “To-Be” utilizing a software product requiring bolt-ons that increased the number of interfaces.
A detailed execution plan did not exist. Additionally, the Systems Integrator needed to have the ability to code the vision as described through the blueprinting process, and the Air Force needed a way to articulate how to execute from the “As-Is” to the “To-Be.”
While the Air Force, as part of the Systems Integrator contract arrangement, provided hundreds of Subject Matter Experts to assist in this endeavor, the Subject Matter Experts had no single vision on how to accomplish this. All the Subject Matter Experts from the field had different processes they utilized, and yet these same individuals were asked to communicate a single vision to the Systems Integrator on how the transition would occur.
The Right Development Environment: The Expeditionary Combat Support System was to be developed in an unrealistic environment; one that did not mirror the reality of the operational environment. Although this issue doesn’t get much play with Expeditionary Combat Support System alumni, it would have been a root cause to the program failure even if they made it through all of the other challenges. The software has to work in the expected environment.
The Right Culture: The culture would have had change to accept the new vision as designed into the code. That means that everyone would have had to understand the vision of the Expeditionary Combat Support System and been convinced their equities were being taken care of in this program. There was universal agreement during interviews that this was not going to happen, but very little understanding as to why.
Enterprise Architecture Development and Evolution
Figure 1
A key finding from the USAF determination of the root causes of the failure was the lack of an As-Is and thereafter an unfolding sequence of migrations through system conversions to evolving To-Be Enterprise Architectures. An overall enterprise architecture is depicted in Figure 1. This architecture is set within an adaption of the Zachman framework. This adaption consists of a set of work products that were especially designed, validated, and fully defined through methodology, courses, workshops, and a comprehensive work-product metadata management system specifically for knowledge workers. The key Enterprise Architecture work product components include:
- Missions, Organizations, and Functions
- Resource Life Cycle and Networks
- Databases
- Database Objects
- Data Models (Specified, Implemented, and Operational)
- Business Events
- Business Information Systems
Table 1 briefly describes each key work product along with its value within the Enterprise’s Architecture. The set of follow-on efforts made possible once initial and subsequent enterprise architecture cycles are identified, set out, and described in Table 2.
Contained and Interrelated Enterprise Architecture Component |
|
| Enterprise Architecture Component | Description |
| Missions, Organizations, and Functions | Metadata Management System stored descriptions, specifications, and interrelationship of enterprise missions, the organizations that carry out these missions, and the human-based functions performed for both infrastructure and external enterprise efforts. |
| Resource Life Cycle and Networks | Metadata Management System stored descriptions and specifications of the essential enterprise resources and their state-based accomplishment life cycles. Includes the appropriate allocation of supporting database objects and business information systems. These are linked to Mission-Organization-Functions. |
| Databases | Metadata Management System stored descriptions and specifications of the databases required by the enterprise in support of the accomplishment of its external and infrastructure missions through the processes of business information systems. Database schemas consist of interrelated collections of database objects. These are linked to their data models. |
| Database Objects | Metadata Management System stored descriptions and specifications of well-defined collections of highly cohesive mission-based data structures of tables and processes that ensure high quality inserts, updates and deletions, state-based transformation life cycles, and information process specifications that ensure rigorously-defined database object transformations. These are interrelated to both data models and databases. |
| Data Models | Metadata Management System stored descriptions and specifications and multi-level data models of data-based concepts through operational database specifications to ensure maximum data quality, and semantic-based automatic naming and definitions. Database model manufacturing and the multiple-level generalizations required for bottom-up inductive data architecture development are enabled. |
| Business Events | Metadata Management System stored descriptions and specifications of the events within the business that are either event or calendar triggered and that invoke the execution of an individual, sequence, or network of sequenced business information systems to accomplish of data-based processes for the support of one or more resource life cycle nodes. |
| Business Information Systems | Metadata Management System stored descriptions and specifications of a collection of computer-software systems that receive, update, or report data within an operational data model database that is associated with one or more resource life cycle nodes. |
| Table 1. Key Work Product Components of Enterprise Architectures. | |
Follow-on Efforts Enabled by Enterprise Architecture |
|
| Follow-on Effort | Description |
| Enterprise Governance | Metadata Management System identified, described, specified, and regularly assessed work products that are the integrity-responsibility of one or more specific mission-organization-functions, positions, and persons. |
| Information System Plans | Metadata Management System supported sequence of the next logical wave of databases and business information systems to be migrated from an As-Is to a To-Be State in a business-based rationale and sequence. |
| Deployed DBMS Syntax Comparative Analysis | Produced analysis of the collections of SQL syntax from within SQL engines that are commonly or uniquely employed within given business information systems that bind particular business information systems to certain DBMS vendor SQL engines. |
| DBMS Inhibitors to Business Information System Migration | Produced analysis of the collections of SQL syntax from within SQL engines that prevent a business information system from being migrated from one DBMS vendor SQL engine to another. |
| Reference Data Management | Metadata Management System identified and specified sets of database tables and value sets that are either authoritative in nature or that act as common references across collections of databases. |
| Semantic Modifier and Data Use Modifier Regularization | Metadata Management System identified and specified semantic hierarchies that enable reliable and repeatable name construction of database facts (data elements, attributes, columns and DBMS Columns) across the data models support standardization and automation of data interoperability, naming, and definitions. |
| Table 2. Metadata Management System Follow-on Efforts Enables by Enterprise Architecture. | |
For Enterprise Architectures to be efficient and effective, its key component work products must be in the metadata management system database such that they are completely integrated, interoperable, and non-redundant. Some of the work products are accomplished through bottom-up processes and others through top-down analyses.
Initially collected, enterprise architectures form the As-Is foundation upon which migration happens in waves from their As-Is to their To-Be architectures. As each conversion wave is completed, the enterprise architecture is updated to a To-Be state, which, in turn, becomes the next As-Is state for the next wave of database and business information system migrations. This process is depicted in Figure 2.
Figure 2
