Enterprise AI Strategy: Transform Your Development Team Before AI Transforms It for You

Most medium and large enterprises are currently asking the same question:

How can we introduce AI into our applications?

Perhaps there is a more important question:

How should AI change the way our development organization itself operates?

Every major enterprise software vendor is adding copilots, assistants and increasingly autonomous agents to its products.

The obvious strategy is to buy them.

AI for the ITSM platform.
AI for the ERP.
AI for the CRM.
AI for development.
AI for analytics.
AI for operations.

Some of these products will undoubtedly provide significant value.

But I believe medium and large enterprises should simultaneously pursue another strategy:

Develop Agentic AI as a core internal engineering capability.

For organizations with significant Java and Spring Boot expertise, frameworks such as Spring AI  together with alternatives such as LangChain4j provide an interesting opportunity.

And the main reason is not simply cost.

The bigger opportunity is to start building the development organization that companies will need in the AI era.

1. The first return on investment may be your own development team

There is a tendency to think about enterprise AI primarily in terms of business-process automation.

But one of its first and most valuable users can be the IT organization itself.

Imagine a development department responsible for 50, 100 or several hundred applications.

Traditionally, maintaining such an estate requires distributing knowledge across teams:

• Java specialists;

• database specialists;

• integration specialists;

• ERP specialists;

• ITSM specialists;

• legacy-platform specialists;

• DevOps engineers;

• functional analysts;

• application-specific experts.

This specialization will not disappear.

But AI can dramatically change how much specialization needs to be permanently allocated to each application.

An AI-augmented engineering environment can give developers immediate access to application documentation, source code, database schemas, historical incidents, architecture decisions, APIs, operational procedures and previous solutions.

The consequence could be profound:

knowledge becomes easier to transfer between engineers.

And when knowledge becomes easier to transfer, teams become much more flexible.

2. From application teams to flexible engineering teams

For decades, enterprise IT organizations have frequently structured development around applications.

Team A knows Application A.

Team B knows Application B.

A few people understand a legacy system that nobody else wants to touch.

Someone leaves the company and suddenly an enormous amount of operational knowledge disappears with them.

AI creates the possibility of progressively changing this model.

Instead of relying exclusively on permanent application-specific knowledge, companies can build an Enterprise Engineering Knowledge Layer combining:

Source Code + Documentation + Architecture + Incidents + Databases + APIs + Operational Knowledge

with:

RAG + Agents + Tools + MCP + Enterprise Models

Developers can then use this layer to understand unfamiliar applications much faster.

The objective is not to pretend that every developer suddenly becomes an expert in every technology.

The objective is more realistic and potentially more valuable:

Reduce the cost of moving engineering capacity from one application or technology to another.

That is organizational agility.

3. Smaller teams could manage larger application estates

This may become one of the most important consequences of AI-assisted software engineering.

Today, maintaining ten different enterprise applications may require knowledge distributed across many specialists.

Tomorrow, a smaller group of experienced engineers supported by AI may be capable of understanding, maintaining and evolving a much broader application portfolio.

AI can help them:

• navigate unfamiliar codebases;

• understand legacy code;

• explain database structures;

• locate business rules;

• analyse incidents;

• generate tests;

• propose changes;

• understand APIs;

• produce documentation;

• compare historical solutions;

• identify dependencies;

• accelerate technology migrations.

The engineer remains responsible for the result.

But the amount of context an engineer can effectively manage increases enormously.

That changes the economics of development departments.

Not simply because fewer lines of code need to be written manually.

But because organizational knowledge becomes scalable.

4. The competitive advantage is flexibility, not headcount reduction

It would be a mistake to interpret this strategy simply as:

“AI means we need fewer developers.”

The more interesting equation is:

AI + Strong Engineers = Greater Engineering Capacity

A flexible AI-enabled team can potentially move much faster when priorities change.

If one application suddenly generates a critical workload, engineering capacity can be redirected.

If a legacy application must be migrated, engineers can acquire its context faster.

If an experienced developer leaves, part of the application's knowledge remains captured in the corporate AI environment.

If a new technology appears, developers have an intelligent assistant helping them understand and adopt it.

If a business unit suddenly requires a new integration, the team already has reusable tools and connectors.

This makes the development organization not only more efficient.

It makes it more adaptable.

And adaptability may be considerably more valuable than pure cost reduction.

5. This also changes what it means to be a developer

AI is becoming extraordinarily good at generating code.

Therefore, companies should probably not optimize their engineering organizations around the assumption that manually producing code will remain the developer's primary source of value.

The value moves upward.

From:

writing code

towards:

understanding systems -> designing solutions -> defining constraints -> orchestrating AI -> validating results -> integrating systems -> governing execution

The future enterprise developer may therefore become much more multidisciplinary.

A strong Java/Spring engineer who understands APIs, databases, security and enterprise architecture can use AI to operate across areas that previously required much deeper technology-specific knowledge.

This could lead to an evolution such as:

Software Developer

            ↓

AI-Augmented Software Engineer

            ↓

Agentic Software Engineer

            ↓

