3 Approaches for Integrated ALM – A Case for ALM Platform

Different Approaches for Integrated ALM

To address the challenges of Integrated ALM and to achieve at least some of the goals, different tool vendors have taken different strategies, which can be broadly categorized in the three alternative approaches.

Approach #1: Point-to-point Integrated Multi-Vendor Tools

Traditionally the individual vendors have tried to achieve modicum of Integrated ALM by first integrating their own ALM point tools and then integrating some selection of the popular point tools from other vendors. The advantage of such an approach is the simplicity. You need to create only the integration between a particular pair of tools if necessary. However, to achieve the functionality and benefits mentioned above, it is necessary to have point-to-point integration between most, if not every pair of tools. Moreover, since the integration is often done between tools from two different vendors, it often becomes the users’ responsibility to create a workable integration using their own development resources. This results in additional internal tool maintenance and management resources, which are not aligned to the core competency of the organization.

The primary issues with the point-to-point approach are discussed below:

Complexity of combinations From high-school algebra, we know that to have a point-to-point integration between every pair of n tools we need n x (n-1) / 2 number of integrations. For a simple case of 5 tools, this amounts to 10 integrations and just by doubling the number of tools to 10 will result in a 4.5 fold increase in number of integrations to 45. Because of the ad-hoc nature of these integrations, it becomes extremely difficult to create and maintain each individual integration code between the pairs of tools.

Handcrafted Integration Business Rules Since each integration code is custom made for a particular pair of tools, it has the maximum flexibility but at the same time, maintenance becomes very difficult. For example, the business rules of integration like which field maps from one tool to the other, under which condition the data is replicated from one tool to another, or how a change in one tool will be reflected in another – are all hardcoded in the integration code. This means that any change in that logic necessitates changes in that code. Any change in code means a full cycle of development, test, and deployment cycle making it impossible to implement even the smallest change quickly.

Replacement Dilemma It is unlikely that a development group will use a single tool forever. With changing needs, technology and preferences, existing tools often need to be replaced by more effective alternatives. However, a point-to-point architecture becomes a hindrance to such an upgrade. Referring to our example of 5 and 10 tools scenarios, a single tool replacement will result in re-development of up to 4 and 9 integration codes respectively that often becomes the reason for perpetuation of old and inappropriate tool usage. These issues are resulting in some development groups abandoning their custom point-to-point integration projects. Even large service companies with enough in-house software expertise and bandwidth are looking for a replacement of their handcrafted internal integration rats-nest architecture with a more sustainable and scalable solution.

Approach #2: Single Vendor Integrated ALM Tools

Because of the problems faced by point-to-point integration architecture, large vendors like IBM and Microsoft have come up with their own solutions to the Integrated ALM. Though their solutions vary in actual implementation, they can be grouped in the category of ‘single vendor solutions’. While these solutions also aim at including third party vendor tools, the current implementations on the market do not meet these needs.

IBM’s solution consists of the Jazz integration technology and various tools created on Jazz platform. This includes Rational Team Concert, Rational Quality Manager, Rational DOORS, DOORS Next Gen and Rational Requirements Composer. Jazz has an open API, which allows third party vendors to integrate their tools with Jazz. One of the main challenges for Jazz users is its current incompatibility to an existing tool – both from IBM Rational and third party vendors. In fact IBM/ Rational has created a new Requirements Management and Elicitation tool called Requirement Composer even when they have two well established Requirements Management tools RequisitePro and Telelogic DOORS. Moreover, Jazz requirements make existing tools from other vendors incompatible unless they retrofit with Jazz compliant interfaces using OSLC (Open Services for Lifecycle Collaboration) web services, an IBM proposed open standard. As of now, no other major tool vendor has adopted OSLC standard for their existing or future tools. On the other hand, Microsoft’s solution does not include any stand-alone integration technology. Centerpiece for Microsoft’s Integrated ALM solution is the Team Foundation Server (TFS). Like the Rational Team Concert from IBM, TFS includes project management, source control, continuous build and work item management. Comparable to the Eclipse IDE, Microsoft has their Visual Studio Team System along with the tools for modeling, coding and testing. Like IBM, Microsoft proposes that a development team should use all tools from Microsoft to achieve Integrated ALM, though there are scopes for integration of other vendor tools in future. As a result, Microsoft solution requires point-to-point integration for each 3rd party vendor tool with TFS and/ or Visual Studio. This results in similar problems discussed in the point-to-point integration solutions above. Any development group starting afresh and focused only on Java based development or .NET based development may benefit from using IBM/ Rational and Microsoft solutions respectively. However, for the vast majority of organizations with major investments in existing tools from various vendors and development in Java, .NET and other mixed technologies, neither the IBM nor the Microsoft solutions can be very appealing.

The primary issues with single vendor integrated ALM tools approach are recapped below:

