BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Buying application integration tools means balancing two missions (tools to move work and tools to address components) and three drivers (business agility, componentization and the cloud) along with considering the technical and business frameworks in which your applications run. The relative importance of these drivers will determine the balance of features you'll need in an application integration tool. All of this information is important to communicate in a request for proposal (RFP) or a more informal buying process, but some areas of particular importance in your buying decision are highlighted below.
A critical point to remember is that all three of the drivers for application integration are growing in importance and spreading to a broader segment of businesses, thus showing that you will have to respond to all three drivers -- business agility, componentization and cloud computing -- eventually.
The process of gathering information and making a product selection weaves through the technical and business frameworks issues. It starts by defining the best strategy for passing work across application boundaries, both in terms of flow and simply locating where your applications are found. It must accommodate your business goals, your current application interfaces and practices, and your technology trends. As you read on, keep in mind that it's best to approach your decision not based on features of technologies, but on how those features meet your needs.
Workflow includes two classes of products
"Workflow" is the mechanism for moving information between applications, and it is divided into two general classes of products. The first are the service or message bus products that provide a kind of highway on which applications and components are placed, and the second are the direct coupling tools designed to allow applications to explicitly link among themselves.
Service or message bus products are best where business transactions are steered among applications based on variable business rules, which means that they're best where considerable business agility is needed. A good workflow product accommodates the business agility driver by providing for business process language work steering on the bus and by supporting transaction loads suitable for current and future business operations. In the real world, this combination is most often found with products classified as "service busses," but it's best to look at both service and message bus products and classify them yourself based on features. Your product selection should classify products by business language steering flexibility and performance.
Direct coupling of applications means that one application makes a "call" to another to pass work. There are three primary application call architectures in use:
- Remote Procedure Call or object-based;
- service-oriented architecture (SOA), also called Web services; and
- Representational State Transfer commonly used in the Internet.
Because applications must be written for a specific direct coupling architecture, it's not possible in most cases to select an architecture, only a product. The direct coupling approaches differ primarily in how many standard features for browsing for useful components, security and reliability, and transaction control (multi-phase commit) are built into the coupling mechanism. SOA and object-broker architectures based on the Common Object Request Broker Architecture are the most sophisticated and also the most difficult to use, but provide standard mechanisms for work exchange among applications. Note that both these architectures can also be used by service or message busses to connect with applications.
Product selection for direct coupling should first establish whether the software in use or to be purchased will accommodate the architecture the product represents, and whether the product supports the full feature set of the architecture rather than a subset. In most cases, unless your business has little need for agile responses to future changes, applications will tend to grow out of the limits of the architecture, so be sure your product will accommodate that growth.
Your primary drivers in workflow strategy are in the business agility category. Your company's ability to be agile or its desire to be agile should be clearly communicated to prospective vendors.
Consider directory strategies
Applications or application components deployed on servers and connected via networks will have to be addressed in order to have work passed to them. This address is stored in a directory where it can be accessed by browsing, through a logical reference name for an application or both.
Directories have to support both access, in order to obtain an application address, and updating, to store the correct address of an application or component when it's deployed. The most important consideration in selecting a directory strategy is compatibility with the access and update mechanisms that your applications and operations processes expect to use.
The most common directory today is the Domain Name Services (DNS) component of the Internet. DNS provides only basic logical-to-physical address translation, insufficient for more sophisticated workflow connections. The Universal Description, Discovery and Integration architecture was developed primarily for the connection of sophisticated workflows in SOA, but it has never gained broad acceptance and should be avoided if possible. The Lightweight Directory Access Protocol is the basis for most modern directory services that offer features beyond DNS.
When selecting a directory product, the first requirement is that it supports a directory strategy compatible with the access and update mechanisms in use or planned. Next, look for performance; can the directory product service the number of requests your applications are likely to generate. Your company's use of componentization and the cloud are the relevant drivers in selecting a directory product, and the ones most important to communicate to your prospective vendors.
Technology implications to be considered
Application integration is a subset of the broader issue of component integration. Your application integration strategy should be as compatible with your component integration strategy as possible – identical, if that's feasible.
One way to ensure compatibility in integration approaches is to consider your primary software supplier as your primary application integration source, unless that proves to be impossible. All of the major software/system vendors, including Dell, HP, IBM, Microsoft, Oracle, Red Hat and SAP now build and distribute componentized software and thus provide tools for integration. Always go to these sources for a quote on application integration tools, and always use the capabilities of your primary software supplier as a reference against which other product options are judged.
If you don't have a unified software approach, you'll have to create a chart showing the integration options available with your current software. Companies are rarely justified changing software to create a unified integration model -- it would be better to select tools that supported all of the integration options you currently use.
The final technical issue to consider is virtualization and the cloud. Applications and their components, in traditional IT, tend to be colocated or at least located within a data center complex. They also tend to stay where they're put unless there's a hardware failure. In the cloud, horizontal scaling under load can multiply application copies, and geographic distribution of copies can support better quality of experience for a dispersed workforce. The cloud makes efficient work distribution more difficult by separating the application pieces, and it adds a dynamic dimension to directory management as well.
Business implications to be considered
IT decisions have to accommodate a highly variable business environment. Generally, this should bias your decisions toward a workflow model of integration with strong support for a business process language to steer work based on business factors. It also means you're likely to need higher performance levels from all of your tools, and the greatest possible breadth of integration interfaces and options from each product.
The fact that you're moving toward becoming a more agile business and also are componentizing or moving to the cloud suggests that you're facing a fairly dramatic level of change in IT practices, enough to mean that it could be worthwhile to examine some of your underlying application choices, and consider making changes that improve your agility overall.
Always look at the growth trends in your application workflows. An increase in transactions or the number of supported workers may have an impact on application quality of experience unless your tools are capable of keeping pace. Be sure to communicate your current and expected activity rates to prospective vendors.
Framing your dialog with suppliers
It's not necessary to issue an RFP for application integration tools; it may not even be productive unless you can narrow your procurement needs to a single product category. But whatever you do, you should communicate your needs to potential vendors in detail. Explain the mission you've identified, the reason for selecting workflow or direct coupling of applications, and your technical and business frameworks.
The technical needs, extracted from the topics above, include application/component interfaces supported, support for steering work based on business policies, the level of performance supported (transaction rate is best), and the extent to which the product is designed to support a specific software framework from major vendors. However, don't simply ask these questions; it's best to obtain the information by asking vendors to respond to the structure of your own needs using the structure this article presents.
Much of your future success with application integration tools will depend on how well a vendor's vision tracks your own requirements. Be sure to convey your own vision in your interactions with prospective suppliers, and be sure to solicit their views of their product evolution. Once you commit to a path to application, you and your vendor(s) are in it together.
Mobile application integration is a whole other discussion.
Streamlining integration services may save developers time and headaches.
Still not convinced the cloud can alleviate your integration pain? Think again.
Enterprises can manage applications using Talend ESB and its open source version, Open Studio for ESB.
Is the MuleSoft Anypoint platform right for you?