Agentic Architecture Engineer

The companies that start developing these skills now will have an important advantage when this transformation accelerates.

6. Spring AI is therefore more than another framework to learn

This is why I believe technologies such as Spring AI or LangChain4j should not be treated simply as another item on the technical training roadmap.

The strategic objective is not:

“Our developers should learn Spring AI.”

It is:

“Our development organization should learn how to engineer software in a world where AI models are becoming another programmable component of enterprise architecture.”

Spring AI can be particularly interesting for organizations already invested in Java and Spring because developers do not need to abandon their existing engineering ecosystem.

They can progressively add:

• model abstraction;

• structured outputs;

• tool/function calling;

• RAG;

• vector search;

• conversation memory;

• MCP;

• agentic workflows;

• model routing;

• evaluation;

• guardrails;

• observability.

The transition can therefore be evolutionary rather than revolutionary.

7. Use your own applications as the training ground

There is another strategic advantage to starting internally.

Instead of training developers through isolated AI courses and demonstrations, companies can use their real application portfolio.

Start with a simple application.

Connect its documentation using RAG.

Then expose one read-only API as a tool.

Add historical incidents.

Connect the source repository.

Introduce database metadata.

Then allow the agent to correlate information between these sources.

The first objective should not be to create a fully autonomous agent.

The objective should be to create engineers who understand how to build, constrain and operate agentic systems.

Each internal project simultaneously creates:

Business Value + Reusable AI Infrastructure + Engineering Knowledge

That combination makes the investment particularly powerful.

8. Then extend the same capability across the enterprise

Once this engineering capability exists, the organization can move beyond development assistance.

The same architecture can progressively connect:

ITSM + ERP + CRM + Databases + Documents + Source Code + Monitoring + APIs + Legacy Systems

through controlled APIs, MCP servers and operational adapters.

An agent could analyse an incident in one platform, search historical information in another, retrieve technical documentation, inspect an application's operational state and create a development task elsewhere.

This is where internal AI capability becomes strategically different from simply purchasing individual AI products.

The organization begins to own the cross-system intelligence layer.

9. Vendor AI still has an important role

This does not mean enterprises should stop buying AI capabilities from software vendors.

A vendor may have extremely sophisticated knowledge of its own product.

Its agent may be the best tool available for operating that particular platform.

Use it.

But the enterprise should ideally avoid making every vendor's AI its own isolated intelligence island.

A better model may be:

Enterprise Agentic Layer

                ↓

Corporate Agents / Orchestration

                ↓

MCP / APIs / Controlled Tools

                ↓

Vendor AI Agents + Enterprise Applications + Databases + Documents + Legacy Systems

The internal architecture orchestrates capabilities rather than attempting to replace every commercial product.

10. Model independence becomes another strategic advantage

The same principle applies to LLM providers.

An enterprise should avoid unnecessarily coupling its architecture to a single model.

Different workloads may eventually use different models.

A complex reasoning problem may justify an advanced frontier model.

A simple classification task may use a smaller inexpensive model.

Sensitive information may require an internally hosted or even air-gapped model.

Future models will almost certainly outperform today's models.

The architecture should therefore make models replaceable components.

That provides both negotiating power and technological flexibility.

11. Cost savings become a consequence, not the strategy

There can certainly be substantial financial advantages.

Instead of purchasing premium AI licenses across every enterprise platform and for every user, organizations can selectively consume models through APIs or run appropriate models internally.

But exact savings will vary enormously depending on usage, infrastructure, support, security and operational requirements.

Therefore, I would not build the business case around a claim such as “AI will reduce costs by 80%.”

The stronger business case is:

Greater engineering productivity.
Greater team flexibility.
Faster knowledge transfer.
Reduced dependency on individual specialists.
Reusable integrations.
Cross-system orchestration.
Model independence.
Vendor independence.
And potentially lower costs.

Cost reduction is one benefit.

Organizational transformation is the strategy.

12. Start now but start small

The first project does not need 20 agents and 50 enterprise systems.

A much better starting point might be:

Spring Boot + Spring AI + RAG + One Enterprise Application

For example:

1. Give the agent access to technical documentation.

2. Connect it to historical incidents.

3. Expose one read-only enterprise API.

4. Allow it to correlate those sources.

5. Add authentication, authorization and auditing.

6. Evaluate its answers systematically.

7. Measure token consumption, latency and cost.

8. Let developers use it on real maintenance work.

9. Learn from the failures.

10. Gradually introduce additional applications and tools.

The first KPI should perhaps not even be financial.

Measure:

How much faster can an experienced developer understand an application they have never worked on before?

That metric could tell us much more about the future of enterprise development than the number of lines of code generated by an LLM.

The development department as a strategic AI asset

For me, this leads to a broader conclusion.

The companies best positioned for the next phase of AI may not necessarily be those that purchase the largest number of AI products.

They may be those that transform their existing development organizations fastest.

A company that already has experienced developers who understand its applications, integrations, data, business processes and security has an extraordinary asset.

Don't discard that knowledge.

Amplify it with AI.

