Most advisory firms can tell you what technology they use. They know their CRM, portfolio management system, reporting platform, billing software, financial planning tools, and increasingly, the AI applications they are testing or considering.
What fewer firms can explain is how all of those systems function together as one operating environment. That distinction matters because firms do not experience technology one application at a time. Work moves across systems, data moves between them, and people operate in the gaps.
Over the years, I have watched technology stacks grow one reasonable decision at a time. A firm identifies a problem, selects a platform to solve it, implements the solution, and moves on.
Then another requirement emerges and another system is added. There is nothing inherently wrong with this process, but eventually those individual decisions become something much larger than a collection of applications. They become the operating infrastructure of the firm.
That leads to a question I believe more RIA leaders should be asking: When was the last time you audited the entire stack as one system?
Most firms have evaluated their vendors. Many have reviewed individual applications. Far fewer have examined whether the environment those applications collectively created is still aligned with how the firm needs to operate and grow.
We Have Been Auditing the Parts
Technology evaluation in wealth management has traditionally happened at the application level. Firms compare CRMs, portfolio management platforms, reporting systems, planning software, billing solutions, and now AI tools.
The underlying assumption is understandable: select strong technology for each function and the firm should end up with a strong technology environment. But I think that assumption becomes less reliable as the number of systems, integrations, workflows, and dependencies inside the firm increases.
A firm can have an excellent CRM and an excellent portfolio management system and still require employees to manually move information between them. It can have sophisticated reporting technology while maintaining separate processes to reconcile the data behind those reports. It can automate individual tasks while leaving the broader workflow fragmented. In each case, the individual applications may be doing exactly what they were designed to do.
The friction exists because the firm has evaluated the components more carefully than the relationships between them.
This is why I believe the unit of analysis needs to change. Best-in-class components do not automatically produce a best-in-class operating system.
As firms become more technology-dependent, the quality of the connections between systems matters almost as much as the capabilities inside them. The question is no longer simply whether each platform works. It is whether the stack works.
The Real Friction Lives Between Systems
When firms experience technology-related friction, the instinct is often to identify which application is causing the problem.
Sometimes that is the correct diagnosis. But many of the operational problems I see are less visible because they exist at the boundaries: where information leaves one system and enters another, where an automated process becomes manual, where someone has to verify that data moved correctly, or where an advisor has to reconstruct context across several applications before completing a relatively simple task.
These problems rarely look serious in isolation. A manual handoff may take only a few minutes. A spreadsheet may provide a convenient bridge between two platforms. An operations employee may know exactly which fields need to be updated in multiple systems. A team may have developed workarounds so familiar that nobody considers them workarounds anymore.
But as the firm grows, these small accommodations multiply across accounts, teams, workflows, and client relationships. What began as a workaround eventually becomes part of the operating architecture.
That is when firms begin compensating for structural friction with human capacity. People reconcile data, manage exceptions, check integrations, move information between platforms, and remember the unofficial steps required to make official processes work.
The technology stack may still appear functional because the work gets completed. But the better measure is whether the stack removes complexity as the firm grows or simply transfers that complexity to the people operating it.
Audit the Whole, Not the Parts
I think RIAs need to approach technology audits differently. Instead of beginning with another feature comparison, vendor review, or department-by-department assessment, leadership should look at the entire technology environment as one operating system.
Audit the whole, not the parts. The objective is not to determine whether every application is good or bad. It is to understand what happens when those applications have to work together to deliver an actual business process.
There are several useful lenses for doing that without turning the exercise into another vendor scorecard. Follow workflows from beginning to end and identify where work stops or requires manual intervention. Trace data from its source through the systems that consume it and determine where duplication or conflicting versions emerge.
Examine ownership at the boundaries between platforms, particularly where responsibilities become unclear. And distinguish technical connectivity from operational integration, because two systems exchanging data does not necessarily mean they are supporting one coherent process.
The answer will not be the same for every firm. Some firms may need greater consolidation.
Others may benefit from maintaining specialized platforms but improving integration around them. In some cases, the technology itself may be adequate, and the real issue may be how workflows were designed around it.
The point of the audit is not to arrive at a predetermined architecture. It is to determine whether the architecture is intentional and whether it still supports the firm the organization is becoming.
AI Will Make Weak Architecture More Visible
AI makes this issue more important because it raises the expectations placed on the underlying technology environment.
The industry is understandably focused on intelligent assistants, meeting automation, workflow automation, personalization, data analysis, and other emerging capabilities. But most of these conversations begin with what AI can do rather than whether the operating environment underneath it is prepared to support what firms want AI to do.
AI does not eliminate fragmented data, inconsistent workflows, unclear ownership, or weak integration.
In many cases, those conditions determine how useful AI can become. If the information required for a process is scattered across several systems, intelligence has to work around that fragmentation. If the workflow itself is inconsistent, automating portions of it does not make the overall process coherent. And if responsibilities are unclear, making a process faster does not resolve who should control the outcome.
This is why I do not think the firms that adopt the most AI will necessarily gain the greatest advantage from it. The stronger position may belong to firms whose operating environments are structured well enough to apply intelligence across connected processes rather than isolated tasks.
AI can amplify good architecture, but it can also amplify the consequences of poor architecture. Before asking how much AI a firm can adopt, leadership should first ask how much intelligence its existing operating system can support.
The Next Technology Decision May Not Be About Technology
For much of the industry’s technology evolution, the strategy has been additive. A new requirement emerges, a capability gap is identified, and another platform or application enters the stack.
That approach was logical when firms were solving clear technology deficiencies. But mature firms now operate environments with years of accumulated systems, integrations, processes, exceptions, and institutional knowledge. At that stage, continually asking what should be added next can distract from the more consequential question: What have we already built?
A serious look at the whole stack may produce very different answers across firms. One organization may discover unnecessary duplication, another may find that integration is the primary constraint, and another may realize that its technology is fundamentally sound, but its workflows were never redesigned as the business evolved. For some firms, the next step may involve consolidation.
For others, better integration or process redesign may create more value than another technology purchase. What matters is not pursuing a particular architecture. It is making sure the architecture reflects a deliberate operating model rather than years of accumulated decisions.
I believe this becomes a leadership issue as RIAs grow more complex and increasingly dependent on automation and AI. The technology stack already influences how work moves, how information is governed, where people spend their time, and how much additional complexity the organization can absorb.
Whether leadership deliberately designed that system or inherited it through years of incremental decisions does not change its influence. Before evaluating the next platform or AI capability, I would examine the system already running the firm. Audit the whole, not the parts.
The next technology advantage may begin not with adding something new, but with finally understanding what you already have.
