The resulting debate and discussion highlights some key areas that application development professionals should look to when building their ALM strategy.
Who owns the code?
The reality of open source, partner-developed code and vendor value add-ins was not lost on the group. The overarching theme from this discussion was that customer organizations not only need to own the overall supply chain but also are responsible for ensuring its quality. That means, as writing code decreases, inspection, validation, and testing increase.
The result is that traceability, workflow, and reporting are inclusive of customer code but also supplier code. For example, defects with an open source project need to be captured, shared, and tracked in a similar way to internal defects. The difference is that, unlike with internal development, those defects will also feature in the open source project and be fixed by people outside of the customer's organization.
The implication of licenses and IP ownership was discussed, with one in the group painting a very bleak picture. He described a scenario where because of the result of one massive IP infringement a company is forced to stop operating, with the resulting fallout being a massive, wholesale movement away from open source software and associated complex IP and licensing issues. Though this example was extreme, the group agreed that licensing should be part of the governance for any ALM solution. This increased complexity of code ownership will require ALM solutions to:
* Track defects/issues that are outside of the customer organization, ensuring that externally owned worked is clearly tracked and reported on.
* Increase the importance of inspection, validation, and testing, perhaps with the advent of external code being provided with testing materials to enable effective regression testing.
* Require integration of status and information into development dashboards. A different type of work item that is actually a proxy for external work needs to be included in the dashboard.
Business will require even faster delivery
As one member of the group stated: "If the last two years are indicative of the next five, we will have to deliver software faster and faster. Maybe even before the business has thought of it." The need to deliver business capabilities at great speed is the reality. As software becomes increasingly important to the overall value of the business, it moves from supporting the processes to becoming the processes.
The result is that the short-term needs of the business translate into short-term requirements of the systems. Time lags, invisible queues, and process latency will have no place in the modern application lifecycle. This requires ALM solutions to:
* Be part of a broader business capability supply chain, inclusive of operations, customer relationship management, product management, and other business-driven processes.
* Automate EVERYTHING that can be automated. Whether it is creating test environments and testing applications or deploying new software to the field, processes need to be increasingly automated and optimized.
* Exploit new process models such as Agile. Breaking the problem down into smaller increments, engaging with the business on those increments, and re-planning after each increment has been delivered enables increased business agility and increases development cadence.
Security, security, and more security
Perhaps because of more-complex supply chains or the advent of cloud-based delivery models, the group highlighted that security of both development assets and the delivered security of the applications will increasingly be the responsibility of ALM. Not only will this require more-robust testing environments including a real mirror of production (an area that the majority of the group agreed was sadly lacking from their own environment) but also the management of security requirements, policy, and known problems in a way that is similar to how software vendors manage their assets. It also will require more frequent security patch releases for application code. The result for application lifecycle management is:
* Security testing tools become a natural part of the ALM stack. Security testing is often considered to be outside of the normal developer or system testing arena, but as the importance of building robust applications increases, security moves down the supply chain to be handled earlier.
* Capturing security issues, bugs, and resolutions in ALM tools. By treating security the same way as both requirements and architecture, application pros can better manage and report the true "security" status of the application.
* Being able to deploy security changes faster. It seems that release speed is relevant not just to the code but also to the architecture; software needs to be structured a way that enables more-flexible deployments, including security patches.
There were many other areas that the group discussed, including skills, outsourcing, compliance, mobile, mixed platforms, cross-functional teams, and end user development, all of which could be included in this blog, but I picked the top topics Would love to hear your vision for ALM in 2016...