Greetings once again, folks! I've realized that while a lot of you can go and quickly look up code snippets and watch tutorials on different technologies, there are some aspects of development that you can't get without living it first-this is also a true statement about life, love and cooking, but i digress... :)

One of those concepts is ALM. A lot of you out there are probably applying it to your work environments, or maybe studying it for the first time-it's a very large concept to grasp and how it works varies from one method and company to the other. While it can be an overwhelming task to learn, there are for the most part some very basic concepts to it. As this blog is dedicated to getting you confident enough to start talking about developer concepts and technologies, I've decided to introduce the concept of ALM to help you understand the basics of it. But first, we must start at the beginning...

 

What the heck is ALM?

ALM stands for Application Lifecycle Management, and it's the cycle of steps an application goes through from that "ah-ha!" light bulb idea over someone's head to developing, realeasing and updating it until the app is no longer used (called End of Life). While it sounds like a largely programming-focused procces, development is only one part of it. ALM in reality is a combination of the development team and the business working together to achieve a successful application. While there are a lot of different methodologies and ways to practice ALM, you could say they follow a general set stages and processes. I like to think David Chappell begins explaining that really well here.

According to Chappell, there are three processes that are involved in ALM:

Governance-This part of ALM is dedicated to making sure that the applicaiton, from the moment it's thought up of to its end of life, meets the needs of the business. This doesn't just happen as the app is being created-it goes on all through the lifecycle.

Development-Mostly occuring in the time between the idea generation and first release of the application, this is when the app gets coded and tested. This also involves updates to the app, which can be very small to rather large.

Operation-Right up to before and going on after the app is released, this involves maintaining the application-monituring its performance, managing update releases, etc.

 

Within these three processes, ALM can be broken down into different steps as the app goes from idea to reality:

Gathering Requirements, Specifications, and Envisioning- Here, you or your dev team talk with each other or the business you're creating your app for, and gather all the specifications your user wants from your final product.

Architecting the application-While this stage varies based on the size of your app, this is the phase where you decide the technologies you're going to be using in your application, and how they'll be talking to each other.

Development-Now, we get cracking. The dev team will now get to work on developing the application, usually in some form of a series of cycles, where each cycle is a part of the whole application

Testing-While this part should be tightly integrated with the development phase, it is typically represented in its own. Usually in each cycle, you'll create tests for your application to make sure it's running smoothly and won't break. If there is something wrong with it, it goes back to the dev team to fix it.

Deployment and updating-Now that your shiny new app is ready to go, in this phase you deploy it and continue to get feedback from the users on how the app can be improved upon in later versions.

You can read a little more about ALM overall here (ALM wiki page) and as we go through ALM feel free to refer back to it.

Now that we pretty much know the basics of ALM, we'll be learning about each phase-and maybe some in-between-in different posts in a series. Next post, we'll start at gathering requirements and envisioning. Stay tuned!