Train those engineers to build RAG systems, agents, tools, MCP servers, evaluation frameworks and secure AI architectures.

Use AI to make application knowledge transferable.

Use it to reduce technological barriers between teams.

Use it to allow smaller, highly skilled teams to operate across larger application portfolios.

Use it to turn developers from specialists tied to individual systems into engineers capable of navigating an entire enterprise architecture.

And simultaneously build an intelligence layer that belongs to the company rather than to any individual software or AI vendor.

The strategic transition may ultimately look like this:

Application-Centric Development Teams

                ↓

AI-Augmented Flexible Engineering Teams

                ↓

Cross-System Agentic Engineering

                ↓

Enterprise Intelligence Platform

That is why investing in internal Agentic AI expertise today should not be considered simply another technology initiative.

It is an investment in the future operating model of the development organization itself.

CAD + Plotter vs. AI + LLMs: What the Architecture Revolution Can Teach Software Engineering

Every technological revolution has its winners, its losers, and its lessons.

One of the best historical examples happened in architecture during the 1980s and 1990s, when Computer-Aided Design (CAD) and plotters transformed the way buildings were designed and documented.

The biggest impact was not on architects. It was on draftsmen.

Entire teams whose role was to transform architects' sketches into technical drawings suddenly found that software could produce cleaner, faster and more consistent drawings than manual drafting ever could.

The skills that had defined the profession for decades (perfect line work, lettering, manual precision) lost much of their commercial value almost overnight. Many professionals successfully adapted and became CAD specialists. Others unfortunately did not.

Architecture did not disappear. Quite the opposite. Projects became larger, more ambitious and more complex because producing technical documentation became dramatically faster and cheaper.

Looking back, CAD didn't destroy architecture. It transformed the skills that created value.

Today, software engineering appears to be entering a remarkably similar transition.

Large Language Models are rapidly automating many of the activities traditionally assigned to junior developers:

• boilerplate code
• CRUD implementations
• unit tests
• documentation
• API integrations
• refactoring
• code explanations

Once again, the repetitive execution layer is becoming increasingly automated.

And once again, the profession itself is unlikely to disappear.

Software demand continues to grow, and AI will almost certainly accelerate it by making many applications economically viable that previously weren't. However, history also suggests that productivity gains alone do not guarantee a healthy transition.

There is one important difference between the CAD revolution and today's AI revolution.

CAD was deterministic. It only drew what the architect explicitly instructed.

Modern AI is probabilistic. It proposes solutions, writes code, reasons over documentation, identifies bugs, suggests improvements and increasingly behaves like an autonomous collaborator rather than a sophisticated tool.

That makes today's transformation considerably deeper.

But my biggest concern is not whether AI will replace programmers. It is how we train the next generation of software engineers.

For decades, junior architects learned by drafting drawings. The work was repetitive, but it forced them to understand construction details, standards, dimensions and how buildings actually came together.

Similarly, junior software engineers have traditionally learned by implementing small features, fixing bugs, writing tests and gradually understanding increasingly complex systems.

If AI performs most of those implementation tasks, we must ask ourselves an uncomfortable question:

How will tomorrow's senior engineers be developed?

At this point, a paradox emerges. Many organizations are already asking a perfectly rational business question:

If a senior engineer, assisted by AI, can deliver the work that previously required several junior developers, why continue hiring as many junior developers?

From a short-term productivity perspective, the argument is compelling. But it also raises a much more fundamental question.

Traditionally, junior developers were not simply an additional pair of hands, they were the talent pipeline from which future senior engineers, technical leads and software architects emerged.

If AI increasingly becomes every senior engineer's "junior developer", who becomes tomorrow's senior engineer?

Perhaps the most important challenge of the AI era is not replacing junior developers. It is ensuring that we do not unintentionally replace the learning journey that has produced generations of experienced engineers.

In my opinion, AI is an extraordinary productivity multiplier. But it also amplifies knowledge or the lack of it. An experienced engineer uses AI to accelerate work because they can evaluate the generated solution.

A junior engineer without strong foundations may accept AI-generated code simply because it compiles and appears correct. That is a dangerous illusion. Writing code has never been the hardest part of software engineering.

Understanding why the code works, how it interacts with the rest of the system, and whether it satisfies the business problem has always been the real challenge.

AI dramatically reduces the cost of writing software. It does not reduce the cost of understanding software. This makes another discipline even more critical than before: Requirements engineering.

AI will always generate an answer. Even if the requirements are incomplete. Even if they are ambiguous. Even if they are contradictory.

If we fail to define business requirements precisely and simply ask AI to "build the feature", we risk producing incorrect software faster than ever before.

The old principle still applies: Garbage in, garbage out. The difference is that today's garbage may become thousands of perfectly compiling lines of code in seconds.

There is another aspect that deserves more attention. Many junior developers begin their careers in consulting companies, often working on customer projects with limited day-to-day mentoring.

Traditionally, they learned by writing code themselves, making mistakes, receiving reviews and gradually building intuition under the guidance of more experienced colleagues.

