The concept of application lifecycle management (ALM) comprises process, tools and people. For ALM-focused organizations, the process and tools won't eliminate or radically change the roles of people, but the silos will start to disappear and there will be some subtle and some not too subtle changes to jobs, industry experts say.
Clementino de Mendonça, manager, national solution lead, ALM, at global consulting firm Sogeti, helps clients do ALM assessments, including personnel. What many have in common, he said, is that, "most companies don't have a concept of a release management team. They tend to think of release management only as operations, or that it doesn't involve configuration management, nor builds, nor mergers. Release management from a best-practice perspective is the process of software release, from requirements to production."
Clearly, that cycle involves everyone on the ALM team and it will have some impact on traditional roles. Steve Porter, technical director of consulting at Wintellect, a consulting and training company based in Knoxville, Tenn. said that to some degree ALM is "more of the same, but what will stay most familiar to people is development," he said. While they may have changes in their process, and will need to work more collaboratively with cross-functional teams, "at the end of the day it's still development."
Other roles will be impacted more. Here's a look at what some industry experts suggest:
"For us, the PMP [project management professional] is much more muted," Porter said. "It's still valuable, but it's not a huge part of the project because of a self-managing team [with agile], or a cooperative effort with QA taking a piece, development taking piece, and a little bit of management oversight. You will always need some oversight/governance to make sure [a project] is moving in the right direction."
The title of "project manager" may change over time, said Theresa Lanowitz, founder of market analyst firm voke inc., based in Minden, Nev., "but the project manager will still be important. You have to have somebody who understands the overarching schedule and goals, and can negotiate trade-offs between functional teams and help them understand the trade-offs. The role of project manager will become more like we see with the program manager or product manager in a commercial software company. They will make and present trade-offs in an analytical way, and explain it to the business in business terms."
IBM's Rolf Nelson, Rational Team Concert product manager, said some traditional PM roles are changing because organizations that are trying to deliver in shorter iterations "can't afford a top-down planning module, it's too time consuming. Teams are taking more ownership over project schedules and feature set and backlog."
With the advent of ALM, Lanowitz said the role of the business analyst is becoming very prevalent. The BA, she said, "needs to be analogous to what we see as a product manager inside commercial software companies. What enterprises are moving to is the realization that they're producing a 'product' for the line of business."
BAs, who are largely in charge of requirements and getting those requirements into a usable form, "have to be given a seat at the table with respect to application lifecycle," she continued. "The BA has to be as respected as the developer and tester are, and those requirements have to be respected as well."
Lanowitz said that is where the thinking is going today, and that in a few years organizations will have figured out how to better include the BAs, and there will be better tools for the BAs.
While it may be just semantics, Porter said he has stopped using the term BA in favor of SME (subject matter expert). "To me, there is not a benefit to a pure BA until you get to pretty large project sizes."
An SME may be someone from the client's organization or someone on the team itself, Porter explained, but the subtle difference he sees is that an SME is more of a resource versus "a documentation engine. When someone thinks BA, they think of listing business requirements and writing documentation." Particularly for agile organizations, all that documentation is not necessary or wanted, he said. Moreover, with agile, he said, "everyone does requirements, everyone works on planning."
IBM's Nelson said a BA connects business value to what is being delivered, and that's a key role, whether it takes the form of BA or PM or managing an agile backlog. "There are people who need to own the business view of what you're trying to achieve, and collaborate and communicate around that business value," he said.
Architects, which in the past few years have gained a more advanced role, will start to play an even more important role in an ALM-focused organization, Lanowitz said. The role of architect involves "taking a look at how the different applications in an organization are playing together, or asking, 'Can we reuse a portion of code from application A to application B?' That may have been absent in years past, but we have solutions now for architects to do that kind of analysis, so the role has been increased. And as we see more emphasis put on security and performance, that architecture role will be more important."
For QA and testing, their roles will have the biggest change, Porter said, particularly if the organization is using an agile methodology. "It's a complete shift from what most QA organizations used to do," he said. "They used a list of things to click through after the application was complete to make sure it worked. That really got turned on its head with the agile process with QA involved from the get-go, driving the process as much as development, helping developers write tests; iterating on tests just like developers are iterating. I see that as the most different; with project management coming in a close second."
Lanowitz said with ALM, QA has "a full seat at the table, being part and parcel of what [the team is] doing. Testing is built into the schedule from the beginning. Enhanced communication and collaboration is first and foremost, with groups really operating as an organization to deliver one common final goal—ship a good piece of software that everyone can use, and is what the business wants and needs."
Sogeti's de Mendonça suggested a new role for ALM-focused organizations: ALM specialist. "Ideally, you have an ALM specialist doing an ALM assessment every six months," he said. That person, he said, has an overall knowledge of ALM and works to improve the process. "Before [organizations] had a sequential program for improvement. Now an ALM specialist applies scrum/lean/Kanban techniques to look for bottlenecks in the process, so you bring in a specialist to improve the bottlenecks," he said.
Porter said in the scrum world people might liken a scrum master to what de Mendonça calls an ALM manager. The scrum master "is the person in charge of making sure everyone adheres to the process," Porter said. "That will change depending on the process; if you're doing a strict CMMI/waterfall process, it is necessary in some regards that you will have a PM that walks you down—this is next, this is next." He added, "No matter what the methodology, someone has to look over entire project or it will never get done."
As organizations more fully embrace ALM, line of business and IT will continue to become more aligned, Lanowitz said. As such, she said there will be new constituents added to the team along the way. Today, the tester is the newest role at the table, gaining full parity with development, and she said business analyst and designer are gaining ground. "As the lifecycle continues to evolve, everyone comes together to deliver better software."