Integration in CommonIntegration in Common

Many of the patterns of integration are common among organizations in particular vertical industries — especially when vertical standards are present (or often mandated) such as UCCnet, Health Insurance Portability and Accountability Act of 1996 (HIPAA), RossettaNet, and so forth — because many internal systems and supply chain systems inside and among these companies look alike. Indeed, these organizations attempt to solve the same business problems, thus many appear to have similar solutions. So, why not share?

Some vertical specific patterns include application semantics, processes, resource adapters, and, of course, adherence to vertical standards. The value to understanding that these patterns exist is the opportunity to create common metadata, processes, standard interfaces, and adapters that are transferable from problem domain to problem domain within the same vertical space, thus saving money and time through the use of reusable parts, as well as allowing organizations in the same industry to better adhere to vertical standards since they are no longer one-off custom developed solutions. We all understand the value of reuse; this is just another opportunity.

To this end, many application integration technology vendors have announced their movement into vertical domains such as finance, healthcare, and manufacturing. They provide canned integration components that work inside those verticals, and thus provide more value to the organizations that purchase them. Moreover, specific standards-based connectivity and transformation solutions provide value, such as HIPAA processing for health care or Global Straight Through Processing (GSTP) Transaction Flow Manager (TFM) connections for finance. We can also add supply chain integration to that list using standards such as ebXML, RosettaNet, and EDI (traditional and over the Internet). Some of these vertical standards, such as HIPAA, are mandated by the government (don't use HIPAA and go to jail). Others, such as GSTP, are mandated by an industry, and some, such as ebXML, are just a good suggestion.

What's important here is not how each vertical standard is implemented, but that the vertical standards exist at all, providing common integration approaches and components. With integration being one of the more complex problems to solve, you need all the help you can get.

Breaking Down the Components

If you're interested in integration technology that is localized to a particular vertical, it's helpful to learn how to categorize the components: Components being the types of technology or layers you're going to employ that get you farther down the road within a particular vertical. For the purpose of this column, I divide them into resource adapters, integration services and metadata, as well as process execution (including vertical process subsystems and domain-specific extensions).

Resource adapters, the lowest level of services in the stack, provide the connectivity into any number of source or target systems using standards such as XML, EDI, Web services, or J2EE Connector Architecture (JCA) or, more likely, proprietary packaged application interfaces or direct database access. Furthermore, you may have specialized vertical-oriented adapters here, including connections to the GSTP TFM adapters, HIPAA, EDI, ebXML, RosettaNet, and so on. Resource adapters are very important due to the fact that creating them as custom one-offs for your particular organization is very expensive when you consider development and maintenance costs; it's always better to buy these adapters if you can find them.

Integration services and metadata, which encompass traditional integration server functions, include the transformation and routing of information that make the information sharable among many different applications and standards. New here is the abstraction of application services using newer standards such as Web services or perhaps distributed objects. This is an important component for vertical integration in that many integration services, such as transformation that has to account for the differences in application semantics, may be vertically oriented and thus provide you with many of the transformation mappings. Such is the case with vertical transformation processing in support of HIPAA, where the incoming and outgoing documents are strongly typed and have to be validated to a HIPAA document type.

Process execution and modeling is, in essence, the business process modeling, management, and integration layer. The purpose of this mechanism is to provide a platform for modeling and process execution that orchestrates the movement of information and the invocation of remote application services in support of a business application — in this case, a vertical application that can apply to many problem domains within a vertical market and can be extended for a particular application.

This is a key notion of vertical application integration. Today, formats and application semantics are the typical way to support vertical standards. Orchestration layers in support of a particular vertical are the wave of the future. Moreover, with new process portability standards, such as business process execution language (BPEL), this promise is becoming more of a reality right now. In the future, standards bodies supporting verticals will provide off-the-shelf processes that define how a particular business runs, at least in general. We can further break this notion down into the following: