Integration and adapter software development are creeping into the mainstream, and both require a different type of project management. Learn some methodologies to help lead you through the analysis, design, coding, and QA of your project.

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.

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.