The focus on meeting the needs of stakeholders leads to an increasing number of new technologies, platforms, business requirements and other drivers impacting on the traditionally controlled world of IT. Increasingly it is these new business processes that are driving the architecture of IT’s systems and applications – traditionally it has often been the other way around.

No enterprise can afford to invest the time or resources to redevelop their core business applications and data stores each time a new service is to be delivered or a new application function provided. You therefore need an

integration architecture that allows you to quickly, easily and efficiently reuse your legacy applications and data stores – to multiply the value of those assets and create a substantial return on your investment.

Let us consider some examples in the context of an insurance company with a legacy quotation system. This is one of the application islands and contains both application functionality and the supporting data stores. The quotation system has been linked with other application islands in the past, but these have been one-off tactical links to meet specific project needs. Stakeholder demands are creating a number of integration requirements with their associated technologies:

• Local Applications – The branch offices are to be gradually migrated to a new GUI-based quotation application running on LAN workstations. The users are experienced in insurance but do not necessarily have any experience in using the legacy application. How do you connect the GUI client platform to your legacy applications and data stores?
• Remote Applications – The insurance agents that go to visit customers need quotation functionality on their notebook computers. The notebooks are typically used disconnected from the company network so need to be able to work in a store-and-forward mode when offline, or in real-time when online. The remote application has the same basic needs as the local version, but clearly has different technical needs when working offline. How do you support these specific remote requirements?
• Web Applications – The quotation functionality is to be made available to the general public via the company Web site. Because the general public has no specialist experience and no training the user interaction must be very simple and self-explanatory. How do you make the legacy functionality available as a Web application where the user interaction model is totally different to the host application?
• Mobile Applications – The marketing department wants to experiment with a PDA-based solution which the sales agents can take with them to customers in “out of the office” situations. The agent should be able to use the full-function quote system and also the user version normally provided via the Web site. How do you meet the needs of the marketing department to build experimental applications which may, or may not, exist for more than a few weeks or months?
• Web Services – The insurance company is thinking about opening their quote system to selected insurance industry portals. There are also plans to connect the legacy systems to the back-office applications of some large customers. How do you expose the core functionality of your legacy applications and data stores as Web services or other B2B connectivity technology?
• Application to Application – The insurance company may be implementing a CRM application to improve customer retention. A part of this project might be to allow quotations to be issued from within the CRM application. How do you interface the new CRM application with the existing legacy quote application, given that you have not decided on which CRM product to use, or which platform it will run on?

Many enterprises are faced with these types of integration scenarios. The focus in each case is external, meeting the needs of diverse stakeholders. This is a big change to the past when a focus of integration was to make the life of the IT group easier. Those days are now long gone.

In today’s complex integration environment the problem is not really the physical connections between applications – there are a wide range of commodity middleware solutions for this. Neither is the problem one of new platforms, nor that the legacy applications were not designed for distributed applications, the Internet or Web services. The fundamental problem is the lack of adaptivity – not just in the legacy applications, but also in the new and leading-edge applications that are being built right now.

The ability of integration solutions to adapt becomes essential when you consider the simple fact that integration is always a process and never a one-off event. Each of the elements within the integration environment has its own rate of change, its own development and maintenance schedules, and its own technology adoption cycle. In some cases there is even an element of the seasonal changes in fashion!

The bottom line is that your integration solution has to be able to thrive in an environment that is constantly changing. SCORE Adaptive Bridges is specifically designed for such a changing environment – this is why we talk about “Integration in Motion”.

You cannot know what you will need to integrate with next, but it is sure it will be different to what you have done before. To prepare for the unknown and unexpected demands an adaptive solution.

Where to Go Next?

Read on to see how SCORE Adaptive Bridges creates Adaptive Services that solve these problems for you.