One lesson I’ve learned in enterprise development: understand the problem behind a requested solution before committing to a direction.
At Aegis Aerospace, I was asked to lead a data-centralization effort because users struggled to find files. Years of organizational and process changes had contributed to data sprawl, and a large migration was proposed.
Centralization could change where files lived. But would it solve how people found them—or prevent the same problem from recurring?
I proposed another way to navigate: let users find documents by what they are, without needing to know where they are stored.
The approach used a three-level taxonomy:
- Functional Domain - Topic - Document Type
Users could drill down through those classifications, add a keyword, and search. Behind the interface, Azure Functions processed files across enterprise systems and applied classification metadata.
The architecture combined Azure Table Storage, Service Bus queues, Azure Functions, certificate-based application authentication, and a SharePoint/SPFx front end.
An important design decision came during an initial AI-assisted classification run. Cost was a concern, but so were unsupported interpretations. For example, “MBR”—Management Business Review in our organization—was interpreted as “Measurement Bias Review.”
I shifted classification to a deterministic engine combining keywords, metadata, content analysis, configurable conditions, and disambiguation rules. This gave us more explicit control over how organizational terminology was interpreted.
The solution was in pilot user testing when I left Aegis.
My takeaway: before reorganizing information, consider whether the underlying problem is storage, discovery, or both. A different way to find information may address a need that moving it alone cannot.