Adapter Development Methodology and Best Practices
- Understanding Integration Project Objectives
- Managing Integration Teams
- Role of Adapters in Integration Project
- Adapter Analysis
- Adapter Design
- Adapter Coding
- Adapter QA
- Deploying Adapters
- Adapter Maintenance
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
- "Even if you are on the right track, you'll get run over if you just sit there."
- —Will Rogers, American humorist
Business today is heavily dependent on interactions and networking with customers, partners, suppliers, and employees. This dependency on integration of business processes and resources drives the need for integrated business applications. The days of developing standalone applications are long gone, and today none of the applications can satisfy users' requirements for information and transaction processing without interfacing with other applications. Almost all software development projects can be categorized as one of the following:
-
Developing a new business application using emerging technologies, leading edge software paradigms, new platforms, and tools.
-
Upgrading existing systems by adding new functions to exchange data and functions with other applications. New functions typically include Web enabling legacy applications and adding integration capabilities.
-
Deploying a third-party package or upgrading an existing third-party package. Typically, deploying third-party packages involves data migration issues, customization issues, and integration with existing business applications.
-
Research projects and other initiatives that experiment with new technologies such as wireless networking and wireless applications can work in an isolated environment or with limited integration with existing systems.
-
Composite applications are a new category of applications that integrate isolated applications as a coherent system capable of supporting e-Business requirements—typically, web services.
In each of these scenarios, the need to integrate business applications is driven not just by the technical requirements; it is mainly the business requirements that drive the software development projects. Application integration has become part of mainstream software development, and it is essential to include integration as a primary objective when planning and managing software projects.
Do we need a new methodology for handling the inclusion of integration requirements and adapter development? Not unless software development is managed without a methodology in the first place. This chapter is not about introducing a new methodology, but customizing existing methodologies for adapter development. Many significant differences exist between standard application development and software development involving adapters or integration. The following sections identify the most important aspects of adapter development, and present how to apply known methodologies and techniques to overcome some of the unique challenges.
Understanding Integration Project Objectives
Most adapter-related projects are initiated as part of other mainstream development projects. Sometimes, an adapter requirement is identified during system integration. In many instances, adapter requirements come from IT staff who handle data integrity issues rather than application users. The reason for this is that most end-users assume that application integration is a normal feature of software. I have seen numerous occasions when end-users were surprised when their applications were not able to share data with other applications without major modifications. In these situations, IT staff are usually commissioned to come up with a short-term solution in the form of shell scripts and other manual processes. The problem is that over time there are too many short-term solutions. Although sometimes time constraints demand patchy solutions and manual application integration procedures, the long-term solution is a proper EAI platform and adapters. This chapter should be useful for project managers who have identified a need for adapters or who are undertaking software development projects.
As an example project, let's consider the Web enabling of a customer service application. The application is currently used by internal customer service staff. These users are trained in-house to handle specific customer situations and exceptions, and to customize business processes to meet the customer needs. However, with the customer interacting directly with the application, most of the work done by the customer service staff will now be the responsibility of the customer. Some of the major differences of Internet-based applications supporting E-Business initiatives and the legacy applications are the end-users and their roles. Web-enabling external business services and internal business processes require the end-users to take more responsibilities than before.
Business processes that were handled manually by the customer service staff now need to be automated by the application and its infrastructure. It is not surprising to see Web enabling of one application requiring significant modifications to other business applications. The need to understand the end-to-end business processes and their impact on all the applications participating in those business processes is fundamental to any E-Business project. As a result, every E-Business project becomes an integration project with varying degrees of complexities.
For many legacy systems developed to work in isolation, integration is a new phenomenon. Adding integration capabilities to existing applications requires careful planning and sustained development. A good design principle is to isolate and localize the integration capabilities of each business application in a separate component that is directly associated with the application. These components are known by different terms: adapters, connectors, components, and so on. The separation of core application functionality and integration logic enables software developers to evolve the business application and the adapter with minimum dependency. Figure 7.1 shows an integration-ready application. The architecture includes an additional integration tier; this tier supports the different types of integration components.
Figure 7.1 Integration-ready applications.){kind=link}