This work investigates Application Lifecycle Management (ALM) and elaborates a methodology for building an ALM platform for organizations dealing with manufacturing of software products. The meaning of platform is defined and available ALM platforms on the market are analyzed as a part of the methodology execution. Emphasis is put on basic principles coming from PLM - Product Lifecycle Management which are about integration of different parts and roles in an organization with the purpose of better information exchange that positively impacts business agility, performance and visibility.
Application Lifecycle Management (ALM) is a term coined in various sources,
(examples [
The idea behind PLM is to solve the problem of un-integrated work of different
roles and parts of an organization that collaborate on product throughout its lifecycle
[
The ALM platform in short encompasses all the technical means that enable the
above stated qualities of the information throughout the software product lifecycle.
While it is possible to build such a platform from existing tools and systems, market
offers out-of-box ALM solutions [
Organizations participating in software business usually have some set of tools in place therefore obtaining an out-of-box ALM platform is a huge responsibility and requires a thorough fit-gap analysis prior to making the decision.
This article describes the elaborated methodology for building the ALM platform based on current state of an organization producing software products. At the end, execution (partial) of the methodology with fit-gap analysis method to four ALM platforms available on the market is presented.
The elaborated methodology consists of two parts: ALM Readiness check – describes/defines target organization’s product lifecycle against ALM Reference model; ALM Tool investigation – investigates tools that support the described product lifecycle and evaluates them accordingly to ALM Reference Requirements (derived from the ALM Reference model).
Figure 1 illustrates the mapping of the methodology foundation (ALM Reference model and ALM Reference requirements) to the product lifecycle and its tools.
In order to build the ALM platform, reference points are needed. Investigation of the
information about IT industry shows that there is a lack of independent, objective
guides/methods for ALM type of solutions. Variety of sources [
Birth/Growth/End-Of-Life block is either a starting, improvement or end-of-life point for the product. Depending on organization, this may be a small set of few separate products reaching to huge program and product portfolio management processes that are targeted in this block. This block maintains product’s full information that is updated on frequent basis.
Business model block is the place where product’s feasibility is validated before
the actual product development is started. It is included in the model as extension to
classical project management. It is proposed to function according to innovative way
of creating business models as proposed by A. Osterwalder [
R&D block represents Research & Development phase of the model which
includes finding the right technology and running software development according to
some of known software development approaches [
Production/CRM block is the last phase which mainly includes processes like Release and Customer Relationship Management (CRM). Challenges in here are release strategy choice, actual release management, customer feedback incorporation into development and similar. The key idea of this block’s relation with block 1 is getting the real production statistical data and CRM data as input into block 1 for correct and timely decision making about the fate of the existing products (termination, further development, new product).
Analytics is the core of this model as it is meant as continuously analyzing part of
processes and information in other blocks. It can be divided into internal and external
parts. Internal is any type of analytics solution up until enterprise level business
intelligence implementations [
Main feature of the model is Integration which makes all parts of it work as one system. This way it achieves high agility and visibility of information under processing. 2.2
In order to execute partially the methodology with fit-gap analysis method, twenty nine ALM Reference requirements are derived from the ALM Reference model that represent the model’s blocks in more details. See Appendix: ALM Reference requirements2.
2. Identify product lifecycle
Yes 3. Identify phases, processes 4. Aligned to Reference model?
Decision to develop
ALM platform 1. Certification and/or mgmt framework in place?
No Yes
Yes 7. Way of working described?
Yes 8. Product lifecycle identifiable?
No
10. Describe No
9. Define 5. ALM Tool investigation No 6. Align product lifecycle to Reference model
2 Some of requirements are not shown due to space limitations. The second part of the methodology – ALM Tool investigation is based on the fact that all processes need tools in order to be executed; therefore it deals with the investigation of the technical means, which are mainly software application tools that support the execution of identified software product lifecycle. See Figure 4.
Completion of ALM Readiness check 1. Identify tools covering the product lifecycle 5. Identify not integrated tools 6. Are those from one vendor?
Yes
Yes 7. Can those be integrated? 8. Integrate according to tool vendor guidelines
No
No 2. Update product lifecycle descriptions 11. Investigate vendor tool change according to
OSLC and/or TASKTOP 12. Implement
tools 9. Update product lifecycle descriptions
No 3. All tools integrated ?
Yes 10. Integrate according to
OSLC and/or TASKTOP guidelines 4. Fit-gap analysis of tools to Reference requirements
End with fit-gap analysis results building practical specifications for integrating software. that produce software product manufacturing tools and applications for use by IT industry players. Emphasis is on the fact that ALM platform might be either one complete solution from one vendor like, for instance, IBM or it can consist of various tools made by various vendors. The key thing is to make them all work integrated, so they can be called the ALM platform. ALM Reference requirements representing the ALM Reference model can be considered as an instrument to verify the conformity of the tools that form the ALM platform to the proposed ALM Reference model. 5
For execution (partial) of the elaborated methodology, test organization is introduced
that has passed the first part of the methodology and has one vendor ALM platform
in-house. This way the second part of the methodology gets executed that deals with
the tools. Four participants were chosen according to Gartner [
Overall (Table 1) the highest score goes to IBM Rational and none of the platforms completely conforms to the proposed ALM Reference model. Tables 2 – 5 show scores for other blocks. Integration feature (Table 7) the highest score goes to Rally Software ALM. 6
Emphasis was put on looking at software products similarly as it is done in other areas, for example, car manufacturing. The reasons for this are to underline that the making process of software products is very much alike. Integration of tools and information flow becomes very crucial in this case. The elaborated methodology for building the ALM platform is model based, the latter being introduced also as part of the work. The reason for this is shortage of such models as shown by the research. Although this is an original work, the model itself is put together from already available information about the subject of software based products. The methodology itself consists of two parts – product lifecycle definition and lifecycle tool investigation. As our work shows, in majority of cases, ALM platforms are built on top of existing tools not obtained as out-of-box solutions. Nevertheless, testing the model and reference requirements on ALM platforms available on the market allowed us to conclude that none of those conform the model for 100%. The reasons behind this might still be very diverse interpretation of what is ALM by different vendors resulting into delivery of appropriate solutions as well as shortage of solid, industry accepted knowledge about ALM the same like it is about PLM.
Product profile There must be support for seeing general product information - name, status (idea, development, maintenance, ending), versions, lifespan and similar. Multiple products (portfolio) support is mandatory. There must be a centralized storage of product backlog. It must be possible to filter it, based on various criteria (proposed, approved, denied, etc.). Important attribute of each entry is its financial value.
There must be a way of describing product roadmap and product releases with names, dates and possibly other information.
It must be possible to validate idea of a new product. Approach like “Business model generation” can be used. This feature must allow modeling business value. It must be possible to validate any new release of an existing product similar to 2.1 and it also must be linked. This feature must allow modeling business value. 1 1.1 2 2.1
Idea validation 1.2
Product backlog 1.3
Product roadmap 2.2
Release validation
Release backlog Waterfall methodology support Iterative methodologies support UML and other diagramming for requirements definition Source control Programming language independence Depending on the method used, here must be a possibility to create subset of requirements from the product backlog according to product roadmap. It must be possible to run development projects according to waterfall method.
It must be possible to run development projects according to iterative methods.
It must be possible to complement requirements with diagrams in different notations.
Various types of source control must be supported by the platform.
This part of platform must also be vendor independent thus allowing performing work in variety of technologies (.NET, C/C++, Java) or it must be easily extensible to accommodate different frameworks.
Release management 5.2
Social media monitoring Analysis block must be social networking friendly. It 4.2
Production deployment 4.4
CRM
Connections There must be possibility to manage several releases of the product. It must be clearly visible in which state is each release. Besides, generation of release notes must be possible as well.
It must be possible to deploy the finished release into the production environment or mark the release as ready to manufacturing (RTM) in case of shippable/embeddable product.
It must be possible to use the same environment that is used for R&D also for handling support requests as well as perform CRM activities. This part of ALM platform must be integrated with ERP system of the enterprise or any other that holds customer/partner data. Analysis block of the solution must take data from other blocks around it. If there is no built-in Analytics sub-system, that supports integrated work of blocks 1-4, it must declare options on connectivity with other analytic solutions/enterprise systems. 5.3 5.4
Web data monitoring Existing data warehouses must be possible to search in public social media data according to keywords. Example of such solution is “Hoot Suite” It must be possible monitor and search information in public web according to keywords.