Seeing the Enterprise Clearly: How a Data Engineer Enables Army Modernization

Image

Introduction
Within the Army Intelligence Security Enterprise, modernization is often discussed in terms of cloud, analytics, data science and other emerging technologies. Those initiatives absolutely matter. However, their success depends on something much more fundamental: a clear understanding of the data that defines our information management (IM) and information technology (IT) environment. Without that foundation, modernization efforts cannot move forward. Instead, the pace of progress slows down efforts, drifts operations off course or ends up built on assumptions rather than hard-grounded truth. 

Image

At the National Ground Intelligence Center, this difficulty sparked a multiyear effort to reconstruct the organization’s understanding of its capabilities, systems and dependencies. As an FA26B data systems engineer with dual positions as senior technical advisor and applications and data branch chief, I discovered that modernization begins long before new technology is introduced. It all starts with the data and the discipline required to create, govern and preserve it. 

Modernization is often cast as a technology challenge, but it’s really a data problem. And solving that problem involves confronting the unpleasant truth that what we think we know about our organization is usually not what the data actually says.  

The Army’s Data Problem
The painful realization began the moment I logged into the Army’s antiquated asset inventory system. Immediately, it was obvious the system no longer represented the enterprise it was supposed to represent. The records had duplicate entries, missing information, outdated system descriptions and capabilities that were in practice but not documented. It was more of a glimpse into the history of what the enterprise once was, rather than a definitive source. 

When people talk about modernization, they generally talk about a new platform or a migration strategy. But modernization begins with comprehending what is there. And in this case, the fact was simple: our base data wasn’t intended for enterprise-level decision-making. 

Originally intended to manage the IT asset portfolio, the Army’s antiquated Automated Systems Integration Database (ASID) had devolved into a disorganized collection of inconsistent information. Some entries listed hardware no longer in use. Some were missing key fields such as owner, cost or network placement. Some capabilities simply did not exist. In numerous cases, the same system was described under multiple names, with mismatched configurations or locational descriptions. 

This was a systemic problem, not a result of inadequate recordkeeping. The system was designed for a different period of Army IT: one with fewer systems, fewer dependencies and fewer modernization requirements. Although the enterprise changed over time, the data remained constant. 

As a result, the system was no longer able to describe the environment it was designed to track. You cannot reason what you do not perceive. You cannot modernize what you cannot quantify. And you can’t transform if your data is distributed over spreadsheets, inventory lists and institutional memory. 

Behind the Scenes: The Efforts No One Sees
When the Information, Data, and Transport Tiger Team was established, the task sounded simple: establish a lasting business process to streamline the Army’s IM/IT portfolio. In fact, it needed a complete rethinking of the Army’s view of its own technology. The data issues we identified were not isolated anomalies, but indicators of a wider challenge. 

It meant knowing not just apps and systems, but the infrastructure, people, contracts, services, networks and dependencies that underpin them. This meant reconciling competing data sources, certifying undocumented capabilities and piecing together information held solely by long-serving engineers and administrators. The labor was painstaking, often manual and highly dependent on institutional knowledge that had never been captured in any system of record. 

This is the component of modernization that is hardly seen in strategy documents. It’s invisible, unglamorous and easily underestimated. However, it is the component that will determine the success or failure of modernization initiatives. In the absence of this fundamental effort, recourse decisions are reactive rather than proactive, cybersecurity becomes inadequate and cloud migrations are a shot in the dark.

Data Reality Check
We must address one basic point before any modernization can start: what do we really have? Each enclave and system owner saw the world differently, and none of them agreed. Something was listed in the inventory system. Another one, according to local accounts. Slides from the command and staff tell a different tale. Then there were the capabilities used only in practice and maintained by teams for years.  

We came across systems without costs, owners without capabilities, capabilities assigned without owners and dependencies that no one could adequately describe. A single person’s memory was the only reliable source in many situations. This was a survival-based environment, not one that was ready for modernization. 

In the absence of a solid foundation, all subsequent activities would rely on assumptions rather than facts. Because of this, our initial task was to establish a sustainable, authoritative baseline that could withstand decision-making, leadership turnover, audits and transformation initiatives.

Developing the Asset Management Portfolio
We began developing a new strategy, the Portfolio-Based System of Automated Tools (PBSAT), after realizing that the existing data could not support the mission. By integrating structure, automation and governance from the outset, we created this tool to rebuild the Army’s Information Technology Asset Management portfolio from the data layer up. It was a total re-architecture of the enterprise’s self-perception rather than a gradual improvement. We needed a data model that could effectively record and analyze the following data points, all in one place, be automated and outlast leadership changes and Permanent Change of Station cycles. 

• Infrastructure (hardware/software)
• Applications
• Services
• Dependencies
• Life-cycle status
• Human capital
• Facilities
• Contracts
• Cost and sustainment requirements
• Security posture
• Networks

