Enterprise Modernization Beyond Digital Engineering
Part 1 — A Framework for Preserving Enterprise Knowledge Across the Air Force Sustainment Center
Executive Summary
For two decades, the Air Force Sustainment Center has invested in upgrading the technology and engineering practices behind Maintenance, Repair, and Overhaul (MRO). Systems Engineering has matured. Software Engineering has been transformed. Digital Engineering, model-based systems engineering, cloud computing, artificial intelligence, and advanced analytics have changed how information is created, managed, and shared across the enterprise.
These investments have paid off. Engineering artifacts are more accessible than before. Digital models present unprecedented visibility into system design. Data flows across organizations that once worked in isolation. Collaboration happens at a scale unimaginable a generation ago.
And yet senior leaders across government and industry keep running into the same modernization problems that predated all of this technology. Programs still struggle with changing requirements. Organizations still lean on long-tenured personnel to explain why past decisions were made. New engineers still spend months reconstructing the reasoning behind earlier work before they can extend it. Digital repositories preserve artifacts, but not always the operational reasoning that gave those artifacts meaning.
These recurring problems are not shortcomings of Systems Engineering, Software Engineering, Digital Engineering, Enterprise Architecture, Data Engineering, or Knowledge Management. If anything, the Air Force Sustainment Center is one of the most sophisticated examples in government of these disciplines working together to sustain mission capability. The problems persist because modernization involves something none of these disciplines was built to address.
Modernization is usually treated as the engineering of systems, software, models, and data. This paper studies it from a different angle: as a continuous chain of knowledge transformations, in which operational experience becomes engineering decisions, engineering decisions become technical implementations, and implementations become repeatable organizational capability. Under that view, modernization can be evaluated not only by the artifacts it produces, but by the integrity of the transformations that produce them.
This paper describes Enterprise Knowledge Engineering (EKE), a complementary framework to examine how operational reasoning survives as it moves across organizational, functional, and technical boundaries. It is not a new discipline or another modernization initiative, but an approach for giving enterprise knowledge the same deliberate engineering attention already given to systems, software, models, and data.
1. Modernization Has Solved One Problem and Exposed Another
Enterprise modernization has never mattered more to national defense than it does today. The Air Force Sustainment Center maintains some of the world's most sophisticated weapon systems in an increasingly uncertain environment: aircraft stay in service for decades, supply chains span thousands of suppliers, and today's engineering decisions determine readiness years down the line. Meanwhile, experienced personnel retire, digital technology continues to evolve, mission priorities shift, and adversaries keep compressing the time available to decide.
Over the past two decades, the Department of the Air Force has responded with sustained investment: Digital Engineering, model-based systems engineering, enterprise data strategies, cloud computing, artificial intelligence, advanced analytics, and enterprise collaboration platforms (U.S. Air Force, 2020; Department of Defense, 2023). These projects have genuinely improved how information is created, shared, and governed. Engineering organizations today have capabilities that previous generations could scarcely imagine.
Despite that progress, one pattern keeps showing up across government and industry: organizations are good at preserving what was decided, and much worse at preserving why (U.S. Government Accountability Office [GAO], 2023).
Engineering documentation captures requirements, architectures, software baselines, technical orders, and configuration changes with real precision. Digital threads improve lifecycle continuity. Governance processes enforce accountability. But when experienced personnel retire or hand off responsibilities, the reasoning behind their decisions proves far harder to recover than the artifacts themselves.
Anyone who has worked inside a complex sustainment organization recognizes the pattern. A new engineer inherits a technical baseline and then spends weeks with subject-matter experts figuring out why one repair strategy beats another. A planner gets authoritative demand data but still has to track down the people who understood the assumptions behind the first forecast. A software team can find the requirement written five years ago, but not the operational context that justified it.
None of this reflects poor engineering. It is the natural consequence of how knowledge changes form as work crosses organizational boundaries. The Air Force has become highly effective at engineering the products of modernization — systems, software, digital models, enterprise data, lifecycle processes. What remains is understanding how operational knowledge survives as it moves between them.
MRO is usually described in terms of aircraft availability, depot throughput, engineering support, supply chain performance, and maintenance execution. Those are the right things to measure. But look at them together, as a system rather than a set of isolated functions (Checkland, 1999), and a more fundamental pattern emerges: every one of them depends on the continuous transformation of knowledge.
Maintainers observe recurring equipment behavior in the field. Engineers analyze those observations and work out the technical implications. Planners weigh resource restrictions and production schedules. Supply chain professionals assess inventory, repair capacity, and procurement timelines. Developers modify the software that runs enterprise processes. Technical orders get revised, procedures change, training gets updated — and eventually, all of it becomes standardized organizational capability, the same conversion of tacit experience into explicit, shareable knowledge that Nonaka and Takeuchi (1995) describe as the engine of organizational learning.
At every stage, knowledge changes representation — from experience to observation, analysis, requirements, and engineering decisions, which in turn become software, processes, technical orders, logistics plans, and maintenance practices.
The finished product of modernization is not simply a new system or a revised process. It is an organization that can work differently because operational knowledge has been successfully turned into repeatable capability. That is why modernization is often harder than adopting new technology: technology can be bought. Knowledge has to be transformed.
This is not a defense-specific problem. Manufacturers turn production knowledge into automated workflows. Hospitals translate clinical expertise into protocols and electronic health records. Utilities convert decades of operating experience into maintenance strategies for infrastructure that will outlive the people who built it. Banks continuously turn regulatory guidance and risk analyses into processes and software. Different missions, same pattern: these organizations succeed not just by producing accurate artifacts, but by preserving enough reasoning that the next generation does not have to reconstruct it from scratch.
That challenge is increasing as organizations adopt artificial intelligence. AI can summarize documents, spot patterns in large data sets, assist draft requirements, and automate standard knowledge work — but it is only as good as the knowledge it has access to. If the operational reasoning behind a decision is incomplete or disconnected from the artifact that documents it, AI will faithfully reproduce that gap rather than fix it. AI does not reduce the need for high-quality knowledge transformations. It raises the stakes on getting them right.
This is also why certain people become quietly necessary in sustainment organizations. Their value is not simply technical. It is that they remember why the enterprise arrived at its current state — the assumptions behind past decisions, the alternatives that were rejected, the constraints that influenced what was built. Their knowledge is the connective tissue between engineering artifacts across time. The goal of modernization is not to make that expertise unnecessary. It is to ensure the next generation inherits as much of it as possible via disciplined engineering practice rather than tribal memory.
3. Existing Disciplines Are Necessary — But Not Sufficient
None of this is a knock on Systems Engineering, Software Engineering, Digital Engineering, Enterprise Architecture, Data Engineering, or Knowledge Management. The Air Force Sustainment Center is one of the most sophisticated examples anywhere in government of these disciplines working together to sustain mission capability across exceptionally complex weapon systems.
Systems Engineering manages technical baselines and integrates complex systems, following the life cycle processes codified by the International Council on Systems Engineering (INCOSE, 2023) and ISO/IEC/IEEE 15288:2023. Software Engineering develops and evolves the applications that increasingly run sustainment operations, building on iterative methods that trace back to Boehm's (1988) spiral model and are now standardized in ISO/IEC/IEEE 12207:2017. Digital Engineering creates authoritative digital representations that improve lifecycle continuity (Department of Defense, 2023). Enterprise Architecture aligns business capabilities with technology investments, using the organized framework first proposed by Zachman (1987). Data Engineering keeps enterprise information governed and trustworthy. Knowledge Management develops methods for creating, sharing, and applying organizational knowledge (Nonaka & Takeuchi, 1995).
Enterprise Knowledge Engineering does not replace these disciplines. It evaluates the knowledge transformations that connect them.
Each of these disciplines has a clear purpose, established methods, and mature standards. None of them tries to solve every enterprise problem, because none of them was built to. That is fine — until a modernization effort stops respecting disciplinary boundaries, which is most of the time. A maintenance observation triggers an engineering investigation. That investigation generates revised requirements. Those requirements ripple through software changes, supply planning, procedures, technical orders, training, and, eventually, operational implementation. Along the way, artifacts change hands repeatedly and get reinterpreted by different communities of practice.
Existing disciplines govern each of those individual handoffs well. What none of them explicitly asks constitutes a broader question: how effectively does critical operational reasoning survive as it moves across organizational, functional, and technical boundaries?
That is a different question from evaluating any single system, requirement, model, or data set. It is about the continuity of reasoning that connects them.
Consider a common scenario. A depot team spots an emerging trend in failures. Engineers investigate and decide to change the inspection criteria. Analysts revise planning assumptions, logisticians adjust repair strategies, developers update supporting software, technical order managers revise guidance, and training organizations update their material. Every organization does its job. Every artifact gets updated. Every baseline stays under configuration control.
Years later, a new engineering team asks a familiar set of questions:
- Why was this inspection interval chosen?
- What assumptions justified this repair strategy?
- Under what conditions should the decision be revisited?
- What alternatives were considered and rejected?
Finding the artifacts is rarely the problem. Understanding the reasoning behind them is often not about any discipline failing, but about none of them being built to engineer reasoning as an object in its own right. Their job is to make sure systems integrate correctly, software behaves reliably, architectures remain aligned, data stays governed, and knowledge gets shared. Those are essential jobs. Modernization may also benefit from evaluating how reasoning changes representation as it crosses these disciplines — a complement to existing practice, not a competitor.
4. Introducing Enterprise Knowledge Engineering
A practical question follows: how should organizations evaluate the quality of enterprise knowledge transformations?
Current disciplines provide mature methods for evaluating systems, software, requirements, architectures, digital models, and data. Those methods remain the foundation of enterprise modernization. What is missing is a way to evaluate the transformations themselves — the translation of individual experience into engineering analysis, analysis into requirements, and requirements into software, technical orders, procedures, and planning assumptions. Every transformation adds value. Each also creates an opportunity for context to be simplified, abstracted, or separated from the artifact it originally informed.
Enterprise Knowledge Engineering (EKE) is introduced here as a framework for systematically asking the question: Can organizations verify that critical operational reasoning survives these conversions well enough to support future engineering and operational decisions? Treating knowledge transformation itself as an object of deliberate engineering follows the tradition established by Simon (1996) for studying the design of artificial, human-made systems.
EKE is not a new discipline, and it does not replace Systems Engineering, Digital Engineering, Software Engineering, Enterprise Architecture, Data Engineering, or Knowledge Management. It is a complementary evaluation framework focused on one specific question: Does the enterprise still understand why its artifacts exist, not just what they say?
EKE evaluates the quality of knowledge transformation across three layers.
The EKE framework assesses the quality of knowledge transformation through three complementary layers, each tackling a different aspect of how operational reasoning survives transformation.
Whether operational reasoning survives the transformation itself.
- Knowledge Fidelity — does the meaning of the knowledge stay intact as it changes form? A requirement can accurately describe a technical function while dropping the assumptions that motivated it. Fidelity is concerned with preserving intent, not just information — the distinction Nonaka and Takeuchi (1995) draw between tacit and explicit knowledge.
- Knowledge Traceability — extending traceability beyond technical artifacts — can subsequent practitioners reconstruct how an operational observation became an engineering decision, and eventually, an organizational capability?
- Knowledge Provenance — where did this knowledge originate, who contributed to it, and under what working conditions? That lineage provides context for future decisions.
Enterprise Stewardship
Whether knowledge stays useful long after the people who created it have moved on.
- Knowledge Governance — Is knowledge managed with clear ownership, lifecycle management, and accountability, so it evolves deliberately rather than by accident — the same discipline Weill and Ross (2004) describe for enterprise IT decision rights?
- Knowledge Validation — Does preserved knowledge stay operationally relevant as missions, technology, and priorities change? Retention alone is not enough — knowledge needs to stay current and trustworthy.
Organizational Value
Whether retaining this knowledge actually improves future capability.
- Knowledge Reuse — Can operational reasoning be applied beyond the circumstances that created it, without extensive reconstruction?
- Knowledge Granularity — Is knowledge preserved at the right level of detail? Too much is unmanageable; too little loses the context needed for good decisions. The right level depends on the decision the knowledge needs to support.
Perhaps the most important thing about EKE is what it does not try to do. It does not compete with Systems Engineering, replace Digital Engineering, redefine Knowledge Management, or supersede Enterprise Architecture. It operates alongside these disciplines, evaluating a concern that spans them all: the preservation and transformation of operational reasoning.
The Air Force Sustainment Center has spent decades building mature engineering capability. The goal here is not to add complexity or stand up a new discipline — it is to find out whether an explicit focus on knowledge transformations sharpens the return on the modernization investments already underway. Seen that way, EKE is less a new discipline than a new question: not just whether the enterprise engineered the right systems, but whether it preserved the comprehension future engineers will need to evolve those systems over the decades ahead.
5. What This Means for the Air Force Sustainment Center
Modernization is usually measured by concrete results: readiness, maintenance throughput, engineering cycle time, software delivery, supply chain performance, cost, and operational availability. Those measures matter and should not change. This paper proposes adding one more question: how effectively is enterprise knowledge preserved as modernization produces those outcomes?
For the Air Force Sustainment Center, that question matters because modernization never stays inside one organization's boundaries. Depot maintenance, engineering, logistics, software development, supply planning, contracting, financial management, and operational leadership are constantly exchanging information in pursuit of shared readiness goals. Each brings expertise the others lack; none holds the complete picture alone. Capability comes from collaboration, not individual excellence — which means every major modernization effort depends on specialists correctly interpreting information that other specialists created, often years earlier, under conditions that no longer exist.
When that handoff works, organizations inherit understanding, not just documentation. When it does not, they compensate with experience: subject-matter experts become the connective tissue among artifacts, institutional memory, and operational decisions. Every sustainment organization has these people — the engineer who remembers why a repair strategy was adopted fifteen years ago, the planner who understands the assumptions behind a recurring demand pattern, the developer who knows why an apparently minor business rule cannot be touched without breaking three downstream systems.
These people are invaluable, and their existence reveals something important: organizations commonly rely upon individuals to preserve relationships between artifacts that the enterprise itself does not preserve. As experienced personnel retire and modernization accelerates, that dependency gets harder to sustain — which makes workforce transition an enterprise engineering concern, not just a human resources one. Viewed this way, the goal is not simply to accumulate documentation. It is to preserve the enterprise's capacity to keep learning — what Senge (2006) calls the defining trait of a learning organization.
Digital Engineering, enterprise repositories, and AI meaningfully improve the ability to preserve information and accelerate engineering work, and their value will continue to grow. But they also raise the stakes on the underlying knowledge quality. AI can only examine the context it is given. Digital models faithfully represent whatever engineering information they contain. Repositories preserve the artifacts they are built to manage. None of these tools reconstructs reasoning that was never captured, or whose connections were quietly lost through successive handoffs.
That does not call for new organizational structures or another layer of governance. It calls for a different question: not just whether an artifact meets its technical requirements, but whether subsequent practitioners will have enough operational understanding to evolve it confidently and responsibly.
That question fits naturally with the Air Force Sustainment Center's long horizon. The Air Force Sustainment Center (AFSC) sustains weapon systems over timelines measured in decades, and today's modernization decisions will shape the engineers, maintainers, and planners who have not yet entered the workforce. Whether those future professionals can build on existing work without rediscovering it first is a real measure of enterprise resilience — and it is not unique to the Air Force. Any organization sustaining complex, long-lived systems eventually faces the same question, regardless of which technologies or org charts change around it:
Will the next generation inherit enough understanding to improve what this generation built, or will they have to rediscover why it was built in the first place?
6. Recommendations and Conclusion
This paper has not proposed a new engineering discipline, initiative, or technology platform. It has described a pattern spanning decades of enterprise modernization: organizations tend to preserve engineering artifacts more reliably than the reasoning that produced them.
That observation detracts nothing from the progress made in Systems Engineering, Software Engineering, Digital Engineering, Enterprise Architecture, Data Engineering, and Knowledge Management. Those disciplines have changed how complex enterprises design, sustain, and evolve mission-critical capability, and the Air Force Sustainment Center is proof of it. The question here is narrower: as modernization accelerates, should organizations also evaluate the knowledge transformations that connect these disciplines? Furthermore, how does that knowledge apply regarding your applications needs?
Enterprise Knowledge Engineering is offered as one way to explore that question — a complementary, technology-neutral framework rather than a new discipline. Whether it proves useful is an empirical question, best answered through limited application rather than debate. Three recommendations follow.
First, pilot it narrowly. Pick one active modernization initiative and examine how operational reasoning moves through its engineering lifecycle. The goal is not to prove EKE works — it is to see whether evaluating knowledge transformations surfaces anything that existing engineering reviews miss.
Second, fold it into existing reviews. Organizations already run architecture reviews, design reviews, readiness assessments, and configuration audits. Adding a knowledge-transformation lens to those activities costs little and adds no new bureaucracy.
Third, treat enterprise knowledge as a strategic engineering asset. Modernization investment increasingly targets systems, software, digital models, data, and AI. That investment pays off fastest when the operational reasoning behind it stays understandable, traceable, and reusable by the engineers, maintainers, and planners who come next — an obligation that lines up with the engineering profession's own commitments to competence and the public good (Association for Computing Machinery [ACM], 2012).
These recommendations are intentionally modest — EKE is a proposed framework that still needs empirical testing, not a new doctrine. But the underlying question is worth taking seriously, for the Air Force Sustainment Center and beyond. AFSC sustains some of the most complex weapon systems in the world within timelines measured in decades, while continuously integrating engineering, logistics, maintenance, software, planning, contracting, finance, and operations. Few organizations illustrate the stakes of enterprise modernization — or the cost of losing institutional understanding — more clearly.
The same reality applies well outside the Department of the Air Force. Technology changes. Missions evolve. People move on. Yet the need to understand why previous decisions were made stays constant.
Modernization has traditionally meant improving systems. The perspective offered here is broader: modernization is also the process by which organizations preserve, refine, and continuously transform the operational knowledge that lets those systems evolve. The organizations that hold a real advantage over the next decade may be distinguished less by the sophistication of their technology than by how well they preserve the reasoning that lets future generations grasp, adapt, and improve it.
If so, the next frontier of enterprise modernization may not be another platform, another repository, or another methodology. It may be the deliberate engineering of the knowledge transformations that connect them.
About This Research
This paper is the first in a planned series examining enterprise knowledge as an engineering concern. It presents Enterprise Knowledge Engineering as a conceptual framework rather than a prescribed solution, consistent with the recommendation that organizations pilot the concept before adopting it broadly. A companion paper, centered on practical approaches to implementing this framework within active modernization programs, is in development and will follow.
References
This bibliography reflects the authoritative sources across systems engineering, software engineering, digital engineering, enterprise architecture, and knowledge management that inform the argument in this paper. In-text citations have been aligned to this list; both should be verified against primary sources prior to publication.
Association for Computing Machinery. (2012). ACM code of ethics and professional conduct. https://www.acm.org/code-of-ethics
Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), 61–72. https://doi.org/10.1109/2.59
Checkland, P. (1999). Systems thinking, systems practice. Wiley.
Department of Defense. (2023). Digital engineering strategy implementation guidance. Office of the Under Secretary of Defense for Research and Engineering.
International Council on Systems Engineering. (2023). INCOSE systems engineering handbook (5th ed.). Wiley.
International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2017). Systems and software engineering — Software life cycle processes (ISO/IEC/IEEE 12207:2017).
International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2023). Systems and software engineering — System life cycle processes (ISO/IEC/IEEE 15288:2023).
Nonaka, I., & Takeuchi, H. (1995). The knowledge-creating company: How Japanese companies create the dynamics of innovation. Oxford University Press.
Senge, P. M. (2006). The fifth discipline: The art and practice of the learning organization (Rev. ed.). Currency/Doubleday.
Simon, H. A. (1996). The sciences of the artificial (3rd ed.). MIT Press.
U.S. Air Force. (2020). Air Force digital campaign. Department of the Air Force.
U.S. Government Accountability Office. (2023). Defense acquisitions annual assessment: Drive to deliver capabilities faster (GAO-23-105582). https://www.gao.gov/products/gao-23-105582
Weill, P., & Ross, J. W. (2004). IT governance: How top performers manage IT decision rights for superior results. Harvard Business School Press.
Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), 276–292. https://doi.org/10.1147/sj.263.0276
