If you've been involved with software development or IT administration for any period of time, then you've probably heard of ALM, or Application Lifecycle Management. However, the last few years have seen the rise of "DevOps" as the buzzword of the day. But what's the difference between the two? Is there a difference at all, or is this just another geeky holy war? And what about SDLC, or Software Development Lifecycle, the hot acronym from yesteryear.
A good place to start the discussion is to take a peek at some posts from Donovan Brown, DevOps Program Manager at Microsoft:
Go ahead and take a minute to read these brief posts.. I’ll wait.
With that background in hand, let's talk about SDLC first. This has been a concept for some years. The whole idea of lifecycle management arose because of the chaos that software development used to be. We've all been there… development projects over budget, over time, and under delivered. Death marches to meet a date. The exponential uncertainty of trying to predict future effort though a parade of scope decisions.
Well-planned SDLC was meant to rein in IT projects, make them predictable, and deliver greater value. Originally, "SDLC" typically just meant the good old waterfall approach that so many of us remember. As time went by, Agile flavors like Scrum became the most popular approach for many well-known reasons. Life was good.
Or was it? If life is so good, why do we need DevOps now? And what is it, anyway?
Whereas SDLC is mostly concerned with the process of writing software, DevOps bridges the gap between software creation and its use, with particular focus on the steps to get software built and deployed. Ideas like continuous integration and deployment or release management are generally considered "DevOps" ideas. As Donovan so succinctly put it, DevOps is about delivering value. In other words, it puts the value of a development effort in the hands of those who can make use of it.
The lines between SDLC and DevOps blur a little in the middle of the process when talking about activities such as building and testing, but, generally, SDLC connotes to the earlier parts of the lifecycle like requirements elicitation, design, and development and DevOps to the later ones like deploying the build to production.
Of course, you could argue that operational concerns are part of the "lifecycle" of an application and thus should be part of SDLC. You could also argue that writing code is the "Dev" in DevOps. At the end of the day, though, it's best to consider these two concepts in terms of their spirit rather than seeking (as we engineers want to do) a definitive classification.
DevOps, then, is just a convenient way to express to someone that you are talking about the later parts of the lifecycle. SDLC, on the other hand, is increasingly shorthand that refers to earlier parts of the lifecycle, where the actual software is designed and written.
That covers SDLC and DevOps, but what about ALM?
Think of ALM as the broad, encompassing idea that includes the others. ALM is everything from birth to death of a product. As such, both SDLC and DevOps are a part of ALM. In addition, activities like portfolio management and the service desk are part of ALM but not necessarily of the SDLC or DevOps of a product.
And, to minimize confusion, most groups and vendors are simply using combinations of terms to refer to the entire process, as in ALM / DevOps, even though ALM is not synonymous with DevOps as discussed above. Indeed, we have adopted the broadest of these concepts right in our name - the ALM Rangers!
But where does the idea of agile development fit into all this? Simply, agile methodologies like scrum are an implementation of the SDLC and, by extension, ALM. In fact, frank discussions with some working teams reveal that those teams are, in fact, using agile methodologies (and using them well!) but without worrying about a particular terminology, which uncovers both the power of agile process, since it was adopted naturally as the best way to get work done, and the acronym confusion around these terms in our industry.
In summary, the proliferation of various process terminologies has muddied the thoughts of many professionals. Worse, their inconsistent use by pros and by vendors' marketing has generated a lot of confusion. By speaking with experts such as Donovan Brown and providing a simple classification of the relationships between each concept, we hope to start the industry on the path to more consistent and meaningful use of each idea.
Share Your Feedback
Weigh in on the debate below - what are your thoughts?