Breaking down barriers

Breaking down barriers

When it comes to implementing service-oriented architecture, it is essential that all parties are not only aligned, but speak the same language.

The desire to see information technology align with the goals of the business it serves seems as old as the IT industry itself. The fact that this is still talked about indicates how little progress has been made. The importance of aligning IT with the business is even more vital when implementing service-oriented architectures. The idea of breaking up the deployment of technology into discreet interoperable services based around business processes requires an in-depth understanding of what those processes are, how they are used, and their interdependencies with other processes within the business.

Failure to do so can result in services that are inappropriate for the task they are assigned to, that are too loosely coupled and hence unresponsive to the functions that are dependent on them, or that are unable to cope under the strain that business users place upon them. Any one of these problems can spell disaster for an SOA implementation.

For MLC however, the wealth management arm of National Australia Bank, the path towards SOA has been made easier by an innovative partnership scheme between IT and business users.

MLC manages more than $100 billion on behalf of individual investors and corporate customers, as well as selling insurance. It embarked on its SOA implementation two years ago as a means of delivering a more flexible and responsive IT environment. The company is using TIBCO Software’s ActiveMatrix and BusinessWorks as the orchestration and mediation layer between services, providing the base infrastructure to adapt messages between existing systems and exposing them to different channels.

Shared responsibility

But rather than having responsibility for SOA residing purely within MLC’s software group, it has been split and handed back in part to the business itself.

David Campbell is head of architecture and strategy in the technology group at MLC, and leads the seven-year-old Software Architecture Forum (SAF). He is not alone however. Within the business lies the Business Architecture Forum (BAF), headed up by general manager John Reid, which was created two years ago to mirror and support the work of the SAF.

Campbell says this so-called business technology partnership structure drives engagement between his team in software and the business, by communicating business strategy back to the technology group and facilitating relationships between the two.

“We take it very seriously, and we have invested quite a lot of effort to get it right,” Campbell says. “We try not to separate business from technology. From a technology perspective, it is our business also to be good at financial services.”

He describes the ideal scenario as one where technology and business are working together towards a business outcome.

“If it means applying technology, or applying another approach, it is good to be in there in that process as it is germinating,” Campbell says. “There is no doubt they [the business] know more about running financial services business than we do. We just want to know enough to be able to have the conversation and identify where value can be added. It is actually better for the business to point out where you are wrong than for the business to think you are irrelevant.”

Reid’s task in architecture commenced two years ago when he was asked to ‘put a light on the hill’ in terms of the products and services that MLC would move forward with. The company had grown through acquisitions, and found itself with multiple versions of numerous products, despite ongoing attempts at rationalisation.

He is quick to confirm that he is not a technology architect himself, but has a keen interest in the field. The membership of the BAF is diverse, including actuaries and experts in designing financial services products, along with some former technologists who attend the weekly working groups.

Improved communication

Reid says birth of the BAF led to some meaningful conversations between themselves and Campbell and his team. At times the task was one that centred on translation as much as explanation.

“Every week we would sit down for an hour or two and they would explain things in detail,” Reid says. “We would then take it offline and talk through the documents so each understood what was meant, because we would often use the same words to mean different things. My main aim was to make sure we stayed instructive and facilitative rather than start getting into an argument about whose meaning was more right than the other.”

Reid says at first it was necessary to explain to the technology group that this was not a case of the business building its own competing technology architecture. What was required however was what he describes as ‘product architecture’ and ‘business architecture’.

“The technology was documented, but we needed to document both the product and business architectures,” Reid says. “Once we had written it down we could start comparing notes and bringing the three together.”

The relationship has since evolved to one where the BAF is now emulating the SAF’s architectural procedures.

“We recognised that really we had no structure, no governance and nothing to aim for on the business side,” Reid says. “And similarly the technology people can have lots of good ideas about where the business should be going, but they’ve got nobody to talk to in a meaningful sense.

“It is becoming a requirement now for all projects that, before we can go into spending serious money, it has to have a tick from the systems architecture forum and the business architecture forum.”

Campbell says the set-up enables the BAF to benefit from the architecture processes that already exist within the SAF and apply them in the business domain, with significant work now happening to share those processes.

“The business has been very good at writing down what they call their target operating model, which is the content of their business architecture,” Campbell says. “That is the main content intersection with what we do, so it guides us in how we implement technology architecture.

No barriers

Having the current arrangement in place has been a huge benefit when it comes to MLC’s SOA deployment, which Campbell says is a result of the organisation’s desire to break down barriers between itself and its customers.

“SOA from the very beginning was a business-oriented set of decisions, as opposed to being about the technology,” Campbell says. “Over the last five years, as we’ve implemented new projects, we’ve looked for opportunities to keep building our business-facing SOA capability, to the point where we’ve enabled our core back-end systems to be SOA compliant.”

Having SOA gives MLC new capabilities, such as straight-through processing of transactions. Advisors will be able to lodge applications directly via the internet and have them processed immediately on its back-end systems. Another benefit of SOA has been greater transparency of workflow processes for advisors.

“If we were going to do straight-through processing five years ago without SOA it would have been a significantly higher cost,” Campbell says.

But while SOA enables channels to be opened up quickly, it also requires high levels of governance, as well as having business and technology working together across all levels of technology.

Also, according to the director of product manager at TIBCO Software, Rourke McNamara, improper planning of an SOA implementation can lead to services being overload and degraded.