If AI starts replacing not only implementation but also that learning process and organizations fail to strengthen mentoring and technical supervision we may unintentionally create a generation of developers who deliver software faster than ever while developing a much weaker understanding of software engineering fundamentals.

That is not an AI problem. It is a leadership and training problem.

The lesson from CAD is not that technology eliminates professions. It is that professions evolve.

Draftsmen who embraced CAD remained valuable.Those who refused to adapt struggled.

Software engineering will likely follow the same path. The most valuable developers won't necessarily be those who write the most code manually.

They will be those who understand systems, architecture, business needs, security, maintainability, and who know when AI is right and when it is confidently wrong.

Perhaps the biggest lesson is this: AI should accelerate learning, not replace it.

If we allow junior developers to rely on AI before they understand software engineering fundamentals, we risk weakening the very pipeline that produces tomorrow's senior engineers.

History may not repeat itself exactly. But if the CAD revolution taught us anything, it is that adopting a new tool is only half the challenge. The other half is redesigning how we develop the professionals who use it.

 

Using AI to Preserve Knowledge and Accelerate Maintenance of Enterprise Java Applications

Introduction

Enterprise Java applications often remain in production for decades, supporting critical business processes such as inventory management, order processing, logistics, finance, manufacturing and customer services. Although these systems continue to deliver considerable business value, organizations frequently encounter a common problem: the gradual loss of technical knowledge.

Developers move to other projects, documentation becomes outdated, and maintenance increasingly depends on a small number of specialists who understand the application's internal behavior. Eventually, the greatest risk is no longer the technology itself, but the disappearance of the knowledge required to maintain and evolve it.

Artificial Intelligence offers an opportunity to fundamentally change this situation.

The objective is not to replace the software engineer responsible for maintaining the application. Enterprise software maintenance still requires experienced professionals capable of understanding software architecture, making design decisions, validating business rules and ensuring software quality.

Instead, the goal is to provide an experienced Java architect or software engineer with an intelligent assistant capable of understanding the application almost as quickly as its original development team. Once the initial learning phase is complete, the AI continuously assists the engineer by accelerating incident resolution, improving the quality and safety of software changes, generating technical documentation, identifying architectural dependencies, and even helping understand the business processes implemented by the application.

Rather than replacing engineers, the proposed solution creates a permanent knowledge platform that captures years of technical expertise and transforms it into an intelligent maintenance assistant available throughout the application's entire lifecycle.

 

Proposed Solution

The proposed solution is based on an on-premise AI platform combining modern Large Language Models (LLMs), Retrieval-Augmented Generation (RAG), semantic search, automated reverse engineering and continuous operational monitoring.

Rather than training a custom model specifically for the application, the platform continuously builds a structured knowledge repository by analysing every available source of information. The LLM consults this repository through a RAG architecture, allowing it to answer questions using accurate, up-to-date and verifiable project knowledge.

The implementation naturally evolves through four project phases:

1. Architecture Preparation
2. Knowledge Acquisition
3. RAG Construction
4. Automated Reverse Engineering

Once these phases have been completed, the platform becomes an AI-powered maintenance assistant that continuously evolves alongside the application.

 

Recommended Architecture

The proposed architecture is composed of several independent but highly integrated layers.

Knowledge Sources

The platform continuously ingests information from multiple technical and functional sources:

• Java source code
• Relational Database metadata
• Configuration files
• User Interface descriptions
• Functional documentation
• Technical documentation
• Source code repositories
• Application logs
• Monitoring platforms
• Issue management systems
• Architecture diagrams
• Deployment pipelines

 

Ingestion Layer

The ingestion layer is responsible for collecting and normalising information.

Typical responsibilities include:

• Repository connectors
• Metadata extraction
• Source code parsing
• Document parsing
• Content chunking
• Metadata enrichment
• Continuous synchronization

 

Knowledge Base

The processed information is transformed into semantic embeddings and stored inside the knowledge repository.

The knowledge base typically contains:

• Vector Database
• Semantic Index
• Metadata Index
• Knowledge Graph
• Hybrid Search Index

This repository becomes the technical memory of the application.

 

AI Orchestration Layer

The orchestration layer represents the intelligence of the platform.

Instead of simply forwarding user questions to the LLM, this layer builds the complete execution context.

Its responsibilities include:

• Query Understanding
• Semantic Search
• Context Assembly
• Prompt Orchestration
• Tool Calling
• Conversation Memory
• Context Compression
• Security Policies
• LLM Interaction
• Response Generation
• Source Citation

Prompt Orchestration is one of the most important components of the solution. It dynamically constructs the final prompt sent to the LLM by combining retrieved documents, source code, database metadata, operational information, previous conversation context and task-specific instructions.

 

Applications

Once deployed, the platform provides several capabilities:

• AI Technical Assistant
• Incident Analyzer
• Code Explorer
• Dependency Explorer
• Business Process Explorer
• Documentation Generator
• Change Impact Analyzer
• Refactoring Assistant

 

Live Operational Connections

To keep the knowledge continuously updated, the platform should maintain live connections with operational systems such as:

