Across multiple industries, service oriented architecture is becoming more than just a catchphrase. Joy Macknight looks at how financial services institutions are mapping the benefits of SOA onto their needs
For financial institutions, the race is on for greater efficiency from the IT budget and an increased need for flexibility and agility. It is a business driven agenda demanding change, but constrained by the technology underpinning the institutions: monolithic legacy and core systems.
“What you have is almost like a rock strata going back eons where you have different technologies, different designs, different architectures all working together but in a very fragile way. As soon as you try to make changes, it suddenly becomes extremely expensive,” says David Sprott, chief executive and principal analyst, CBDi Forum, an independent analyst firm and think-tank. “Many financial institutions have been trying to address this problem, and many understand the problem when you call it applications or systems silos. Over the last four or five years a lot of energy has gone into what might be referred to as enterprise application integration that has been quite unsuccessful in the sense that what it has been doing is creating dependencies which create more complexity across the silos.”
These systems - the basic processes that are needed in order to get up in the morning - tend to eat up the budget, but don’t necessarily create differentiation for the financial services institutions. Service oriented architecture is a paradigm exposing these processes, how they are built and integrated so they are made available to any other process in a very rapid, easy to re-use combination. It can create something that is flexible enough to solve today’s problems, while providing the infrastructure to evolve and tackle future IT problems.
SOA is a planned and systematic approach of being able to deliver service oriented IT that focuses on the delivery to the customer. Institutions then couple that with a disciplined approach in terms of business process where business users are driving IT and where the business needs to be able to adapt and flexibly change overnight or within minutes in relation to compliance regulation. “If you think about all the changes a bank needs to make quickly to either compete in the market or bring new products to market in order to be proactive in the way they serve their customers, their needs are for IT to be more responsive,” says Sarah Haskell, group marketing manager at Portrait Software, a UK firm focused on customer interaction software. “If they build the processes in service oriented architecture, it allows them to develop responses more quickly,”
Portrait Software’s client Cheshire Building Society began an SOA project to solve a particular problem — to create a unified experience for customers across the business. Paul D’Ambra, director of IT systems at CBS, says: “The pain area was that many of our processes weren’t end-to-end. We had multiple processes for the same things, different channels do the same thing differently - for example our call centres would handle things differently than our branches. Our IT was supporting eight different systems, which is costly. So we were looking to insulate our business from changes so that the customer experience was the same; we wanted to reduce our costs and make our system more agile to respond to customer demand.”
“The biggest challenge we faced was getting the business to have a business view. Most of the business thinks in terms of silos instead of end-to-end processes. The change was easiest where an individual department was in charge of process because their view was end-to-end; it is much harder when the process goes across a number of departments. It was a big cultural change within the building society trying to get them to think of the big picture and target the operational model,” says D’Ambra.
Zuger Kantonalbank looked at SOA from a different perspective: to break up the value chain. The Swiss bank did not want to be manufacturer, distributor and seller of its products - it wanted to be able to work with other parties to be able to use their services and plug them into their overall solution so their employees and clients see no difference in service. ZKB took securities from a merchant bank also in Zurich, they plugged that application into their architecture, so that the user thinks they are using a ZKB service, but actually it is a different bank in a different place that has the skills - and they do it with cost savings.
ZKB teamed up with Computer Sciences Corporation to develop a banking platform that would address their needs. Beat Mathys, board member for logistics at ZKB, says: “The Swiss Banking Platform, due to its flexible SOA architecture, allows us to work with suitable external partners. Because the fundamental architecture is in place, we can complete a project within eight months. This has allowed us to enter into a business process outsourcing of our securities business to a specialised private bank. This relationship also offers lower project and migration costs, as well as lower costs in the operation. With this step, our customers get the added value of the know-how of the specialists of the private bank.”
Being able to solve these many different pain areas with SOA is making waves with the big technology players in the financial services industry - IBM, SAP, Sun Microsystems and SunGard — who are restructuring their architecture to SOA and making big announcements. Sun Microsystems has recently acquired SeeBeyond, an enterprise application integration firm, to strengthen its software portfolio and its position within the market. Martin Schroeter, chief solution architect at SAP, sees this period as a critical phase but thinks that the industry is on the right road to restructuring. And SunGard is very aggressively pursuing a common SOA across its different units to leverage the technology within SunGard and is planning big launches in the autumn, claims Mats Lillienberg, chief technology officer, SunGard Front Arena.
Michael Liebow, vice president, web services, IBM Global Services, talks about IBM’s roadmap. “I liken SOA to building a highway system. People have cars and they need to get some place, but the highway is not there to allow them this transaction flow. What SOA does is build out an integration layer that allows for this volume of information to travel. That is the plumbing level and what you need to bring it up a level and say that it’s not just the infrastructure but also what rides on the highway: those business processes or elements of applications abstracted as a service. That is the concept — you spend most of the time explaining what these business services are and why they are important and what do they do from an IT and business perspective because they have to deliver benefit to both sides of the house.”
And IBM is willing to pave the way to SOA. IBM Financial Services has recently announced $140 million of investment and a partnership with Fidelity in order to create the underlying SOA for the financial service industry. “It leverages our prior investment in the integrated financial warehouse data model that they can standardise on and allows us to create the ecosystems in banking for platforms to be open and flexible in the marketplace,” says Liebow. “Through our business modelling you can look at what are the strategic areas of the bank, what really provides differentiation in the marketplace. So the business design and the components may be the same bank to bank, but the areas of differentiation, of strategic value, are different. And understanding where your strategic differentiation is — that overall business design — is absolutely critical to being able to develop SOA.”
The buzzwords surrounding SOA are ‘open standards’, ‘loose coupling’ and ‘non-proprietary’. It’s not a big bang approach that wipes out everything that has gone before, but rather it uses the underlying technology in an integrated way. Bruce Graham, vice president worldwide consulting, BEA, says: “SOA begins to allow you to leverage assets you already created, code that you have already got — you can wrap those or encapsulate them and then use it in a much more structured approach to build new applications. And that’s the part that we are seeing: it allows them to re-use stuff they’ve already got. The standards now are giving them an opportunity to do it in an open way without being locked into one vendor.”
“At the heart of it SOA is about open standards and a lot of these companies, after a lot of hard work on standards committees over the years, are finally starting to see some of the benefits of it; this stuff has got to be able to interoperate and allow customers to be a lot more independent of these companies. Sometimes standards committees can be like the UN where they work on stuff that nobody cares about. But in other cases, there have been some very fundamental things that needed to be put in place that are now good enough that people think that it is there, it is working and we are seeing things happen,” continues Graham.
Graham lists six things companies need to be solving as they begin to build an overall SOA roadmap: 1) business strategy; 2) reference architecture; 3) building blocks; 4) existing application portfolios; 5) organisation and governance; and 6) costs and benefits.
“The most difficult challenge for most companies is to figure out what is the organisation and governance model. When working with SOA, the key benefit here is to re-use across more than just your particular silo. Particularly because of the way IT has been since the dotcom bust, there have been some very constricted budgets and the ROI on every project has to be justified - this aligns it to more of a silo approach. Who pays for the funding of it? And once it is in operation, if it turns out to be a wild success, who is going to pay for the additional horsepower you are going to have to throw at it? This is turning out to be, not an insurmountable hurdle or anything, but it is definitely something companies have to consider as they go to this type of model,” says Graham.