Enterprise Modernization Beyond Digital Engineering

Part 2 — Enterprise Knowledge Engineering in Practice

Executive Summary

The first paper in this series laid out Enterprise Knowledge Engineering (EKE): a way of evaluating something most modernization programs never measure directly, whether the reasoning behind a decision actually survives the trip from someone's head into a requirement, a line of code, or a training manual. That survival is not a minor detail. It's the difference between technology that works the way it was intended to and technology that quietly drifts from the judgment that shaped it.

This paper follows one maintenance observation, drawn from Maintenance, Repair, and Overhaul (MRO) modernization work at the Air Force Sustainment Center, as it moves through engineering, planning, supply chain, software, and training. From there, it looks at where EKE's three evaluation layers show up inside work organizations are already doing, not some new layer bolted on top.

1. Every Modernization Effort Begins With People, Not Systems

Talk to most program offices about modernization and you'll hear about the visible parts first: cloud migrations, enterprise resource planning systems, digital engineering environments, artificial intelligence, integrated data platforms. That's not surprising. Those are the things you can procure, configure, and put a number on.

But focus on the platform long enough and you miss something that shows up in program after program: organizations that just invested heavily in new tools still turn to the same long-tenured staff to explain why something was done a certain way, years after the old technology is gone.

Before a single requirement gets written or a platform gets chosen, the modernization team is already leaning on experienced personnel, the ones who can explain how the enterprise works and why the exceptions exist in the first place.

A maintainer explains why a repair sequence breaks from the published procedure once certain conditions show up. A production superintendent walks through how priorities shift the moment aircraft availability becomes the constraint that actually matters. Engineers defend design decisions the same way. Supply planners justify why they sourced a part the way they did. Financial managers flag funding constraints that reshape a schedule in ways the technical team rarely sees coming.

That's how modernization starts: through conversation, demonstration, and explanation, long before requirements, workflows, or business rules exist in any formal sense. The knowledge the team runs into first is knowledge in its rawest form, contextual, interconnected, and hard to separate from the people who hold it.

It's not that these enterprises lack information. They maintain policies, technical orders, engineering drawings, and maintenance records. What the maintenance record usually captures is the action taken. What it leaves out is the operating condition or tradeoff that made that action the right call, and that part lives in meetings, informal decisions, and the memory of whoever happened to be in the room.

That gap is exactly why "we've always done it this way" comes up in so many process-discovery interviews, and why it satisfies so few of them. Sometimes a business rule traces back to a system limitation that stopped existing years ago. Sometimes an approval workflow still reflects an organizational structure that has since changed. Manual workarounds persist because they solved a real problem once, and nobody ever folded the fix back into the formal process.

Program plans have a name for this: dependency on key personnel. Organizations know success depends on capturing enough understanding from experienced staff before they retire, change assignments, or become unavailable. That risk is real. It's also a symptom of something larger: the enterprise depending on individuals to preserve connections between artifacts that the enterprise itself never captured.

At its core, every modernization effort requires interpreting the enterprise's accumulated reasoning before translating it into whatever comes next. A requirement can describe system behavior perfectly and still omit the operating context that justified it. A workflow diagram can be entirely accurate and still never explain why the exceptions exist.

A finished artifact rarely yields any nuance about the reasoning that produced it. You can read a well-built requirement and never learn which exception, tradeoff, or field observation shaped it. That's not a flaw in the writing, it's what happens to context every time knowledge moves through an increasingly structured form. That difficulty is exactly where EKE starts.

2. How Knowledge Changes Shape as It Moves Through the Enterprise

Organizational knowledge never sits still. It gets reinterpreted and reformalized constantly as work moves across the enterprise, and modernization doesn't start that cycle, it just accelerates it. Figure 1 illustrates this lifecycle, showing how experience becomes formalized knowledge and eventually feeds back into organizational capability and new experience.

Most enterprise knowledge starts life as pure experience: a maintainer's inspection observation, a planner's scheduling insight, an engineer's recognition of a recurring failure pattern. Nobody teaches that in a classroom; it builds up through repeated exposure, which is exactly why interviews, workshops, and process observation are the mechanism that makes tacit knowledge visible enough to preserve (Nonaka & Takeuchi, 1995).