“Folk don’t want their SOA initiative to be a victim of their own success,” McNamara says. “They don’t want to run into a situation where a service gets reused a lot and the load gets high, and without understanding what is going to happen the service is overloaded, the performance degrades and all the applications using it fall over or get slow.”

Campbell says that MLC has been careful to ensure that new services are able to cope with the demand placed upon them.

“We’ve been creating coarse-grained enterprise business functions, so we are not having storms of demand,” he says. “We wouldn’t put SOA in between a batch job on the mainframe. But it certainly is an enabler for functionality being deployed across the enterprise and across different channels, which is really where the innovation comes from. ”

To date, Campbell says SOA has been most useful in the operational areas of the business for managing services and the delivery of information to customers and advisors, particularly when that requires assembling information from a number of disparate systems into a single view. Other areas that are candidates for SOA projects include within the organisation’s finance group and management of its operational data.

Consistent outcomes

He is confident that things would not be running so smoothly were it not for the architectural structures that have been put in place.

“The business benefits of SOA is where the magic happens,” Campbell says. “We’ve actually benefitted from using the context of the business to describe our SOA journey. Because it is not about the technology; it is about consistent business outcomes across the enterprise, and talking in the context of business services and business outcomes, rather than technology messages going back and forth.

“It is a very exciting place to be, because we are making technology relevant to our business and we are leveraging the research and development and innovation that we can’t possibly match from our key external partners, with an understanding that they can’t possibly match our business knowledge. So there is quite a sweet spot emerging here, to play in that space of understanding our business drivers and leveraging that research and development and that innovation.”

Campbell says the success being witnessed now is due more to the numerous small things that result from the relationships and collaboration, rather than a single bullet.

“The creation of the business architecture forum and the focus on business architecture within the business has been very important,” he says. “Our CIO Michelle Tredenick has been very passionate in building business engagement and relationship and investing in those processes, as has Greg Hutchinson, my predecessor and now head of regional architecture for NAB technology.”

Over time both Campbell and Reid believe the SAF and BAF will come closer together, with Campbell seeing benefit in an eventual merger of the two forums.

“We think the end game is to have a single peak architecture forum, which will then have sub-forums exploring different levels of detail around technology, product and business architecture” Campbell says. “It is important to do that at the right time, so the maturity levels of the two forums match and that we can engage with a common language.”

The search for singularity

Service-oriented architecture (SOA) is proving especially appealing to companies in the banking and finance sector, where it is being used to deliver greater flexibility for reacting to changing market conditions and customer needs.

Multinational financial services company Citibank has been working within the Asia-Pacific region to deploy SOA-based services using technology from TIBCO Software.

According to the head of Citi’s International Technology Organisation, DK Sharma, the work supports the company’s ‘One Citi’ business strategy to deliver the full benefits of an efficient and integrated organisation to clients. This is designed to drive innovation through the organisation and simplify customer interaction.

Sharma says that with an integrated approach, Citi will have a single view of all the customer’s relationships with different parts of the company. For the customer, this will mean easier interaction and better service.

“One of the things our CEO has talked very strongly about is our need to be extremely customer-centric,” Sharma says. “Whatever we do in terms of our product offering, our technology capability or our operations processes, we need to get extremely client-focused.”

“That means being proactive. Whenever our clients touch us through any channel, we want to be able to get back to them in ‘internet time’, and not in the time that is associated with traditional banking.”

The implementation of SOA started in early 2008 and is expected to continue until the last quarter of 2009. Already the company is seeing some early benefits, including one project that is simplifying credit approval processes. Use of SOA-enabled straight-through processing means functions such as evaluating credit history and determining the client’s ability to repay can be processed faster.

“Through a combination of process redesign and best-in-class technology, we are enabling a capability to respond within less than a day when customers apply for a credit card or a personal loan from any channel,” Sharma says.

Using existing technology would have required using a traditional workflow method with hard-coded programming to match very specific business requirements. Thanks to SOA however, Sharma says everything becomes configurable.

“We can fine-tune and change the product in response to changing market scenarios, or the customer segment that we want to do business with.”

The deployment of SOA will also see the company move to a single web-based platform, eliminating the tangle that exists today. Sharma says that while this will undoubtedly make life simpler for customers, moving to a single web platform internally will also make life easier for employees and reduce training costs, while delivering an environment that is cheaper to operate with reduced risk.

“And our ability to roll out new products and services becomes faster, and in this business faster time to market is an absolute key objective of this whole exercise,” Sharma says.

The bank has overhauled the interaction model between business and technology, and created a business technology team that decides the prioritisation of what needs to be done, the approach to be used, and which technology investments will be made.

“I would emphasise the need to build this end-to-end dialogue within business and technology,” Sharma says. “This is not an easy exercise, so it requires a lot of senior management sponsorship and leadership to stay the course.”

Another area that he describes as critical is ensuring that people are correctly trained to work in an SOA environment.

“If you think that you can learn it on the fly you may end up designing and building something that you think works, but will probably come apart when you come to implementation,” Sharma says.

Sharma also stresses that without the appropriate governance framework, trouble will ensue, as services are created that do not meet business requirements, or cannot handle the workload that is placed on them. He says it is also important to consider how services are coupled, to ensure that latency and delays do not make services unsuitable for the tasks they are supposed to address.

“The technologies are somewhat bleeding edge, and in order to get them deployable in a production environment where they run without any interference requires a lot of fine-tuning and tweaking,” Sharma says. “The proof-points will be in terms of getting appropriate performance throughput and scalability of what we have put in for some of our pilot implementations.”

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!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

Tags strategyservice-oriented architecure

Show Comments