A single, dedicated connection between two applications to exchange information, point-to-point is the traditional (and before the mid-’80s, only) integration method. It’s quick, easy and inexpensive. But as more connections and applications are added to the infrastructure, point-to-point becomes a cobweb of complexity and cost. If one of the applications in the web changes, all the links to other applications must be rewritten. CFOs and CEOs may not know it, but when they complain (as they do on every survey) about IT being slow, inflexible and expensive, they are talking about point-to-point integration.
A third party—usually proprietary middleware—is inserted into the infrastructure to broker and manage communications among applications. Applications link via the messaging infrastructure rather than to each other, reducing the need to rewrite links when applications change. The messaging infrastructure is often constructed as a central conduit, with applications feeding into it like airline flights into a hub city. But the hub can become a choke point. It usually requires a centralized, dedicated staff of specialists to construct and deconstruct links, robbing developers of the flexibility they had when they could write point-to-point links. Improvements in middleware and Web services have reduced the need for every message to go through the hub. Using Web services, for example, developers can link applications directly again. But messaging remains a tactical solution to a strategic problem.
A concept that dates back to the development of object-oriented programming in the ’80s, the services strategy has enjoyed a renaissance with improvements in middleware and the arrival of Internet standards and Web services. The idea is simple: Technology should be expressed as a chunk of a business process—”get credit,” or “find customer,” for example—rather than as an arcane application such as ERP or CRM. The service is often a composite of different applications and data, all hidden behind a complex interface built to make linking among services easy. By chunking data and business logic together into a piece of a critical business process, chances are that it will be used again and again, reducing development time. Developers regain the flexibility they had with point-to-point, but this time the links—ideally, constructed using Web services—are standard and thus can be more easily torn apart and rebuilt. Even better, the services approach comes with a service-oriented architecture (SOA): IT creates a repository of services that developers can use (and, more importantly, reuse) to create new applications and workflows.
4 Business configuration
Create enough services in the SOA repository and you can begin to represent the processes of the company in chunks of software. Changing a process no longer requires expensive rewrites of software and tearing apart convoluted integration links; one can combine and recombine services into new applications and workflows, often without the need for much more than mundane communication programming or, possibly, without the need of IT at all. Businesspeople can use a single screen to drag and drop services together into workflows. The integration logic is automatically generated to link the different pieces together. Integration goes from the primary IT inhibitor of business change to an ally.