Sticky ToolLook: What are some of the obstacles organizations encounter when deliberating about whether or not to incorporate an application lifecycle management (ALM) solution? What do you suggest to these organizations?
Matthew Klassen: There are several common obstacles as organizations deliberate about investing in ALM. The following are the issues most often cited:
- They are not sure that an ALM solution will provide enough value to the organization to warrant the investment. I recommend that organizations evaluate the total value as well as the cost of ownership over a multi-year period. Gartner suggests that a good ALM solution should provide benefit in productivity, quality, auditability, predictability, and agility. Any reputable ALM vendor should propose a solution that includes clearly defined objectives (issues being solved and improvements), a phased plan to get there, the value of achieving those objectives, and a framework to measure progress towards those goals.
- They have existing tools in place and are concerned about replacing them because of the amount of investment they have in them, political reasons, or simply the pain of change. I suggest that these organizations first assess their overall capability in software development across the ALM spectrum and, as part of that, assess the value of these existing tools. Once they understand what is working and what is not, they can better assess where to begin. Implementing ALM is not an overnight process, and many times there are other areas of improvement that could provide more value. In addition, they should look to a solution that will integrate and adapt to some existing tools and process that are truly lending value to the organization.
- They have organizational constraints that are unique to their organization and they feel will impede their ability to successfully deploy a "generic" ALM solution. These concerns range from regulatory concerns to industry-specific processes. I recommend as they look at potential ALM solutions--that they evaluate not only the vendor's tool or platform capabilities, but also the vendor's approach to assessing needs and tailoring the solution to adapt to their specific organization. It is also helpful if the vendor can give references of similar organizations and the solutions that worked for them.
- One group within the organization (PMO, business analysts, QA, developers/engineers, etc.) is motivated to make the change without getting the buy-in of the rest of the group. This one is tricky, because although there might be more value to the organization to adopt an ALM solution, many times, the interested organization does not have the power to actually put one in place. So, many times, it makes sense for the interested group to put in place a solution that serves their needs and has the potential to serve the needs of the other groups in the future.
STL: What differentiates what MKS refers to as "Intelligent ALM" from what most people think of as ALM?
MK: Intelligent ALM builds on the common notion of ALM and the analyst definitions of ALM. It moves beyond a competent set of integrated tools that cover the breadth of the disciplines of ALM and passes the notion of a coherent platform where artifacts are linked, workflow is automated, and cross-ALM visibility allows for better management and ultimately improved project outcomes. Intelligent ALM encompasses those qualities and mixes in the notion of adaptability, such that a coherent and competent ALM solution can adapt to highly varied enterprise environments (platforms, technologies, processes, etc.), scale to the enterprise beyond a single project or division, and maybe most importantly connect software development with business processes, business stakeholders, and business problems to truly impact the business.
STL: What does it offer to business analysts?
MK: It offers the business analyst the opportunity to influence the entire team, providing clear direction for all roles. It allows the business analyst to focus the team's attention on solving the business problems and satisfying business stakeholders' needs. Intelligent ALM can uniquely provide this for two reasons:
- MKS Integrity provides requirements management (RM) capabilities as part of a holistic ALM offering that connects requirements to all relevant artifacts, automates RM workflow as part of the development process, and provides transparency through comprehensive metrics. This allows the business analyst to spend much less time manually ensuring traceability, generating status reports and metrics, and guiding the process and more time solving business problems.
- Intelligent ALM goes beyond a technological platform to an approach of working with customers to improve their ability to solve business problems with software. By helping turn the focus from simply the software's being produced to connecting software development with core business processes, business analysts' work will be much more impactful to the business.
STL: What does Intelligent ALM offer to those in individual areas of the lifecycle, such as developers or testers?
MK: Intelligent ALM allows each role to maximize its contribution to the team and ultimately the team's impact on the organization by:
- Providing competence-managing requirements, test, and development activities and artifacts
- Providing this competence in a single, coherent platform so artifacts, processes, and roles are inextricably linked
- Adapting the solution to each team's unique needs in supporting platform, technology, IDE, team size, process (agile, iterative, waterfall, mixed), and distribution (collocated or globally distributed)
- Elevating the visibility of the team's project and deliverables to the enterprise, connecting the team's objectives to corporate objectives that move the business forward
STL: What are the difficulties and benefits involved with elevating visibility and connecting team and corporate objectives?
MK: There are several difficulties in doing so, including:
- The software development group has not typically spent time collaborating with these other groups, and this, many times, can be a cultural barrier more than a technical barrier.
- The other groups (such as systems engineering or IT operations and support) see software as a necessary evil almost and an inferior science. They have strict controls and engineering practices and don't understand why software development can't get their act together. This creates a difficult situation. It seems to be changing, as it is impossible to ignore the criticality and strategic role of software.
- Technical barriers exist, as most ALM solutions don't actually integrate well with IT operations or PLM solutions.
If the these teams, processes, and tools can be connected, it really adds significant benefit to the business as a whole, such as:
- True end-to-end visibility and control across core processes, including IT change management (ITIL/ITSM), eliminate the software development black box and allow management to actually manage costs, quality, and schedules much more predictably (similar for PLM and engineering processes).
- It naturally brings down costs and improves quality as waste is eliminated from the organization. Disconnected teams, processes, tools, and data create waste and cost millions each year.
- If these processes and tools are connected, it really gives business stakeholders better transparency into the delivery of systems and will have a positive effect on customer satisfaction and retention.
STL: What issues do you see in existing all-in-one ALM solutions, and what improvements do you expect to appear in coming years?
MK: Right now there are four core issues with all-in-one solutions:
- The major contenders in this single platform space are not very adaptable and are quite proprietary with few exceptions.
- Integrating with the existing tooling and process in place within an organization still is a concern. Some innovative vendors are able to combat this with more adaptable integration schemes, but that is not the norm.
- Incomplete functionality is another issue with some of the major players in the single platform space. Some do well at test and maybe OK at requirements, but fail to support change and configuration management. Others support change management, but really have light functionality in requirements and test management.
- Finally, many of these solutions fail to really scale to the enterprise level in terms of users and data volume and even post limits on their Web sites.