• Source Code Repository
• Relational Database metadata
• Logging Platform
• Monitoring Platform
• CI/CD Pipeline
• Issue Tracking System
• Documentation Repository

These connectors ensure that the assistant continuously learns from new deployments, incidents and software evolution.

 

Information Required by the AI Platform

The effectiveness of the assistant depends directly on the quality and completeness of the information supplied during the knowledge acquisition process.

Source Code

The complete Java application should be indexed, including:

• Controllers
• Services
• Repositories
• Entities
• DTOs
• Mappers
• Validation rules
• Batch jobs
• Scheduled tasks
• Security configuration
• Integration services
• Unit and integration tests

The objective is to understand not only individual classes but also the relationships between components.

 

Relational Database

The AI should analyse the complete logical database model:

• Tables
• Columns
• Relationships
• Primary Keys
• Foreign Keys
• Constraints
• Views
• Functions
• Stored Procedures
• Triggers
• Indexes

This information allows the assistant to reconstruct the application's data model.

 

User Interface

Business knowledge is often better represented by the application's user interface than by the source code itself.

Useful information includes:

• Screen captures
• Navigation flows
• Field descriptions
• User manuals
• Functional specifications

This enables the AI to relate technical implementation with actual business operations.

 

Documentation

Every available document should be incorporated:

• Functional Specifications
• Technical Specifications
• Architecture Documents
• Deployment Guides
• API Documentation
• Integration Specifications
• Existing Diagrams

 

Operational Knowledge

Production experience represents one of the most valuable knowledge sources.

The platform should ingest:

• Historical incidents
• Root Cause Analysis reports
• Previous fixes
• Frequently executed SQL queries
• Production logs
• Stack traces
• Monitoring alerts

Over time, operational knowledge becomes part of the assistant's expertise.

Phase 1 Architecture Preparation

The first phase focuses on designing the AI ecosystem.

Typical activities include:

• Selecting the on-premise LLM
• Selecting the Vector Database
• Designing the RAG architecture
• Designing the AI Orchestration Layer
• Defining metadata models
• Defining security policies
• Identifying information sources
• Designing update mechanisms
• Defining governance policies

At this stage no application knowledge has yet been generated. The objective is to prepare the platform.

 

Phase 2 Knowledge Acquisition

Once the infrastructure is available, the platform begins collecting information from every available source.

Inputs include:

• Source Code
• Relational Database metadata
• Documentation
• User Interfaces
• Configuration Files
• Architecture Diagrams
• Logs
• Monitoring Information
• Incident History

Each source is parsed, divided into semantic chunks, enriched with metadata and stored inside the knowledge repository.

This phase creates the knowledge foundation upon which the entire system will operate.

 

Phase 3 RAG Construction

After acquiring the available knowledge, the Retrieval-Augmented Generation platform is built.

Activities include:

• Embedding generation
• Vector indexing
• Metadata indexing
• Knowledge graph construction
• Hybrid search configuration
• Semantic retrieval optimisation
• Prompt template design
• Prompt orchestration workflows
• Tool integration
• Context ranking
• Response validation

The resulting RAG platform allows the AI to retrieve accurate and relevant technical information before generating any response.

Unlike traditional LLM usage, every answer is grounded in the organization's own technical knowledge.

 

Phase 4  Automated Reverse Engineering

Once sufficient knowledge has been collected, the AI begins reconstructing the application's architecture automatically.

This is where the platform starts generating new technical knowledge rather than simply indexing existing information.

Technical Models

The AI can automatically generate:

• Application Architecture
• Layer Dependencies
• Component Relationships
• Service Catalogue
• API Catalogue
• Package Dependencies
• Deployment Architecture

 

Data Models

The assistant reconstructs:

• Logical Data Models
• Entity Relationships
• Data Flows
• Database Dependencies

 

Business Models

Business knowledge extracted from code and documentation includes:

• Business Entities
• Business Rules
• Validation Rules
• Decision Logic
• Domain Concepts

 

Workflow Reconstruction

The AI can automatically identify workflows such as:

• Order Creation
• Order Validation
• Inventory Allocation
• Stock Reservation
• Inventory Updates
• Shipment
• Order Cancellation
• Inventory Adjustments

 

Dependency Analysis

The assistant identifies:

• Cross-module dependencies
• Component interactions
• Service dependencies
• Data dependencies
• External integrations

 

Change Impact Analysis

The platform can estimate:

• Components affected by a modification
• Potential regressions
• Downstream impacts
• Risk areas

 

Automatic Documentation

The reverse engineering process continuously generates documentation such as:

• Architecture Documentation
• Technical Documentation
• API Documentation
• Data Model Documentation
• Business Process Documentation
• Sequence Diagrams
• Component Diagrams
• Workflow Diagrams
• Dependency Diagrams

At this point, the organization has effectively rebuilt the technical knowledge of the application, even if much of the original documentation has been lost.

 

Operational AI-Assisted Maintenance

Once the platform has completed the reverse engineering process, it becomes an intelligent assistant for day-to-day software maintenance.

Incident Analysis

The assistant can:

