The use of multiple application lifecycle management (ALM) systems can lower user productivity and create errors. There are several ways to connect and integrate multiple ALM systems. Here’s a list of integration options for unifying multiple ALM systems, in the fashion of a military ranking scale. The list begins with the do-nothing, integration-less approach and culminates with the most optimal approach to ALM integration: the enterprise service bus.
Rank: Civilian (do nothing)
There’s no rule stating that you have to connect and integrate multiple ALM systems! Doing nothing is a no-cost, but no-benefit, approach that leads to ALM islands that do not have the ability to communicate with one another.
Advantage: No cost
Disadvantages: Users of each system can’t see what others are doing. And even those with multiple installations from a single vendor can have workflow and process breakdown.
Rank: Enlistee (manual)
This approach involves collaboration by manually copying, cutting, pasting, and replacing data between systems or by using email to communicate project details between teams or departments.
Advantage: This is the first step in having ALM systems communicate with one another.
Disadvantages: The workflow/processing method for manually importing data is time-consuming, repetitive, and manually intensive. Due to human automation, it’s prone to error.
Rank: Captain (custom coding)
This approach calls for home-grown, custom hard coding performed by middleware programmers.
Advantage: This band-aid approach to coding solves the ALM integration issues of the day by taking advantage of resident talent.
Disadvantages: Most developers resort to building their own integrations because of the misconception that hard-coded integrations can only be customized on a case-by-case basis. However, it’s costly to divert in-house talent to developing tools. Middleware consultants are expensive, and depending on them can make custom coding risky. It also takes a lot of time for programmers to keep up with all necessary revisions, recoding, and retesting, and lack of mapping/integration templates makes hard coding unnecessarily complex.
Rank: Colonel (plugins)
Plugins, also referred to as add-ons, are extensions that add features and functionality to a core product. They are usually developed by third-party software providers. In the case of ALM, the added integration functionality provided by plugins only works between two specified vendors’ products. This point-to-point offering is purpose-built for a single function, and is usually installed on an incumbent application server. It makes custom coding unnecessary.
Advantage: Plugins can result in more rapid integration than custom coding, saving programmers time.
Disadvantages: Plugins often involve inelegant code developed solely for point-to-point integrations. Some major drawbacks to using plugins when doing ALM system upgrades are that the plugins have to be compatible with the newest version of the system and that the administrator needs to keep up with the ALM vendor’s releases. As plugins run on application servers, server performance may be compromised, leading to higher CPU utilization and potential crashes.
Rank: General (enterprise service bus)
An enterprise service bus (ESB) is a software architecture approach that uses a common messaging fabric as the backbone for connecting and integrating an enterprise’s applications. In order to communicate between the various applications and endpoints, an adapter is required. This adapter, also referred to as a connector, is a self-contained component that uses the published APIs of external applications to communicate via the ESB.
Advantages: The primary advantage of an ESB is accelerated integration and efficiency. There can also be a cost advantage because users no longer need a license for many systems. Manual methods mean a user license for each ALM applications and each user, which can require the purchase of hundreds or thousands of licenses! Using an ESB, the same user license is used to copy many sets of data so the thousands of user licenses can be reduced to only two. Through the decoupling of the application stack, policies and rules can be changed without making any modifications to the adapter since there is no business logic hard coded into the adapter. This makes the adapter a more lightweight interface than a plugin. An ROI analysis performed by customers of ESB vendor MuleSoft revealed that ESB integration is 5x to 20x faster than custom code integration.
Disadvantages: An ESB is a long-term investment if used as a platform to build corporate-wide connectivity. However, using an ESB solely as a mechanism to unlock specific off-the-shelf features (e.g., scalability, pooling, connectivity, enterprise management, etc.) alleviates the need for a company to code these specific features. Refer to the MuleSoft blog article “To ESB or not to ESB” for more information.
A four-star general knows how to manage resources to achieve strength and efficiency. When choosing an approach to unify ALM systems, one needs to balance expediency against a strong architecture. With ESBs embracing an open, modular approach agnostic towards any particular products, the choice is a no-brainer. Using an ESB gives access to a common core of architectural features and, in conjunction with adapters, enables communications and transformations specific to those adapters (e.g., comments, attachments, links, etc.). Furthermore, it allows an incremental approach towards development and future-proofing one’s architectural investment.
Johnathan McGowan is a Sr Solutions Architect at ConnectALL. He is responsible for customer-facing technical resource for the ConnectALL integration tool. He works with Account Managers to assess prospect needs and build demo integration solutions, guide prospects through product evaluations, and assist clients with their production deployments.
