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
Explore other sections in this guide:
What should process-centric ALM suites do that they don't do today?
When we think about the SDLC process, we often think about it as being one, consistent, homogenous process. But in the real world, software development lifecycle processes vary widely. The SDLC for a mobile app is necessarily different from that for a back-end data processing system. If you're in health care, your tolerance for errors should be zero, but if you're in retail, time-to-market pressures may be more important than zero tolerance for errors.
App development teams must be able to interact with the development process from any device, anywhere.
When you set up your process-centric ALM infrastructure, be sure to define a workflow that meets your methodology (Agile to waterfall), your topology (mainframe to mobile), your technology (ALM suite to open source collection of tools) and your business needs (risk control, quality, time to market, governance). In addition, you need to define unique workflows on a project-by-project basis. For example, your business marketing needs may be mobile/social/cloud with requirements developed Wednesday and with the updated app expected in the stores by the weekend. HR systems are updated only once a year but because they impact your ERP and SCM systems, they need different processes operating at different speeds with different controls.
Of course the biggest SDLC process challenge facing us now is coordinating the deployment of these disparate technologies. Increasingly common is the need to make sure changes delivered to the Amazon/Apple/Google App Store are made and go live at the same time -- and that they go live with the website changes and the back-end server changes.
Add the complexity of consuming Web services from third parties and a development community spread across 33 time zones, and all of sudden we have 21st century style release management. Our process-centric ALM infrastructure must not only control this, but it must also facilitate the process. We must have deployment technologies that support the test environment for the continuous delivery teams. We also need deployment controls that embrace operational needs and time frames for production delivery.
ALM tools that enable social interaction about projects should be part of the solution too. For example, if you have a question about a requirement, it is good to see that the author is online. And it is useful to discover that the build engineer in Wellington knows exactly how to release apps like the one you're developing in Santiago.
Mobile is critical as well. App development teams must be able to interact with the development process from any device, anywhere. Whether that is getting notified of a critical error that's preventing the build from completion, selecting a task during the stand-up meeting, or approving changes to be released to UAT, developers must be able to carry out these tasks from their mobile devices.