Specialist functionality
Ledgers, loan systems and other established products maintain consequential records and apply defined rules. Their value includes the integrity of those records, the behavior of their calculations and the work required to maintain the product as requirements change.
Recreating that functionality makes the firm responsible for it. The ability to generate software more quickly does not make every replacement economically sensible. Existing products and supported configuration should be assessed against the actual requirement before custom work is commissioned.
The operation across systems
The products may perform their own roles well while employees still interpret documents, reconcile identities, investigate discrepancies and move work between them. A notice can change what needs to happen in several systems without any one product knowing the whole process.
The operating layer maintains that continuity. It gives the work a shared identity and history, connects the relevant information and tools, and records what has completed and what remains unresolved. AI can interpret variable material and investigate a discrepancy while tested software performs the defined calculations and actions.
Records and execution
The architecture must identify which record is authoritative and how a change reaches it. A proposed update, an approved instruction and a confirmed posting are different states. Sending an instruction does not establish that the destination accepted it.
Partial failures, retries and conflicting records are therefore part of the operating design. Without them, staff become the recovery mechanism between otherwise successful applications. That hidden work belongs in the cost of the system.
The custom-development decision
Custom work is justified where the requirement is specific to the business or spans products that do not support the complete process. It should be limited where a maintained product already performs the necessary function well.
AI also changes the cost of building and modifying software, making some previously uneconomic scopes worth reassessing. That is a reason to compare the real delivery and operating costs again, not to assume bespoke software has become free to maintain.
Model independence
Business records, permissions and external interfaces should not depend on a particular model's behavior. The model and its execution method need to be replaceable within that architecture, with the changed process evaluated before it is relied on.
Halyard's position is to retain sound specialist functionality and develop the operation the business needs around it. This gives the firm control over its service without making it the developer of every underlying platform.