Lessons Learned: Life Cycle Management, what is it?

During a recent conversation with a prospect it happened again: Oracle ODI 12 has now a Life Cycle Management solution. End of story.

Luckily an Oracle employee took part in the discussion and admitted that ODI 12 had now versioning and that indeed versioning is just one part of Life Cycle Management.

I admit and know that you and many others are confused  when Life Cycle Management (LCM) or Application Life Cycle Management (ALM) or DEVOPS is brought to the table. Or when vendors like Atlassian with JIRA or HP with HPALM are being seen by customers to offer full ALM capabilities.

When we ask you the question “do you know what LCM or ALM is?” we sometimes get the answer yes and we have it as we have JIRA or HP ALM. Well LCM or ALM is more than issue tracking or testing.

Simply said LCM or ALM starts with business requirements, process and information modeling,  development (dev, version and build), quality assurance (testing) and production.

ALM is more than issue tracking or testing

Proper ALM covers all these steps and makes sure that each stakeholder (be it an architect, developer, tester or operations engineer) can stay in his comfort zone, but gets the results of the work of the other stakeholders in such a way he can do his job without having to ask a lot of questions or doing it again and again. In other words it starts with a good overall process definition and in the best of worlds this process is automated in such a way it is reliable, repeatable and fully documented.

Good LCM or ALM will make your cycles shorter, give a better quality and will give you a faster time to market. Is there a silver bullet: I don’t think. Of course you need to standardize as much as possible, but specific environments can demand specific solutions.

Let’s take ODI: do you think versioning ODI objects is just a question of committing an export to SVN or GIT? Or could it be more complex? What about restore? All objects or do you want to handle Topologies separately? What about dependencies? Do you want a full restore of a Repository or just a deploy if the latest changes?

My take away: make sure you know what your current state is (WHAT IS) and what you want to achieve (TO BE). Make sure all stakeholders are involved, not just developers. Based on you WHAT is and TO BE you can start your journey, be it for implementing an LCM or ALM solution or just another project.

Picture of Rene De Vleeschauwer

About the author

Hello, my name is René De Vleeschauwer.

Throughout my career I've been responsible for the development of enterprise software. Since 12 years I've been leading the development of IKAN ALM, an open DevOps framework.

Do you have any questions about this post? Just ask me!

Get free insight!

Let's analyze your current development and release process, and show you how to make it much faster and 100% reliable.

Yes, I want insight

Do you want to recieve the latest news and updates?