• Analyse production incidents
• Explain stack traces
• Suggest root causes
• Recommend diagnostic SQL queries
• Identify affected components

 

Business Understanding

Engineers can ask questions such as:

• How is inventory updated?
• Which validations occur before an order is confirmed?
• What happens when an order is cancelled?
• Which services update stock levels?

 

Code Understanding

The assistant explains:

• Business logic
• Algorithms
• Class responsibilities
• Method interactions
• Design patterns
• Technical decisions

 

Change Impact Analysis

Before modifying the application, the AI can identify:

• Impacted services
• Impacted database objects
• Affected APIs
• Dependencies
• Potential regressions

 

Safe Change Assistance

Rather than changing the software automatically, the assistant proposes improvements for human review.

Typical outputs include:

• Implementation suggestions
• Refactoring opportunities
• SQL improvements
• Performance recommendations
• Security improvements
• Regression test suggestions

Human validation remains mandatory before any deployment.

 

Documentation Assistance

The platform continuously generates and updates:

• Technical documentation
• Business documentation
• Architecture diagrams
• API descriptions
• Operational guides

 

Continuous Knowledge Evolution

The platform is that it never stops learning.

Every software release enriches the knowledge repository through:

• New source code
• Database schema evolution
• New documentation
• Production incidents
• Monitoring information
• User feedback
• Deployment history

The RAG repository continuously evolves, making the assistant increasingly accurate and valuable over time.

Instead of becoming obsolete, the knowledge platform grows alongside the application.

Conclusion

The proposed solution should not be viewed as an attempt to automate software maintenance or replace experienced software engineers.

Its real purpose is to preserve the technical knowledge accumulated over many years and provide software architects and maintenance engineers with an intelligent assistant capable of understanding both the software architecture and the underlying business processes in a fraction of the time traditionally required.

By combining modern Large Language Models, Retrieval-Augmented Generation, automated reverse engineering, semantic search and continuously evolving operational knowledge, organizations can transform legacy enterprise applications into self-documented systems supported by AI.

The result is not autonomous maintenance, but AI-Augmented Software Engineering: significantly faster onboarding of new maintainers, quicker incident resolution, safer software evolution, continuously updated documentation, deeper understanding of business processes, and ultimately, a substantial reduction in the long-term maintenance cost and risk of enterprise applications.

It is worth noting that several commercial solutions already pursue a similar vision of AI-assisted software engineering. Among them, Sourcegraph Cody is probably one of the closest, providing semantic code search, repository-wide understanding, Retrieval-Augmented Generation (RAG), and AI-assisted development over large codebases. However, the approach proposed in this article aims to go beyond source code analysis. It envisions a unified software knowledge platform that combines source code, relational database metadata, user interface descriptions, technical and functional documentation, operational logs, monitoring data, incident history, and deployment information into a continuously evolving knowledge repository. The objective is not only to assist developers while writing code, but to reconstruct the application's technical architecture, business processes, workflows, dependencies, and operational knowledge, creating a long-term AI companion for software maintenance, onboarding, architectural understanding, and safer system evolution.

Why the Future of Document Management Is Not Another ECM

For more than two decades, Enterprise Content Management (ECM) systems have been the foundation of corporate document management.

They have proven their value by providing secure storage, version control, workflows, permissions, audit trails, records management and compliance capabilities. Platforms such as SharePoint, Oracle WebCenter Content (WCC), OpenText, Alfresco and many others continue to manage millions of business-critical documents every day.

The problem is not that these systems have failed.

The problem is that the expectations of users have changed.

The New Challenge: Knowledge Discovery

Traditionally, document management was focused on storing and retrieving documents.

Users knew what they were looking for:

• Find a document.

• Locate the latest version.

• Check who approved it.

• Review its history.

Artificial Intelligence introduces a completely different expectation.

Users now want answers rather than documents.

They want to ask questions such as:

• Which systems are impacted by this change?

• What requirements are affected by this decision?

• Which documents contain conflicting information?

• What risks are associated with this component?

• What knowledge already exists about this topic?

Answering these questions requires much more than document storage and keyword search.

It requires understanding relationships, context, dependencies and knowledge hidden inside thousands of documents.

This is something that traditional ECM platforms were never designed to do.

Why Simply Adding AI Is Not Enough

Many current initiatives attempt to connect existing ECM repositories to chatbots or generic AI assistants.

While this approach can produce impressive demonstrations, it often struggles in real-world environments.

The reason is simple.

Documents are distributed across multiple repositories, each with its own structure, permissions, metadata models and lifecycle rules.

A typical organization may store information in:

• SharePoint

• Oracle WebCenter Content

• OpenText

• Alfresco

• File shares

• PLM systems

• Email archives

Each repository contains valuable knowledge, but none of them provides a complete picture.

Adding an AI assistant on top of a single repository does not solve the fragmentation problem.

The Reality: Nobody Wants to Replace Their ECM

This is where many proposed solutions become unrealistic.

Large organizations have invested years, sometimes decades, building their document management ecosystems.

They have:

• Millions of documents.

• Complex workflows.

