Architectural engineering for AI in legacy software
A software company was evaluating how to add a more intelligent capability to an existing product.
One proposed architecture used a relatively heavy AI approach.
Talbot West broke the requirement down into the actual behavior the system needed to produce, compared the mechanisms capable of producing it, and identified a simpler architecture that could satisfy the requirement with less complexity, lower computational burden, and more predictable control.
What the system actually needed to do
The system needed to evaluate context, distinguish among a bounded set of possible actions, and select an appropriate response consistently enough for production use.
That requirement did not automatically justify the heavier architecture.
The architecture decision depended on whether the additional machinery produced a material advantage in accuracy, flexibility, economics, or operating performance.
Comparing the approaches
Introduced
- More runtime cost
- More dependencies
- Greater operational variability
- A larger engineering surface area
Those costs did not clearly create a corresponding improvement in the required behavior.
Preserved
- Less complexity
- Lower computational burden
- More predictable control
The simpler approach reduced the amount of machinery involved while preserving the capability the product needed.
What changed
The company avoided complexity that did not earn its cost.
The architecture was evaluated against the behavior the product required and the operating burden of producing it, not by how advanced the technology appeared.
The heavier approach added runtime cost, dependencies, engineering surface area, and operational variability without enough additional capability to justify them. The simpler architecture preserved the required behavior without paying for machinery that did not create commensurate value.