Menu
Menu
SOA pays off for PSIS

SOA pays off for PSIS

‘It’s about business, not technology’ was the crucial lesson learnt from the co-operative’s transfer to an SOA framework.

Service oriented architecture (SOA) was the last item to come out of a revision of the business strategy of PSIS in 2006. The new strategy for the financial services co-operative came purely from business drivers, says enterprise architect Mike Burrowes. “Our thinking went around: What does the business need today; what do they need tomorrow and 10 years down the line as well as we could estimate? “The basic message was flexibility, integration and a common user interface.”

Agility — the ability to get applications developed and, where necessary amended quickly — was a less explicitly outlined requirement, but definitely implied.

Only after the priorities had been decided and worked on, did SOA appear as a logical solution.

The co-operative’s legacy ICT system was monolithic — everything was essentially one big application. The user interface for each task was individually designed.

As it wants to minimise risk and not subject staff to repeated change, PSIS will develop a consistent user interface first, says Annette Nata, PSIS general manager IT.

“We allow that to be the one and only change for our users,” she says. It is key to delivering “the huge new functionality”.

Some applications still have a green-screen interface, while the customer relationship management system is Windows-based.

Creating a new interface “would allow us to move off the mainframe — that’s one of our key risks”, says Nata. The applications were written in Cobol, “which is not being taught anymore”.

The new code will be written around .Net. That, too, was a late decision, “though we have always been a Microsoft shop”, says Burrowes. “We’re bringing in the Microsoft implementation of web services,” with Windows Communications Foundation as a wrap-round security framework.

To further ease the transition, PSIS is using Microsoft’s Model View Controller. “That lets us further divorce presentation from data,” says Burrowes.

The team did a proof of concept by putting a front end — Unisys’s ePortal — on three mainframe applications. It converted the textual messages from those applications into XML format. “So that supplies a method under web services that we can pick up and from there we built a simple model with a small number of transactions,” says Burrowes.

“We proved that we could interface to all three of the systems,” says Nata — transactional banking, CRM and ActiveDocs, a tool for generating and managing complex documents.

The exercise did not consider details such as managing servers — though some work was done on virtualisation. “Its purpose was to prove that the technology could enable our vision of SOA,” says Nata. Microsoft staff were “engaged to cast a jaundiced eye over what we had done”.

Adopting SOA through web services means a smooth interface with other organisations, for example, Inland Revenue and credit-checking company Veda Advantage, that may construct their systems with different hardware and systems software, such as IBM’s Websphere.

Web services don’t have to be SOA-compliant, Burrowes emphasises, it’s just the way PSIS has chosen to implement SOA.

By “decoupling” presentation, process and data repository from the core business functions, PSIS reduces the likelihood of compromising those functions, he says. “The strength of SOA is being able to more easily replicate a real-life business process.”

Typically core processes such as a deposit, withdrawal or funds transfer are the most stable things about a business. “They rarely change. What does change are maybe the presentation layer and definitely the [data manipulation] process that’s behind them.

“The secret to the whole thing — and we haven’t met that challenge yet — is getting the granularity right. I could say we’ve got 500 distinct functions, then build a web service for each; but to me that’s not a successful SOA implementation.”

You could probably use larger chunks, each of which could still be reused as one module in other business processes. “You need to be driven by the understanding of the business as to what ‘a process’ is.”

Checking an account balance, for example, applies to several business processes, so it may be that this will be a fine-grained web service in the final system.

Lending will be the first application implemented under SOA. “That’s a complex process and both business and IT are discovering this on a daily basis,” says Burrowes. “Real users have been involved from day one.” As well, some of the team are IT business analysts, software architects, usability specialists and head-office staff who understand lending policies — “and all this is before we write one line of code”.

The policymakers’ involvement serves a broader purpose than developing a new computer system; it will make everyone aware of why the policies are there and encourage stricter adherence.

“We can start capturing a lot more data for MIS (managing information systems) purposes,like how many declines do we have and how long do they take,” says Nata. This feeds into head office’s priority — increased productivity.

“Forget about the technology,” says Burrowes. “The whole purpose of the project is to make life easier for the people working in our branches.”

Using the modern ‘language’ of SOA and web services means easier recruitment of staff, who have been trained in those frameworks, and it may allow some functions, such as a credit-scoring system to be bought ready-made and slotted in smoothly with the other services, says Nata.

Even when an application does not have a standard web services interface, “using the SOA approach you can mask that interface well away from the end-user”, says Burrowes.

To ‘sell’ the new system to the business, the team used metaphors such as Lego building blocks to describe the easy slotting together of reusable services.

“We don’t talk about the technology,” says Burrowes. “The business does not expect to sign off on the technology; they sign off on our implementation of their business processes. The way we describe that is by using cases and mock-up screens, not by class diagrams. Businesses like to see words and visuals.”

At present, for a complex transaction, an operator may have to use as many as 50 different screens, some requiring separate logins, says Nata. “We’ll replace that with five or six screens” and that’s the kind of demonstration that makes sense to the business, she says.

PSIS has purposely taken a gradual “risk-averse” approach. “This is potentially a seven-year series of projects,” Burrowes says. The co-operative wants to have the option of pulling out at any stage and still having a working SOA-based system for some processes.

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.

Tags CIO roleSOAArchitecturefinanceservice-oriented architecure

Show Comments