1. Rip and Replace The requirement of replacing existing tools by a single vendor tools does not sit well with any development manager. Apart from the difficulty of economic justification for such a move, this results in retraining of the development team members in new tools, which may delay development projects unnecessarily .
2. One Size Fits All It is highly unlikely that built-in tools from a single vendor can serve the needs of a wide range of development groups. However, due to the very nature of the solutions, the users are forced to use these tools even when better and often less expensive (sometime free open source) tools are available and appropriate for their needs. For example, Microsoft’s Visual Studio Team System designer is a brand new tool without any maturity whereas, there are quite a few matured design tools available, which cannot be used in the Microsoft only environment. Similarly, there are many organizations using Perforce, Subversion, PVCS, CVS who will not be able to participate in the IBM only environment, since they do not use ClearCase or the new configuration management built-in Team Center.
3. Technology Islands of Development Single vendor tools create a technology island with little or no chance of working together. Groups developing in both .NET and Java simultaneously using Eclipse and Visual Studio will have severe problems adopting a single vendor approach. It will be difficult to meet any of the functionality and benefits mentioned above in scenarios like that. Though there are patches of integration bridges like integrating TFS to Eclipse by Teamprise (acquired by Microsoft), they are again essentially a point-to-point integration with all its unwanted baggage.

Approach #3: Multi-Vendor Best of Breed Integrated ALM Tools by ALM Middleware

Taking a cue from the integration solutions in other industries, most notably financial software, the concept of ALM middleware addresses all the Integrated ALM requirements squarely and offers some more while avoiding all issues and pitfalls mentioned with the other two approaches of point to point and single vendor integrations. The middleware technology is based on Enterprise Service Bus (ESB) architecture, which has some distinct advantages over any point-to-point integration architecture. These advantages are discussed below:

1. Significantly simpler development To use the previous examples of 5 and 10 tools development environment, the ESB architecture needs 5 and 10 adapters respectively, just one per tool! This is substantially less than 10 and 45 custom integrations necessary for point-to-point architecture. Moreover, to replace one of 5 and 10 tools needs replacement of just one adapter, a far cry from the redevelopment of 4 and 9 integration codes respectively.
2. Protect Investments ALM Middleware is based on a standard set of web service based APIs. Without any special requirement on the tools, ALM Middleware can integrate tools from different vendors, including internally developed tools. This means all the tool investments by a development organization are protected.
3. Best Tools for Best Functions ALM Middleware allows integration of multiple tools from different vendors for the same function. For example, Requirements Management may be covered by any combination of tools from IBM/ Rational (RequisitePro, DOORS, Rational Requirements Composer), Microfocus/ Borland (Caliber-RM). What is even better, it can support simultaneous usage of multiple tools from multiple vendors in a single tools ecosystem. This allows organizations to select the best tools available in the market without locking themselves in a single vendor solution. The table below illustrates the increased flexibility with tool choices using ALM Middleware.
4. Flexibility of Integration Business Rules Integration business rules do change over time for various reasons, including changes in business conditions, group dynamics, and development methodologies. For example, how the Requirements will be replicated from IBM RequisitePro to HP Quality Center so that the Traceability relation created in Quality Center may change over time. Integrated ALM platform allows creation and management of these rules independent of the individual tool adapters. Unlike point-to-point and single-vendor integrations where the logic is hard coded in the integration codes, middleware adapters do not have any embedded business rules. The business rules are managed in middleware administrative module with visual interface for the empowered end users. This eliminates the necessity of development resources for changing the integration codes and reduces the change implementation time drastically from weeks to hours.
5. Traceability with Change Impact Analysis ALM Middleware makes it simple to create Traceability relation between artifacts from various tools. In case of Point-to-point integration where without a central framework only two tools are integrated at a time, there is no way to visualize and manipulate Traceability relations of three or more Artifacts in a single interface. But for ALM Middleware, a central framework allows flexible ways of creating and managing these relationships among multiple (more than a pair of) tools. Moreover, due to its flexibility in relationship management, ALM Middleware promotes multi-tool proactive and reactive change impact analysis. This is impossible to do both in point-to-point and single vendor integration solutions.
6. Process Automation without Boundary Typically, Implementing SDLC Processes for multi-tool ALM requires discipline of individual participants. Such a manual implementation of the process fails after a short time when individuals do not follow it due to high overhead and high cost of retraining for each small change. ALM Middleware, with its built-in process automation capability has a unique advantage of creating a cross tools process and automating that for a transparent no-overhead implementation with a much larger success potential. The typical example is a Requirement that starts life in a Requirements Management tool, is reviewed and approved by stakeholders in a Project Management tool, is implemented by a developer in an IDE, and tested by testers in a Test Management tool. ALM Middleware automates the whole process for all these users even when they are using different tools and may be based at different locations.
7. Analytics and Dashboards Once ALM Middleware has all the artifacts and meta information about the artifacts (e.g. not just the Requirement but the information about the Requestor, Type, Priority, Approval status, Approver, Lifecycle status…) in its repository either by replication (where the artifact information is replicated to ALM Middleware repository) or federation (where the tool data is retrieved on demand, avoiding replication), one can create all sorts of dashboard metrics and reports for those data in real-time. These reports give valuable insight about the whole cross-tool process, which is often impossible or difficult to get.

A Comparison of the 3 Approaches