Considerations For Implementing Systems in Financial Service Organizations

INTRODUCTIONdesired.
The confluence of SOA and SOX has hadThis second point is critical. Management at financial
unexpected consequences, making softwarefirms typically realizes that ISVs require comprehensive
development more efficient and system failures rarer.development specifications. Equipped with them, ISVs
There are a number of reasons why new systemsare able more rapidly to build-and modify-applications
fail. But thanks to developments in service-orientedto better meet the needs of firms and their clients. This
architecture (SOA)-which reduces interdependenciesminimizes the traditional back-and-forth and decreases
between applications-and the implementation of thethe amount of time required for financial firms to
Sarbanes-Oxley Act (SOX), which has led to morerealize a return-on-investment (ROI) on their new
firms outsourcing development to independentapplications. These successes build upon each other.
software vendors, the likelihood of all-out failure hasThe bank that successfully rolls out an ISV-created
been reduced.application is encouraged to develop more applications.
There are two types of major systems in financialFrom a systems' development perspective, the
services firms, with vastly different success rates andcumulative effects of SOA and SOX have been
implementation challenges. The first type-client-facinglargely positive. Many financial firms that had historically
systems-are outwardly focused. They connectcreated their own systems often failed for one simple
bankers, financial planners, hedge fund managers,reason. The best programmers and developers tend
stockbrokers, and their ilk with customers. Examplesto work for software companies, not financial firms.
include banking and bill payment, 401(k) management,Financial firms that contract ISVs to create specific,
remote deposits, derivatives trading, and positionclient-facing applications typically realize a number of
monitoring. While these systems have many differentsignificant benefits.
objectives, they have two overridingLESS RISK WITH ISVs
commonalities-they link customers and investors withWeinrib Partners, a fictitious hedge fund, wants to
their financial institutions and generate revenue in thecreate an application allowing its investors to wire
process.money from banks directly to the fund. Weinrib's
Not all systems in a financial firm are client-facing.managers decide to outsource development to an ISV.
Organizations' back-office systems are inwardlyThe application has one very specific purpose and the
focused on internal employees and daily operations.managers can very clearly articulate the application's
Customers never use or even see these applications.requirements to an ISV which, in turn, expedites
Examples include supply chain management,development. Testing should manifest any and all
accounting, human resources, and payroll. Back-officeissues because of the application's singular purpose.
applications-typically called enterprise resource planningWeinrib launches its application to clients who no longer
(ERP) systems-record sales and purchasehave to write and mail checks to deposit funds. It is
transactions, update inventory, and cut employee andimportant to note that Weinrib owns the application
vendor paychecks. Invoices, receipts, and reports cancreated by the ISV. As a result, Weinrib can control
also be produced by back-office systems. Unlike theirthe application's customizations and enhancements. If
client-facing brethren, back-office systems generateWeinrib's customers request that the application
no revenue; they support cost centers.integrates with QuickBooks and Microsoft Money, for
The different scopes and audiences of theseexample, then Weinrib can approach its ISV
applications result in different rates of success.immediately about making this change.
Client-facing systems fail much less often thanContrast the system ownership model with traditional
back-office applications. By and large, the challengesERP purchase and support model. Organizations that
faced by financial firms with respect to enterpriseutilize SAP or Oracle as an enterprise system have no
systems are not materially different than those facedcontrol over its delivered functionality. End-users can
by retail, health care, or government organizations.always submit vendor "enhancement requests," but
Back-office systems support the entire enterprise, notthere is no guarantee that they will be adopted in
simply one function. ERPs have to handle a number offuture releases of the application. What's more, IT
disparate tasks, the vast majority of which tie back todepartments that customize ERPs face a number of
the general ledger (GL). ERP systems are tightlysignificant obstacles. For one, customizations typically
coupled with one another. A problem in one area willinvalidate vendor support agreements. Second, making
almost always affect another.a tweak to a general ledger program, for example,
On the other hand, client-facing applications can bemay break something else. Enterprise systems are
considered "best of breed" and often do not need tovery involved and contain many interdependencies.
integrate with other applications. They typically areFinally, even a successfully implemented customization
designed to accomplish one or a limited number ofmay go by the wayside after an upgrade or service
specific objectives: transferring funds, buying and sellingpatch.
stocks, and the like. Handling stock trades or dividends,In April of 2008, PNC completed its acquisition of
for example, is much less exhaustive than managingSterling Financial Corp. While there were many
an entire supply chain or paying employees in 48reasons for the merger, one of the more overlooked
states and seven countries. As a result of this limitedones involved technology. Specifically, Sterling's internal
integration, their development cycles are much shortersystems had become antiquated. Its senior
and their failure rates much lower.management realized that the necessary investment
SOA AND SOXto upgrade them would be cost-prohibitive.
Two recent and seemingly unrelated events haveSterling is not alone in this regard. Many financial
coalesced, resulting in more efficient softwareinstitutions have realized that the old maxim applies: "If
development and fewer system failures. The first isyou can't beat 'em, join 'em." Organizations with
the advent of SOA, which provides methods forantiquated client-facing systems cannot re-tool by
systems development and integration in whichsimply making a few, relatively inexpensive
systems group functionality around businessenhancements. More often than not, a complete
processes and package these as interoperableoverhaul is necessary. At a minimum, most financial
services. SOA also describes IT infrastructure thatsystems today must comply with SOX requirements,
allows different applications to exchange data withintegrate with external banks, offer customers a
one another as they participate in business processes.powerful and user-friendly experience, and ward off
Service-orientation aims at a loose coupling of servicesincreasing security threats. Beyond these requirements,
with operating systems, programming languages, andapplications often need to do more. Rather than
other technologies which underlie applications.merely transfer funds, many applications offer data
On the regulatory front, due to SOX requirements,mining and business intelligence (BI) capability and allow
many financial firms no longer attempt to create theiragents, bankers, and other personnel the ability to
own internal systems. SOX's increased auditcustomize offerings based on the individual customer's
requirements have resulted in many financial servicesfinancial situation. Added to this, organizations' IT
firms using independent software vendors (ISVs) tobudgets are under a microscope.
build proprietary systems. Firms such as InfosysCONCLUSION
specialize in making or selling software, designed forWhile there is no secret sauce to building and
mass marketing or for niche markets.implementing client-facing systems, financial firms tend
Due to the arrival of both SOA and SOX, manyto minimize failure rates by utilizing ISVs and
financial firms have abandoned internal applicationextensively documenting business requirements.
development and now deal almost exclusively withSeasoned ISVs allow firms to quickly create and roll
ISVs, who observe the following cardinal rules without custom applications that can increase firm revenue,
regard to software development: Issues found later inprofitability, and ROI. With respect to enterprise and
an application's development cycle are exponentiallyback office systems, however, financial firms should
more time-consuming and expensive to fix than issuesnot try to build from scratch. They realize no
found at the beginning of the cycle. Unlike off-the-shelfcompetitive advantage from payroll vendors or
applications, software developers can essentially buildemployees. In this sense, financial firms tend to have
anything. Software engineers and coders do best withmany of the same issues as the rest of the corporate
pristine development specifications, allowing them toworld.
accurately build the applications and functionality