This prompted the creation of a schema that could encapsulate the organization’s complexity without bogging down users who would update it. It had to create automation to validate data, flag discrepancies and cut manual labor. It also needed an established governance process to ensure the data remained accurate over time. 

The PBSAT was designed as a dynamic rather than static system. The goal is to illustrate how an organization actually operates, including the resources available, its links, dependencies and operational flows. That design choice established a framework for transformation by framing the enterprise as a coherent system rather than a series of disconnected elements. 

This evolution also brought about a cultural shift. Data ownership shifted from an individual to a group effort, away from a focus on specialized technical roles. System owners, mission leads and sustainment teams were all responsible for ensuring the enterprise reflected accuracy.

Modernization was no longer something done to the enterprise; rather, it was something sustained by the enterprise.

Rationalization Matrix: An Automated Decision Process
Modernization is not simply about data storage; it is about the decision-making process. With the PBSAT framework, we still needed a mechanism to translate data captured into actionable insights. To support this, we created an automated rationalization model that could function on imperfect and incomplete data. 

The model focused on the following data points: 

• Business impact
• Technical debt
• Total cost of ownership
• Mission criticality
• Strategic alignment
• User base
• Integration complexity
• Cloud readiness
• Requirement source and authorities

The rationalization model also brought to light patterns that had not been seen before. It highlighted areas with overlapping capabilities and technical debt, as well as where modernization efforts would have the most impact. It provided us with a data-driven, not assumption-based, transformation plan.

Just as important, it established a repeatable process that subsequent teams could follow without having to start over, a critical need for an enterprise with frequent staff rotations and turnover. The process of rationalization became a persistent, data-driven discipline and not a one-time event. 

The Workforce Deficit
Even the most complex data model cannot function without personnel to support it. Soldiers, civilians and contractors across the enterprise were combining legacy sustainment with new modernization demands, frequently using processes and tools designed for a different period of Army IT. The leaders responsible for the safeguarding of the enterprise were doing so under conditions that made modernization exponentially more difficult. 

This modernization initiative revealed both technical and human capital debt, and addressing this deficit is critical for long-term success. Consequently, the specialized skills of data engineering must be cultivated, resourced and retained. This discipline cannot be treated as a temporary mechanism, task or transient chore. It should be seen as a core mission function.  

This is the point at which modernization becomes a human-centered rather than a technical focus. The Army must invest in organizational structures, career ladders and training to support data-centric work. Even the best-designed systems will eventually degrade. Modernization is driven not by tools, but by the people who understand how to use, maintain, implement and evolve them. 

What Changed 
The immediate effect was updating the first dashboards with accurate, validated data. Finally, the Army Intelligence Enterprise had a comprehensive understanding of its resources. It could finally see itself after years of disjointed data, contradicting reports and unverified capabilities. It had a clear and authoritative picture of the entire enterprise.

Hidden capabilities that had not been seen or reported for years were documented, including owners, costs, dependencies and life-cycle changes. Systems considered mission-critical were identified as redundant. Tools that discreetly consumed resources finally had the data to justify divestment. Decisions previously made based on institutional memory can now be supported by evidence. The new system substituted institutional memory for institutional expertise, fragmentation for structure and ambiguity for clarity. More importantly, it provided the enterprise with “a single source of truth,” something it never had before.

After the data was cleaned, validated and exposed, the modernization tempo of the enterprise pivoted. Time previously spent reconciling sub-hand receipts or tracking down mismatched ASID entries was now used for real modernization work. Units could effectively trace inventory using reliable data and allocate resources appropriately. Decision-making accelerated, priorities became clear and the enterprise was able to operate at the pace required by its mission. This transition from reactive maintenance to proactive planning marked a pivotal moment in scaling modernization and positioned the enterprise for future success.

Conclusion: Data Is the First Step to Modernization
After years of legacy, broken inventories and inadequate automation, one thing became clear: modernization doesn’t start with the cloud, artificial intelligence or zero-trust architectures. It begins with the data. Clean, structured, dependable data underpins every decision and capability. To modernize at scale, the Army must treat data engineering as a critical mission function, teaching, resourcing and supporting it. Recent initiatives, such as the Army’s Data Literacy (DL101) requirement, are excellent advances, but literacy alone is not enough. We need systems built on quality data so that analysts, developers and leaders can work with clarity and confidence. A data-literate workforce is valuable, but one with high-quality, well-engineered data is a force multiplier. By investing in both people and data, modernization becomes the standard way the enterprise operates. 

Capt. Diana M. Ochoa is an FA26B data systems engineer who has worked on some of the Army Intelligence Enterprise’s enduring data and modernization challenges. She dual-hats as the senior technical advisor and applications and data branch chief at the National Ground Intelligence Center, where she supervises application development, data engineering, portfolio modernization and enterprise automation. 

Special thanks to Matthew Thompson, Ryan Campbell, Richard Hephner and the whole PBSAT team for their technical leadership, patience and partnership throughout this work. This project is a technological achievement and a representation of the joint commitment of a team dedicated to advancing the Army Intelligence Enterprise.