Once someone articulates that understanding, it becomes a requirement, a business rule, or a specification. In that translation, a whole set of operational discussions, exceptions, and cautionary stories gets compressed into language built for clarity and verifiability, not context. Software can't implement a conversation, so formalization forces a team to decide what context stays attached to the requirement and what explanation gets safely omitted. Later teams inherit whatever call was made.

By the time requirements become architecture, software, technical orders, and training material, they've become the enterprise's institutional memory, and, somewhat paradoxically, the hardest place to recover the reasoning behind any of it. A system shows its behavior without explaining the tradeoff that produced it. So organizations compensate the way they always have: new experts emerge, informal explanations spread, and workarounds bridge the gap between documented process and operational reality.

Then the cycle begins again. Preservation works best as a standing engineering concern rather than a milestone completed at project kickoff, since every modernization effort relies on records from earlier work and creates records that later teams will need.

Recognizing this changes how success gets measured. Leaders can track whether the enterprise keeps preserving operational reasoning as knowledge evolves through each new transformation, because the lifecycle doesn't pause once a system goes live.

3. A Maintenance Observation, Traced Through the Enterprise

Here's how that plays out in practice.

An aircraft enters depot maintenance with a structural discrepancy that keeps recurring. During teardown, an experienced artisan notices something: the damage keeps showing up near an area previously thought unrelated to the original failure mechanism.

That observation stays informal until it reaches engineering review, even though it has already changed what the enterprise knows about the discrepancy.

It reaches engineering review, and historical repair records and fleet data confirm a broader pattern than initially suspected. Engineering concludes that inspection criteria should change. That conclusion adds rigor, but the original observation still holds context the formal analysis may never retain.

From there, the knowledge keeps traveling. Planners assess how the added inspection time affects production schedules. Supply chain specialists reconsider demand forecasts for replacement components. Software teams update workflow logic to support the revised inspection process. Technical order managers revise documentation. Training organizations update instructional material, ideally so the next inspector understands both the new procedure and the condition that prompted it.

Every organization contributes real expertise, and every one reshapes the knowledge to fit its own purpose. The planner is focused on production flow, the developer on system behavior, both several steps removed from the structural integrity and fatigue mechanism that originally justified the change. That's the core observation behind EKE: each organization interprets operational knowledge for its own purpose, and that reshaping is what changes what the next organization receives.

Figure 2 illustrates how that reshaping can occur as a single maintenance observation moves through the enterprise.

By the time implementation is complete, that original observation exists at once as revised engineering analysis, updated inspection procedures, modified software logic, planning assumptions, technical orders, and training material. Each artifact can look complete within its own function. The full reasoning is only visible when the records are examined together.

Years later, a newly assigned engineer inherits all of it without ever meeting the artisan who started the chain. If the reasoning survived each handoff, that engineer can extend the work with confidence. If it didn't, the enterprise ends up asking questions it already answered once, such as why the inspection interval was chosen or what assumptions justified the repair strategy.

These moments rarely point to bad engineering. More often, they show the enterprise preserving its artifacts more carefully than the reasoning connecting them, through a long series of individually reasonable decisions rather than any single failure. A requirements workshop, for example, can simplify an operational explanation just to keep the session moving: the analyst captures the decision but not the maintenance exception that prompted it, and by the next design review that exception has quietly dropped out of the record. Architecture reviews and training materials trim in similar ways, for similar reasons, and the combined effect determines how much of the enterprise's own reasoning survives.

4. Putting Enterprise Knowledge Engineering Into Existing Work

EKE doesn't ask programs to do anything new. It adds one knowledge-preservation question to reviews and engineering activities that modernization programs already perform, from knowledge discovery and requirements development to systems engineering and organizational change management. The question stays the same at each stage: has the reasoning behind this decision been preserved well enough for the next organization to understand, apply, and improve it?

What that question actually looks like changes depending on where it's asked, as shown in Table 1:

Table 1. EKE Questions Across Existing Enterprise Activities

