Mapping business to SOA for Retail Financial Services

By Dharmesh Mistry, edge IPK

What good is technology when it is not aligned to the business? What sober CIO would disagree? So why is it, architectures developed by IT can’t be understood by the business and why is it that a visual representation cannot be used to understand the business from a non-technical perspective? My goal in this article is to describe how a business architecture for retail financial services companies can be mapped onto an SOA architecture so that both business and IT can understand how the objectives of the business are being delivered by IT. Furthermore I hope to show that IT can appreciate the variables of the business that will drive demand for future applications. This is absolutely critical if a CIO wants to help the business achieve its goals for flexibility, time to market, efficiency and product innovation.

As an often over-hyped technology proposition, SOA can be complex and it can seem like a daunting task to even think about implementing something that could influence your organisation on such a business-wide scale. Although not new, the principles of SOA essentially allow applications to communicate with each other as they go about their individual processes, meeting specific business objectives. By linking applications that often speak different languages, the theory is that the business will benefit from increased interoperability and increased federation, thereby achieving the hallowed goals of greater flexibility and efficiency.

Complexity Rules  

One of the underlying issues with SOA has been that in a bid to realise the many promised benefits, organisations have desperately tried to force a new IT architecture onto their current systems, often causing serious conflicts with the objectives of their overall business. An SOA architecture will vary from organisation to organisation but in its simplest form will incorporate Presentation, Process / Business Logic and Data (see Fig A above). Whilst this simple view is easy to understand, until it is given a business context it would be very easy for IT to deliver solutions in the “siloed” fashion that has previously caused problems of interoperability between applications.

The detailed business context across financial services varies greatly, however if you take a high level view it is much simpler and can more easily be mapped to technology (see Fig B below). Fundamentally financial services products are based on information. This might not seem like too much of a problem, but when you consider that your business may well have 1000s of products it becomes a great deal more complex. 30 years ago in the UK there were a mere 500 mortgage products – today there are over 5,000, with some specialist lenders offering over 500 alone. Going forward product innovation will drive more personalisation into products, allowing customers to “configure” their own products.

Each of these products has to be delivered through a number of “business processes”. Traditionally these processes have supported the full lifecycle of CRM: Marketing (target prospect), Sales (fulfill product) and Service. However, the number of processes being managed is increasing not only by smarter CRM but also because of greater regulation creating more processes for compliance and fraud for example. These processes are fairly straight forward in concept and objective but individual product groups tend to mean that processes can become quite different in implementation.

These processes inevitably need some screen-based interaction to support them.

In the diagram you can see the large number of variables that a retail financial services organisation must deal with. Increasingly processes are being delivered through a growing number of “delivery channels”. Processes for products might be the same but they may need to be presented differently to accommodate the channel they are being delivered through. For instance, low brand, large screen, verbose text for call centre staff versus high brand, short text for Internet presence.

More and more the deployment of applications is shifting towards browser based solutions. However here there are variations: point of sale solutions are leading the way for Rich Internet applications, further engaging customers; disability access laws and low technology devices drive the need for pure HTML solutions; call centres require multiple applications in a single browser and hence demand Portal applications. Furthermore, for long duration processes such as Fact Find for regulated products, there is a requirement for offline capabilities to support disconnected data capture on client premises. SOA is enabling new forms of applications such as “composite applications” (single front end to multiple back end systems), which are increasingly being deployed through the browser for process efficiency.

Large-scale consolidation within the industry could also mean your organisation is responsible for a number of inherited brands, each with their own products sets, variants and audiences to serve. You soon realise that trying to control such a beast, let alone pull it into a position to allow any level of interoperability, will be a mammoth undertaking.

Externally, competition is hot as the economic climate pushes consumers to search for the best deal, at the lowest price. With new products hitting the market all the time, retail finance organisations must respond quickly to changing conditions. This is near-impossible when you have to start from scratch each time to develop and configure the necessary information, behaviour and calculations required to launch individual offerings. The timeframes are simply too long.

The end goal therefore is to form a common business and technology architecture, giving organisations the ability to easily identify appropriate technology to fit with their business objectives.

Layering to success

So how can these problems be solved? After all, there are companies out there that manage a multitude of brands, products and other variables, whilst housing a consistent IT set up. Predictably, the answer is flexibility. By mapping business to SOA, a company has the framework from which to create a flexible, service-driven architecture. Further more, the real key to success comes at the presentation-layer, providing the means to view the “available everywhere” information that SOA can provide, from every variable perspective.

Imagine an organisation that could launch new products in days or hours rather than weeks or months. One that knew it could provide a localised, consistent website look and feel for that product to 20 countries at the touch of a button whilst being confident that at the same time, all other internal or 3 rd party viewers would get just the information they needed, updated at the same speed a customer gets. This is not some make-believe aspiration – it is very much a reality.

Such organisations gain their agility by ensuring smooth integration between their base data and their visible presentations. By adopting a layered approach to allow this integration to include business processes and communication with legacy systems, organisations can provide a flexible platform from which to extend or adapt their product sets. Rather than requiring a time-consuming, ground-up, technology development project to mine, enrich and present data, a product launch becomes a function of the presentation. The data is already available in whatever format the company wants because of the SOA architecture, it is merely a question of presenting it in the correct format to each party.

Contrary to popular belief, this level of agility does not even require a developer-heavy workforce. When implemented correctly it can actually be achieved by business analysts, giving the added advantage that business objectives remain front of mind at all times. In letting business drive the agenda, it is the business that maps to the underlying and very capable SOA architecture, not the unsuited technology that constricts the real business objective.

The Future

So what are the key things you should bear in mind?

• Increase productivity through automation to deliver on the increasing demand for screen based applications
• Greater data re-use to create “common” processes or “process fragments” to reduce duplication and hence minimise changes to common items
• Increase business user involvement to get solutions right first time, avoiding lengthy re-development
• Increase marketing flexibility to create/change customer experiences without heavy development penalties (both time and cost)

As architectures collide, it will be those companies that have the ability to remain flexible which will avoid shattering. Painless integration will ensure consistency not only throughout presentations, but ultimately will lead to consistency in revenues – and which boardroom wouldn’t want that?

Dharmesh Mistry is co-founder and Chief Technology and Operations Officer for edge IPK. At edge IPK, he leads product development and professional services. He champions thought leadership about the presentation layer (user interface) within SOA. His blog can be viewed at http://dharmeshmistry.wordpress.com .

Previous Articles by this company:

How technology can turn KYC into a competitive advantage

Risky business