Q: What is driving the adoption of service-oriented architecture (SOA) by banks?
Alan Goldstein, Bank of New York: The way we measure the business value of an application is changing as IT gets more aligned with and accountable to business drivers. As a result, the tolerance once exhibited by business sponsors in accepting solutions that cannot be broadly leveraged is waning. This has created a greater impetus within the technology world to attempt to answer some of the challenges that inhibit broad reuse. The current industry iteration of SOA is perhaps the first genuine attempt to solve some of the perennial challenges (legacy reuse, interoperability, better ROI) in a united way. SOA is one of the first steps in addressing the necessity to modernize business capability using technology as opposed to making the capability fit within the constraints of technology.
Manuel Barbero, BearingPoint: SOA enables faster, cheaper application integration. It exists thanks to the adoption of Web-related technologies and constructs that make applications talk to one another in a standardized manner. Moreover, SOA makes the creation of enterprisewide, reusable services possible, and accelerates the creation of new applications as well as their integration with the plethora of disparate applications performing overlapping functions and storing redundant data.
Jim Gahagan, webMethods: The main driver for SOA adoption is the desire by banks to overcome the limitations of their legacy systems as well as their need to eliminate the operational silos separating various business units. By employing an SOA, banks are realizing greater reuse of existing IT assets while also reducing the cost to develop and implement new systems. SOA also allows banks to readily create and implement dynamic business processes that span disparate business units and more closely mirror actual customer requirements.
Q: What challenges and risks do banks face when pursuing SOA?
Goldstein, Bank of New York: Some of the initial challenges are getting familiar with the concept of a service, understanding the boundary conditions around what constitutes a service, implementing the processes to manage this orientation and associated service levels, and working through the underlying technology issues. Many of the obstacles are not technology related. Providing a suite of network-available services that comprehensively represent our business capabilities requires a holistic view of business services and how they translate to technical services. This requires a level of technical and business architectural maturity that is often difficult to achieve.
Our strategy to manage the risk around SOA is to try to understand the fundamental strengths and the value-add of this model as it relates to our business services. Clearly, not all business capabilities in their current forms can be objectively justified for SOA enablement. We go through a due-diligence process of assessing the current capabilities, identifying the needs and benefits to see what services fit into this model, augment the services if necessary and then finally orchestrate them using an SOA paradigm.
This also requires a mind-set change among the providers of the technology services. Once you start delivering capabilities broadly across many business lines, you encounter issues in which there is no obvious ownership. Long-term strategic planning requires business and technology unit managers to think as service owners, and offer a comprehensive service-level agreement for their services including enhancements, support and planning. Critical success factors include establishing a strong operational service infrastructure (service bus), and establishing a culture of ownership, service engineering, responsiveness and collaboration among the service owners.
Gahagan, webMethods: Many banks maintain a number of disparate and redundant systems. Culturally, banks often are unable or unwilling to share data, objectives or processes across siloed organizations. As banks move forward with SOA, they risk creating multiple "islands of SOA," effectively creating new silos within the IT infrastructure that require another layer of complex middleware to overcome. To minimize these risks, banks should employ a pragmatic, targeted SOA strategy and road map, with clear benchmarks for return-on-investment as the strategy unfolds.
Jamie Bernardin, DataSynapse: The primary risk to any application that is constructed by assembling these discrete services is that those services won't be available when the application must execute them. Web services tell us how to manage the interaction between client request and service response. However, if the services aren't there or don't respond in an appropriate amount of time, the application is at risk. Given this, organizations that are exposing services must take care to ensure that their services are always available and able to scale with demand.
Q: In what processes/applications have banks had the most success in deploying grid computing?
Goldstein, Bank of New York: Banks have had the greatest success in deploying grids in capital markets, fixed-income and currency derivatives applications. These high-performance computing applications use mathematically intensive calculations that require massive processor compute resources. Grid is the right solution for these because it's much cheaper to scale capacity horizontally using many low-cost small servers than to scale vertically using a single high-cost large server.
Bernardin, DataSynapse: The initial successes of grid computing were in the area of computationally intense applications. For instance, Monte Carlo simulations are easily parallelized and distributed to every compute node participating in the grid. The advantage should be clearinstead of executing these simulations on one server and grinding away for, in some instances, days, they now can be broken apart and distributed across hundreds or even thousands of compute nodes, resulting in dramatic reductions in the amount of time taken to complete. The result is that organizations using this technology are gaining a competitive edge. In the area of SOAs, the grid is the ideal platform on which to execute services because of its ability to virtualize the actual execution of the service away from the physical host on which the service is to be executed.
Q: How will SOA and/or grid change banks' computing environments, and what impacts will they have on IT organizations and end users?
Barbero, BearingPoint: Imagine being a credit risk analyst not having to log into six applications to get a single view of your client exposure. You run a risk model on your entire portfolio and get results within seconds, not minutes. As an end user, you just leveraged SOA, and grid computing helped you quickly marshal enormous computing resources. The IT group developed the application at a fraction of the cost and time it would otherwise needthat's what SOA and grid make possible.
Bernardin, DataSynapse: SOA and grid computing are natural partners. SOAs give organizations the ability to respond rapidly to evolving business requirements by leveraging existing value-add processes as discrete services; grid computing provides the virtual service infrastructure that will guarantee the availability of these services regardless of the demand placed upon them.
The impact that grid computing has on the IT organization cannot be overstated. Services executing on the grid are not tied to any particular host, so removing any one node (for hardware upgrades, for instance) has no impact on service execution. Adding new hardware to the grid is just as easy because it is the responsibility of the grid itself to ensure that nodes are appropriately provisioned with all of the services that are being managed on the grid. As for the end users, they benefit from increased response times and a wider array of available application services. --Peggy Bresnick Kendler