• Regulatory requirements.

• Existing integrations.

• Thousands of users.

No organization wants to hear:

"Replace your entire ECM infrastructure."

The cost, risk and disruption would be enormous.

In practice, most organizations will continue using their existing ECM platforms for many years.

And that is perfectly reasonable.

A Different Approach

Instead of replacing existing ECM systems, a more realistic strategy is to preserve them as the official systems of record.

Their role remains essential:

• Document storage.

• Version control.

• Security.

• Compliance.

• Auditability.

• Records management.

What changes is what sits above them.

Rather than building yet another ECM, organizations should introduce a new layer capable of connecting all existing repositories and transforming the information they contain into usable knowledge.

This new layer becomes the bridge between traditional document management and modern AI capabilities.

Preserving Existing ECM Investments

One of the key advantages of this approach is that it does not require organizations to replace their existing ECM platforms.

Systems such as SharePoint, Oracle WebCenter Content, OpenText or other repositories can continue operating exactly as they do today. Documents remain in their current locations, managed by the same permissions, workflows and governance processes already in place.

The new platform simply connects to these repositories through their existing APIs and content services.

Rather than moving documents, the platform discovers and indexes knowledge from multiple sources while leaving the original content untouched.

This significantly reduces risk, cost and implementation effort.

Starting Small

Perhaps the most important aspect of this architecture is that it does not require a massive transformation project from day one.

A first version could start with a very simple user interface:

• A unified search screen.
• An AI-powered chat interface.
• Basic document discovery across repositories.
• Simple knowledge exploration capabilities.

Behind the scenes, the platform would connect to existing ECMs and gradually build a unified knowledge layer.

Additional capabilities such as impact analysis, knowledge graphs, intelligent agents and advanced workflows could then be introduced incrementally.

This allows organizations to begin generating value immediately while evolving towards a much more powerful Document Intelligence Platform over time.

Instead of replacing existing systems, the new platform enhances them, bringing AI-powered knowledge discovery to repositories that organizations already trust and depend on.

From Multiple Repositories to a Unified Knowledge Layer

The objective is not to migrate documents.

The objective is to unify access to knowledge.

In this model, existing repositories remain untouched:

• SharePoint continues managing SharePoint documents.

• Oracle WCC continues managing WCC content.

• Other repositories continue performing their current role.

Above them, a new intelligence layer is introduced.

This layer is responsible for:

• Discovering information across repositories.

• Extracting knowledge from documents.

• Understanding relationships between information.

• Building semantic indexes.

• Applying security and permission rules.

• Providing AI-powered search and analysis capabilities.

Users no longer need to know where information is stored.

They interact with a unified knowledge platform capable of accessing multiple repositories behind the scenes.

The Next Generation of Document Management

The future is unlikely to be another standalone ECM platform.

Instead, it is likely to be a new architecture where existing ECMs continue acting as trusted repositories while a new intelligence layer provides AI-driven discovery, analysis and knowledge management capabilities.

This approach protects previous investments, reduces migration risks and enables organizations to benefit from Artificial Intelligence without disrupting their existing document management landscape.

The challenge is no longer managing documents.

The challenge is understanding and exploiting the knowledge contained within them.

And that requires a new architectural foundation.

Proposed Technology Stack

At this stage, the objective is not to build every component from scratch. Instead, the platform should leverage proven technologies for each layer while focusing development efforts on the areas that create real business value.

For the user interface and application layer, a rapid development platform such as Jmix provides an excellent starting point. It enables the fast creation of enterprise-grade user interfaces, administration screens, workflows, dashboards and security models, allowing the project to deliver working functionality in a relatively short timeframe.

For the intelligence layer, modern open-source AI technologies provide the foundation for knowledge discovery and semantic search. Large Language Models (LLMs) can be deployed locally to ensure full control over data, while vector databases can be used to support semantic retrieval and knowledge exploration.

The platform can therefore be structured around several complementary layers:

• Application Layer: User interfaces, administration, workflows and dashboards.
• Knowledge Layer: Unified access to information coming from multiple repositories.
• AI Layer: Semantic search, document understanding, summarization and knowledge discovery.
• Security and Governance Layer: Permissions, auditability, classification and compliance.
• Repository Layer: Existing ECMs and other systems of record.

A possible implementation could combine:

• Jmix for rapid enterprise application development.
• Spring Boot for backend services and integration.
• Local LLMs for secure AI processing.
• Vector databases for semantic search and retrieval.
• Knowledge graph technologies for relationship discovery and impact analysis.
• Existing ECM platforms as trusted systems of record.

The key point is that none of these technologies replace the current repositories. Instead, they work together to create a new layer of intelligence capable of discovering, connecting and exploiting the knowledge already stored across the organization.

This approach allows the project to start with a simple and practical first release while providing a clear path towards a much more advanced Document Intelligence Platform in future iterations.

 

Recommended Technologies

AI Layer

The AI Layer should be built using proven open-source technologies rather than developed from scratch. The objective is to leverage mature components and focus development efforts on the capabilities that create real business value.

