This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - ALM development, projects and processes: Read more in this section
- Getting business leaders involved with ALM process
- Virtual applications for ALM
- Tools for SOA ALM processes
- Unified DevOps approach to ALM
Explore other sections in this guide:
For SOA application lifecycle management (ALM), to "come of age," it must reflect the fact that modern applications are increasingly created by reusing components and re-orchestrating workflows. When a component changes, it could impact a half-dozen applications. An application change that alters component behavior could similarly explode across application boundaries into unexpected areas.
Software architects have to think about deployment and redeployment, even testing and compliance, completely differently in a service-oriented architecture (SOA) world. Despite this need, most architects say their organizations haven't completed the transition. A two-dimensional view of applications and selection of component-optimized tools can bring SOA ALM to the state needed to face the future of the cloud.
The most overlooked element of a multi-dimensional impact matrix is the business processes element.
Creating a meaningful SOA ALM process
The starting point for any meaningful SOA ALM process is a mechanism to link components with applications. While SOA requires some directory function to support workflow linkages among components, it doesn't mandate that these linkages be referenced back to the applications and, from them, to the business processes they support.
Vendors such as IBM, Microsoft and Oracle, which provide complete SOA development/deployment suites, offer component inventory features and mechanisms for this kind of tracking. Companies who create their own ALM toolkit have to consider how well business-to-application-to-component mapping is handled and, in particular, whether it can support backtracking from component changes to applications and business processes impacted.
The goal of this correlation is to scope the impact of a change, given the intercreative nature of componentized applications. In a modern SOA ALM process, the goal is to allow any change in a business practice, application, or component to be tracked across all of these areas of impact -- the "first dimension" of change management.
Measuring the scope of change
The critical "second dimension" is to examine other applications and areas that are influenced by the primary change. In effect, this will take a matrix of business practice, application and component relationships and draw an impact surface that identifies the scope over which the change's impact might be expected to propagate. This becomes the scope of the ALM processes.
The most overlooked element of a multi-dimensional impact matrix is the business processes element. A change in an application component may impact how that component is used, not only in the application that may have driven the change, but also in all other applications into which the component is integrated. Software architects report that there is a problem in linking the output of formalized enterprise architecture (EA) business process maps with software components.
All major SOA suite providers offer practice hints in linking EA methodologies (TOGAF, FEA, Zachman, Gartner, etc) with SOA development, but specific tools to support this linkage are sparse. This may force architects (both EA and application) to organize their practices around software and requirements documentation tools.
The Open Group provides practice management steps to integrate EA with SOA, but these focus more on design than on the entire lifecycle. However, a proper EA framework linking business practices to SOA design (creating the "services" in SOA) will allow a software architect to extend a SOA component-to-application matrix into the business process dimension fairly conveniently and, in fact, this may be the only way such a linkage can be created reliably.
Organizing an ALM process
Once an application architect has a matrix that identifies the areas likely to be impacted by a given change in a SOA component/application, the next step is to organize the ALM processes accordingly. How that's best accomplished will depend primarily on how interdependent the applications are.
If component reuse is common and business process impact is broad, the best course would be to abandon per-application ALM and think in terms of a holistic SOA-ALM union. You will know this is the case if your impact chart always shows everything being impacted!
In normal situations, SOA application and component changes will usually spread to only a few related applications. In this case, the best practice is to simply launch the ALM processes for all the applications impacted and, at the testing phase, converge the activities to ensure there's no duplication or missed elements.
Managing ALM processes
For managing a series of ALM processes triggered by a change in a shared element, architects report that traditional project management tools are a good start. In most cases, ALM processes are defined by a set of practice documents supported by tools.
More on application lifecycle management
Top ALM deployment best practices
Automated tools for ALM
Simplifying mobile ALM with hybrid HTLM5
All that's needed is to converge these at the appropriate point (usually pilot testing, often with real users) and to insure the specific test data and requirements are merged at that stage. The remainder of the ALM cycle will then proceed on the merged requirements set, effectively treating all of the impacted applications as a single application.
Enterprises suggest that as this kind of converged ALM proceeds, it may generate indicators that harmonizing test data and practices across all applications, or at least across groups of related applications, is wise. If three applications share components, having a common test framework will require some tests be skipped where a given application isn't affected by changes. This isn't usually difficult if tests are properly organized and documented.
Enterprises have reported that even careful auditing of component reuse can miss interdependencies among applications. Having a full set of related applications tested en masse as the final phase of ALM validation can be viewed as a last checkpoint to avoid problems.
SOA ALM and cloud computing
Growth in cloud computing is likely to increase the componentization of applications, permit component replication, improve performance, facilitate customization of worker support and maximize productivity. It's also likely to increase the frequency of reuse of components, even across company boundaries in hybrid cloud relationships. Getting SOA ALM on track is a huge step in preparing for the cloud deployments of the future.