Mergers and acquisitions have played a significant role in the growth strategy of many banks and financial services institutions in the past decade (Wachovia and First Union, Fleet and Bank of America, JP Morgan Chase and BankOne, Citi and Banamex, to name a few). And in 1998, the Citicorp merger with the Travelers Group, under a two-year trial period granted by the US Federal Reserve Board, ushered in a new dimension of mergers between the banking and insurance domains. Unfortunately, few challenges faced by today’s enterprises pose as daunting a challenge as integrating another entity (through a merger or an acquisition).
Chief technology officers (CTOs) in such a situation are often confronted with overlapping and frequently incompatible business process models, IT applications and technical infrastructure. The challenge for them is to define a new and efficient technology backbone that meets the strategic goals of the organisation, such as increased speed to market, decreased costs, increased return on investment, including ensuring effective software reuse, and close alignment of IT and business objectives.
Enter service-oriented architecture (SOA). Endowing IT architecture with the resilience it needs, SOA also provides a platform for a bank to manage the ever-evolving compliance environment and to secure its information assets. It not only improves and redefines the competitive advantage of an enterprise, but also prepares the supporting technology infrastructure for servicing new business imperatives. A mergers and acquisitions (M&A) situation is an ideal one for SOA.
New business process models
Traditionally, business processes implemented in the enterprise are dictated by supporting IT applications and inherent workflows, which do not necessarily cater to business transactions across organisational boundaries. Services that fall under SOA need to be identified, combined and co-ordinated in a logical manner.
The best approach is to use a process layer on top of services to effectively utilise services provided by different applications in a business transaction. For instance, the loan origination process for a new customer may use a ‘book loan’ service in the operations department provided by the customer data hub application, while the ‘get credit rating’ service would originate from the controls department from the scoring system. Therefore, cross-departmental processes would minimise complexities of individual application workflows. Individual services would not be able to invoke other services independently for completing a business task. Business processes are responsible for procedurally invoking each constituent service, thereby providing a composite service for the services originally requested.
Outsourcing
To fund M&As or entries into newer markets, businesses are continuously seeking process efficiency in their value and supply chains. SOA can create a foundation on which more meaningful integration and governance can be achieved with both customers and vendors.
A SOA throws up immense benefits: for instance, in buying external services, for selective outsourcing, re-using services to reduce costs and facilitate faster change (for applications or outsourcing partners) because the need for detailed technical information in real-time is lesser, leading to fewer dependencies and reduced complexity, and lowering the barriers to outsourcing. Proprietary process definitions would remain in-house ensuring that intellectual property rights are not disclosed to vendors.
However, difficulties in outsourcing concerning business specifications, legislations and tax issues will remain. Industry standards such as ACORD2 for the insurance industry are indicators of the importance of this integration, and an example of how companies in a certain sector are coming together to standardise interactions and streamline integration. Other standards, such as HR-XML for human resources-related transactions, XML for governments, and FiXML for the financial services, are also fast emerging.
Speed to market
With the advent of new markets come changes in IT functionality, types of users and the data architecture. With SOA, businesses are able to respond quickly to these changes and enter newer markets faster and with ease.
Along similar lines, new business objectives might dictate that businesses exit certain markets quickly. In such situations, IT organisations need speed in encapsulating applications and the infrastructure associated with an offering and potentially de-commissioning it, or participating in the sale of assets.
A well-defined SOA, based on business services and platform-independent messaging and where the integration points are separate from the business logic, will assist businesses ably in both these scenarios.
Grappling with the multitude
SOA is built around the concept of a business service, which is a reusable piece of logic designed to execute a business process, with standard access and invocation interfaces. Following a merger or acquisition, there is a prevailing need for rationalising and publishing existing multitudinous applications (related to specific business functions) as business services by wrapping existing application functionalities using standard interface technologies.
This approach allows CTOs to choose services from best-of-breed applications and counter those nuances specific to integration. Only the chosen services would be integrated into the business process.
Interoperability
The loose-coupling paradigm of SOA separates the interface components from the business logic of underlying applications. This proves to be an advantage in that new connections between applications can be made by changing only the interface layer.
The process of ‘wrapping’ existing applications into a service or breaking down the application functionality in terms of business services removes the layer of complexity that has traditionally been present between two disparate systems. The services, once identified and published, are available for invocation, with only request and response parameters that need defining.
Effective software reuse
In addition to extending the lifecycle of critical business applications, services and applications developed using SOA are reusable. A well-defined service need only be created once and is then available for use by other applications and development projects.
SOA outperforms object-oriented development models, which have traditionally been developed as and when required, in the area of discovery and reusability. Object-oriented developers rely on technical specifications and other developers’ comments in the software to determine inputs, functionality and outputs of the various objects. In many instances, writing a new object takes less time than determining if and how an object can be reused. SOA, on the other hand, provides for the discovery of other services that can be incorporated into new applications or other services.
Decreased IT costs
The SOA model enables IT budgets to be reduced in several ways. First, because the underlying applications and technology to support an SOA are already in place at most large organisations, the development of service components is more about integrating existing applications and business logic than it is about writing new systems.
SOA can also extend the useful life of business applications, creating a new method for meeting business requirements. Functionality from various applications, exposed via the services layer, can be integrated to create new applications, views of data or automated processes.
Today, many IT organisations are still pursuing ‘big bang’ implementations and investing a tremendous amount of resources and time in projects – with no guarantee of success. In SOA, projects are smaller in scope and completed in less time. As a result, capital investments tend to be lower because SOA implementations can be treated in a phased manner by building services as per business needs, which then evolve as the business grows.
Business requirements
SOA can add value to an organisation as a result of its ability to align IT with its business drivers. Prior to SOA, IT organisations’ main concerns were related to making disparate technologies work in unison. The siloed implementation of overlapping and incompatible applications creates integration, synchronisation and knowledge management issues, translating into the need for higher maintenance.
Such application-specific complexities are alleviated by the process abstraction that is accomplished as part of SOA. This allows IT resources to focus on how best to use their portfolio of applications and data stores to meet business requirements. This also allows for varied resource allocations, as system maintenance-related tasks would decrease.
Business flexibility
The final area where SOA delivers value to an organisation is in extending business flexibility. According to a recent study of Fortune 500 companies, more than 80% of companies modified their business process models within a two-year period. This pace of change is likely to accelerate, requiring business managers to continually adjust business process models to meet customer, compliance and competitive pressures. To be effective, these adjustments will have to be executed rapidly and without the interference of IT limitations.
The abstract process layer and loosely coupled platform of independent business services will provide a head start for the modification and extension of technology infrastructure to support these business changes.
SOA’s value in the case of an M&A scenario is undeniable. However, maximising its benefits calls for a combined tactical and strategic approach, and, most importantly, a paradigm shift in the way applications are regarded today.
Bhuvan Satwan is a consultant at i-flex consulting.
