For today's banks and brokerage firms, addressing the ‘world as it is’ means keeping pace with the changing structure in organisations – providing technology to address growth, compliance, and deliver expanded repertories of services. But keeping up with this change can put IT teams in a continual reactive mode, and that has some serious downsides. One growing challenge is the capability gap between the newer online web-based channels and the legacy backend systems with batch processing constraints. Another problem is that without an architectural approach to enterprise information management, usage of data across product silos is inconsistent and a single view of the customer is impossible. The resulting problems with channel-or ‘customer touch point’-integration include high complexity and cost, and limited flexibility and scalability. We keep hearing about IT being agile enough to be always ready for the business world ‘as it will be’. And in these discussions about structuring systems and processes to meet new demands, a term that keeps coming up is Service-Oriented Architecture, or SOA. This article provides a detailed view of the benefits of implementing SOA and also clears the common misconceptions associated with it.
Introduction
SOA is not simply about IT, but about the enterprise as a whole. Encompassing people, processes, and technology, SOA is an approach to managing all these resources by representing functionality as services that business users can compose into processes defined by business requirements.
In IT terms, SOA is an approach to distributed computing that abstracts complex, heterogeneous IT systems into composite, business-oriented services. The perspective is that business applications are all about ‘service delivery,’ and they need to be represented as granular services to achieve the modularity and reuse that drive IT costs down and increase resource efficiencies.
With SOA, you move away from platform and vendor-dependent technology towards an architectural solution to chronic IT problems. SOA means embracing heterogeneity and leveraging existing investments rather than ‘rip and replace’.
However, there are a few misconceptions that people have about SOA. One fact is that SOA is never a ‘big bang’ effort. SOA requires a phased roadmap approach and you must start with a thorough upfront assessment of requirements, not simply in IT, but business-wide. Achieving a SOA is a journey that can take several years. Another basic is that SOA is not just about technology – the SOA journey also involves people and processes.
There are many other ‘myths’ about SOA, and seven of the most common are addressed in the sections that follow.
Myth 1: SOAs Are Too Expensive
This myth has its origins in organisations that did not plan a SOA roadmap, but simply tacked the idea of multi-channel integration or creating common services onto an existing initiative such as updating a branch banking system. Suddenly the costs for that single initiative spiraled out of control. The problem here is not cost but inadequate planning. Of course there are costs involved in the SOA architectural approach and required governance, and these must be planned and budgeted from a holistic, enterprise-wide standpoint. Once implemented, SOAs decrease costs by driving reuse and vendor agnosticism. And by focusing on simplicity and modularity, SOA radically reduces development costs.
Myth 2: There's No Business Case
The first step in implementing a SOA is not technology implementation at all. It is planning, and this planning is tied directly to business justification. You start with the business view (why you want to do something), then move to the functional view (what exactly you need to accomplish), and finally get to a technical view of how to do it (which is where SOA comes in with its technology-neutral approach).
If you view a business application such as mortgage processing or loan origination in isolation, it does not matter much how that application was created. But in terms of the compelling issues that a line of business is facing – such as customer retention or increasing ‘wallet share’ – moving from point applications and legacy systems to a services-oriented IT world has very clear business justification. You are not justifying an architecture, but the ability to serve customers faster, address compliance requirements efficiently, and so on.
One possible starting point is to evaluate which business processes generate the most Return on Investment (RoI) for your company, and prioritise your SOA deployment to make these processes more efficient and more customer-aware.
Myth 3: Structure Hinders SOA
This is probably true. It's important to understand that SOA drives some organisational changes and calls for a fresh look based on a review of business requirements. ‘Consensus combined with governance’ is a good summation of a successful SOA. SOA calls for enterprise governance that establishes and communicates policies that employees must follow for technology implementations, gives employees the tools they need to be compliant with those policies, provides visibility into the levels of compliance across the organisation, and mitigates any deviations from established policy. Some major banks, for example, have instituted ‘reuse metrics’ for their development environments to encourage leveraging of existing services.
Myth 4: Web Services Trumps SOA
There is a relationship, but the use of Web Services does not constitute a SOA or deliver its benefits. SOA is an architectural approach, while Web Services is an implementation of SOA, in which interfaces are based on standardized Internet protocols. SOA takes planning based on business requirements and priorities, implementation of governance, and a phased, roadmap approach to achieve a true service-oriented environment.
Myth 5: Integration Woes Dissolve
It's true that by adopting the strategy you need for a successful SOA, you will ultimately eliminate integration problems. The distinction is that it's the underlying information integration strategy that is the solution, not a magic bullet effect of the SOA architecture. Planning for a SOA, assessing business requirements, and establishing governance and an underlying information integration strategy are the ways to solve integration problems.
Myth 6: SOA Is Unmanageable
If you enable the proliferation of services without governance or continue to have siloed development, any system becomes too difficult to manage. A successful SOA involves the coordinated application of technology, expertise, and resources. Governance is a key element of this, and the right management tools are also vital.
Myth 7: SOA Is Lower Priority
The financial industry is facing serious challenges with enterprise architecture, and this myth has its origins in those very real pressures. The priorities of compliance and proliferating service offerings can force IT into reactive mode. Adopting SOA can be the solution. SOA and its related governance structure can give IT the flexibility to adjust more rapidly and easily to continual change.
Conclusion
Moving to SOA is as fundamental a change as client/server was to mainframe or the Internet was to client/server. The move to SOA has a major reward – relief from the reactive treadmill in IT.
SOA offers dramatic improvements in three areas of particular urgency for banking – customer retention, compliance, and operational efficiency. To make attracting and retaining customers less expensive and complex, SOA helps establish a single view of the customer and reduces costs for developing new services. The continually shifting processes required for compliance are faster and easier when architecture and governance facilitate quick action.
And when it comes to operational efficiency, SOA enables businesses to introduce new practices, processes, and services more rapidly and at a lower cost. Myths aside, the fundamental business reason for moving toward the architectural approach of SOA is business flexibility, and this is an enormous advantage with wide-reaching implications across banking and financial enterprises.
Jason Chia is Practice Principal for Enterprise Integration HP Services Consulting & Integration, Hewlett Packard Asia Pacific |
