The confluence of SOA and SOX has had unexpected consequences, making software development more efficient and system failures rarer.
There are a number of reasons why new systems fail. But thanks to developments in service-oriented architecture (SOA)-which reduces interdependencies between applications-and the implementation of the Sarbanes-Oxley Act (SOX), which has led to more firms outsourcing development to independent software vendors, the likelihood of all-out failure has been reduced.
There are two types of major systems in financial services firms, with vastly different success rates and implementation challenges. The first type-client-facing systems-are outwardly focused. They connect bankers, financial planners, hedge fund managers, stockbrokers, and their ilk with customers. Examples include banking and bill payment, 401(k) management, remote deposits, derivatives trading, and position monitoring. While these systems have many different objectives, they have two overriding commonalities-they link customers and investors with their financial institutions and generate revenue in the process.
Not all systems in a financial firm are client-facing. Organizations’ back-office systems are inwardly focused on internal employees and daily operations. Customers never use or even see these applications. Examples include supply chain management, accounting, human resources, and payroll. Back-office applications-typically called enterprise resource planning (ERP) systems-record sales and purchase transactions, update inventory, and cut employee and vendor paychecks. Invoices, receipts, and reports can also be produced by back-office systems. Unlike their client-facing brethren, back-office systems generate no revenue; they support cost centers.
The different scopes and audiences of these applications result in different rates of success. Client-facing systems fail much less often than back-office applications. By and large, the challenges faced by financial firms with respect to enterprise systems are not materially different than those faced by retail, health care, or government organizations.
Back-office systems support the entire enterprise, not simply one function. ERPs have to handle a number of disparate tasks, the vast majority of which tie back to the general ledger (GL). ERP systems are tightly coupled with one another. A problem in one area will almost always affect another.
On the other hand, client-facing applications can be considered “best of breed” and often do not need to integrate with other applications. They typically are designed to accomplish one or a limited number of specific objectives: transferring funds, buying and selling stocks, and the like. Handling stock trades or dividends, for example, is much less exhaustive than managing an entire supply chain or paying employees in 48 states and seven countries. As a result of this limited integration, their development cycles are much shorter and their failure rates much lower.
SOA AND SOX
Two recent and seemingly unrelated events have coalesced, resulting in more efficient software development and fewer system failures. The first is the advent of SOA, which provides methods for systems development and integration in which systems group functionality around business processes and package these as interoperable services. SOA also describes IT infrastructure that allows different applications to exchange data with one another as they participate in business processes. Service-orientation aims at a loose coupling of services with operating systems, programming languages, and other technologies which underlie applications.
On the regulatory front, due to SOX requirements, many financial firms no longer attempt to create their own internal systems. SOX’s increased audit requirements have resulted in many financial services firms using independent software vendors (ISVs) to build proprietary systems. Firms such as Infosys specialize in making or selling software, designed for mass marketing or for niche markets.
Due to the arrival of both SOA and SOX, many financial firms have abandoned internal application development and now deal almost exclusively with ISVs, who observe the following cardinal rules with regard to software development: Issues found later in an application’s development cycle are exponentially more time-consuming and expensive to fix than issues found at the beginning of the cycle. Unlike off-the-shelf applications, software developers can essentially build anything. Software engineers and coders do best with pristine development specifications, allowing them to accurately build the applications and functionality desired.
This second point is critical. Management at financial firms typically realizes that ISVs require comprehensive development specifications. Equipped with them, ISVs are able more rapidly to build-and modify-applications to better meet the needs of firms and their clients. This minimizes the traditional back-and-forth and decreases the amount of time required for financial firms to realize a return-on-investment (ROI) on their new applications. These successes build upon each other. The bank that successfully rolls out an ISV-created application is encouraged to develop more applications.
From a systems’ development perspective, the cumulative effects of SOA and SOX have been largely positive. Many financial firms that had historically created their own systems often failed for one simple reason. The best programmers and developers tend to work for software companies, not financial firms.
Financial firms that contract ISVs to create specific, client-facing applications typically realize a number of significant benefits.
LESS RISK WITH ISVs
Weinrib Partners, a fictitious hedge fund, wants to create an application allowing its investors to wire money from banks directly to the fund. Weinrib’s managers decide to outsource development to an ISV. The application has one very specific purpose and the managers can very clearly articulate the application’s requirements to an ISV which, in turn, expedites development. Testing should manifest any and all issues because of the application’s singular purpose.
Weinrib launches its application to clients who no longer have to write and mail checks to deposit funds. It is important to note that Weinrib owns the application created by the ISV. As a result, Weinrib can control the application’s customizations and enhancements. If Weinrib’s customers request that the application integrates with QuickBooks and Microsoft Money, for example, then Weinrib can approach its ISV immediately about making this change.
Contrast the system ownership model with traditional ERP purchase and support model. Organizations that utilize SAP or Oracle as an enterprise system have no control over its delivered functionality. End-users can always submit vendor “enhancement requests,” but there is no guarantee that they will be adopted in future releases of the application. What’s more, IT departments that customize ERPs face a number of significant obstacles. For one, customizations typically invalidate vendor support agreements. Second, making a tweak to a general ledger program, for example, may break something else. Enterprise systems are very involved and contain many interdependencies. Finally, even a successfully implemented customization may go by the wayside after an upgrade or service patch.
In April of 2008, PNC completed its acquisition of Sterling Financial Corp. While there were many reasons for the merger, one of the more overlooked ones involved technology. Specifically, Sterling’s internal systems had become antiquated. Its senior management realized that the necessary investment to upgrade them would be cost-prohibitive.
Sterling is not alone in this regard. Many financial institutions have realized that the old maxim applies: “If you can’t beat ’em, join ’em.” Organizations with antiquated client-facing systems cannot re-tool by simply making a few, relatively inexpensive enhancements. More often than not, a complete overhaul is necessary. At a minimum, most financial systems today must comply with SOX requirements, integrate with external banks, offer customers a powerful and user-friendly experience, and ward off increasing security threats. Beyond these requirements, applications often need to do more. Rather than merely transfer funds, many applications offer data mining and business intelligence (BI) capability and allow agents, bankers, and other personnel the ability to customize offerings based on the individual customer’s financial situation. Added to this, organizations’ IT budgets are under a microscope.
While there is no secret sauce to building and implementing client-facing systems, financial firms tend to minimize failure rates by utilizing ISVs and extensively documenting business requirements. Seasoned ISVs allow firms to quickly create and roll out custom applications that can increase firm revenue, profitability, and ROI. With respect to enterprise and back office systems, however, financial firms should not try to build from scratch. They realize no competitive advantage from payroll vendors or employees. In this sense, financial firms tend to have many of the same issues as the rest of the corporate world.
With more than a decade of experience, Phil Simon assists organizations in all phases of systems consulting including vendor selection, project management, business needs analysis, gap analysis, system testing and design, end-user training, interface and custom report development, and documentation. The result: providing his clients with superior systems, increased ROI, and a healthier bottom line.