That last row deserves more attention than it usually gets. AI doesn't fill gaps in the enterprise record, it reflects them: a system trained on incomplete rationale will draft requirements, summaries, and recommendations with the same gaps. Better source material and preserved rationale give the model a stronger basis for that work, though human review still doesn't go away.

None of this requires new technology to get started. Organizations can begin with the practices they already have. In an MRO modernization workshop, for instance, an SME could explain an inspection exception while the requirement, the unresolved ambiguity, and the source basis are recorded together in the same place. That record would still be available when the rule later enters software, training, and technical orders.

The discipline must come first. Technology just makes it far easier to sustain at scale.

5. Measuring Whether Knowledge Survived the Journey

The first paper in this series laid out EKE's three evaluation layers, as shown in Figure 3. In practice, each one fails in its own recognizable way: a transformation-integrity problem shows up as a decision nobody can trace back to its source, a stewardship problem shows up as guidance that was accurate once but that nobody has revisited since, and an organizational-value problem shows up as knowledge that exists but sits at the wrong level of detail for anyone to actually use.

Organizations can observe these patterns directly in ongoing modernization work, without new instrumentation.

Take a new engineer who inherits a technical baseline for a repair strategy adopted a decade earlier, with only the approved procedure to go on. That single situation can strain all three layers at once: the reasoning was never captured cleanly, so transformation integrity is weak; no one has revisited whether the original conditions still hold, so stewardship has lapsed; and the same reconstruction work will likely repeat on the next program that touches this baseline, so the knowledge isn't being reused. No dashboard captures that cost. It shows up in the weeks the engineer spends tracking down people who remember why.

It's also worth watching how much depends on any one person. Every enterprise relies on experienced professionals whose judgment is invaluable; that's not the issue. The practical test is whether the organization can explain an important engineering decision when the original expert is unavailable. Sophisticated surrounding technology doesn't reduce that dependency on its own.

Recommendations

• Apply the framework to a modernization effort currently underway. Pick one initiative, and trace how operational reasoning moves from discovery through implementation. The goal isn't to prove EKE works. It's to see whether the perspective surfaces something existing reviews miss.
• Fold a knowledge-transformation check into reviews that already happen. Requirements reviews, architecture reviews, configuration control boards, and readiness assessments are natural checkpoints for this. Asking whether sufficient reasoning survived needs no new governance structure, just a broader question inside work already considered essential.

The same logic applies to enterprise knowledge generally: as investment shifts toward software, digital models, data, and AI, that investment pays off fastest when the reasoning behind it stays understandable to the people who inherit it next.

6. Conclusion

Return to the artisan's observation from Section 3. Years from now, whether that decision still helps anyone will depend less on which software recorded it and more on whether the reasoning behind it remains recoverable. Technology implements decisions that organizations must sustain and future teams will inherit.

EKE evaluates how much operational understanding remains traceable as experience becomes an enduring capability. Organizations get more out of modernization when they preserve enough reasoning for later teams to understand and adapt what was built, rather than simply inheriting the artifact and rediscovering the reasoning from scratch.

EKE can be tested without standing up a new office or governance structure. Select one active modernization effort and trace an operational decision from discovery into requirements, implementation, and training. Wherever the reasoning becomes difficult to recover, the enterprise has found a knowledge-preservation gap worth addressing.

About This Research

This paper is the second in a continuing series examining EKE as a complementary framework for enterprise modernization. The first paper established the conceptual foundation; this one applies it to a representative modernization scenario without introducing new governance or replacing established engineering disciplines. The third paper in the series will apply the framework to a full Air Force Sustainment Center MRO modernization case study, looking for opportunities to validate it empirically.

References

Nonaka, I., & Takeuchi, H. (1995). The knowledge-creating company: How Japanese companies create the dynamics of innovation. Oxford University Press.

Getting Started with ACC3 International

ACC3 International recommends a focused demonstration with your team or designated staff representatives. Please contact ACC3 International to schedule a demonstration of Alchemist AI Pro™ and assess how Enterprise Knowledge Engineering can strengthen knowledge continuity across your own modernization programs.