Capability	Recommended Technologies	Purpose
Large Language Models (LLMs)	Llama, Mistral, Mixtral, Qwen	Document understanding, summarization, question answering and reasoning
LLM Runtime / Inference Engine	vLLM, Ollama, Text Generation Inference (TGI)	Efficient execution of AI models, either for production or development environments
Vector Database	Qdrant, pgvector, Milvus	Semantic search, embeddings storage and Retrieval-Augmented Generation (RAG)
Knowledge Graph	Neo4j, ArangoDB	Relationship discovery, dependency mapping and impact analysis
Agent Framework	Dify, LangGraph	AI workflows, intelligent assistants and agent orchestration

For an initial release, a combination of Jmix, Spring Boot, Dify, vLLM and Qdrant could provide a fast path towards a working platform with AI-powered search, document chat and semantic retrieval capabilities.

As the platform evolves, more advanced technologies such as LangGraph and Neo4j can be introduced to support sophisticated agent workflows, relationship analysis and knowledge discovery scenarios.

The key point is that these technologies are not the product itself. They are building blocks. The real value lies in the intelligence layer built on top of them, including knowledge federation, document classification, metadata extraction, relationship discovery, impact analysis and security-aware access to information across multiple repositories.

Knowledge Layer

The Knowledge Layer is the core of the platform. Its role is to connect existing repositories, normalize their information, apply security rules and transform distributed documents into usable knowledge.

Capability	Recommended Technologies	Purpose
Repository Connectors	REST APIs, CMIS, Microsoft Graph API, Oracle WCC APIs	Connect to SharePoint, WCC, ECMs and other repositories without replacing them
Integration and Synchronization	Spring Boot, Apache Camel, Kafka, RabbitMQ	Move metadata, events and document updates between repositories and the intelligence platform
Metadata Federation	PostgreSQL, Oracle, Elasticsearch / OpenSearch	Normalize metadata from different systems into a common searchable model
Security Federation	LDAP, Active Directory, Keycloak, OAuth2 / OpenID Connect	Preserve permissions, roles and identity rules across repositories
Knowledge Processing	Apache Tika, OCR engines, custom extraction services	Extract text, structure and relevant information from documents
Search Indexing	OpenSearch, Elasticsearch	Support fast keyword search, filtering and faceted navigation

This layer is especially important because it prevents the platform from becoming just another isolated repository. Instead, it acts as a bridge between existing ECMs and the new AI capabilities.

The key idea is that documents can remain in their current systems of record, while the Knowledge Layer creates a unified view of their metadata, content, permissions and relationships.

In other words, the Knowledge Layer is what allows the platform to connect SharePoint, WCC, other ECMs, PLM systems, databases and file shares under a common intelligence model.

Presentation Layer

The Presentation Layer is responsible for providing simple, powerful and user-friendly access to the platform. It should allow users to search, explore, analyse and interact with knowledge without needing to know where documents are physically stored.

Capability Recommended Technologies Purpose Enterprise UI Development Jmix, Vaadin Rapid development of enterprise screens, administration panels, dashboards and workflows Advanced Web Interfaces React, Angular, Vue Build richer user experiences such as AI search, document exploration and visual analysis AI Chat Interface Dify UI, custom React UI, Vaadin components Provide conversational access to documents and knowledge Dashboards and Analytics Jmix dashboards, Apache Superset, Grafana Display document metrics, usage, quality indicators and knowledge insights Graph Visualization Neo4j Bloom, Cytoscape.js, React Flow, D3.js Visualize relationships between documents, systems, requirements and risks Document Viewer PDF.js, OnlyOffice, Collabora Preview documents, compare versions and display extracted knowledge next to the original content

For the first version, Jmix remains a very appropriate option because it allows the team to build useful enterprise interfaces quickly, including search screens, metadata views, administration panels and basic workflows.

Later, more advanced interfaces can be introduced using React or specialized visualization libraries for AI chat, relationship graphs, impact analysis and document intelligence dashboards.

The main goal of this layer is to make the platform feel simple for the user, even if the underlying architecture connects many repositories, AI services and knowledge sources behind the scenes.

Example of a Unified Search and Knowledge Discovery Experience

The Unified Search and Knowledge Discovery screen is the primary entry point to the platform. It combines traditional document search with AI-powered knowledge discovery, allowing users to search across multiple repositories through a single interface.

Users can perform natural language queries, apply advanced filters and explore documents stored in different systems such as SharePoint, WCC, engineering repositories and other ECM platforms.

Search results are enriched with AI-generated summaries, metadata, relationships and impact information, helping users understand not only which documents exist, but also how they are connected to other systems, requirements, reports and business processes.

The interface is organized into three main areas:

• Advanced Filters Panel: Allows users to refine searches by repository, document type, classification, status, program, owner, date range and tags.
• Results Panel: Displays matching documents together with summaries, metadata and related knowledge.
• Knowledge Panel: Provides additional context, including relationships, dependencies, impact analysis and AI-generated insights.

This approach transforms document retrieval into knowledge discovery, enabling users to find information faster, understand its context and assess its potential impact across the organization.