I have to admit: I'm badly placed to write this post, but I have to.
When at university I learned the concept of "Make or Buy". You weigh the cost and benefits of developing something yourself against the cost of buying it.
Depending on the outcome you do one or the other.
Doing your homework
When presenting our Life Cycle Management solution for ODI, it sometimes happens that the ODI team likes it but that some operations people say: "Yes but we have already a company wide LCM framework let us use that. Thank you and goodbye."
When you talk to the ODI people after some months they have to admit there still isn't anything there!
What I am trying to say is that, yes do that exercise, but be fair.
Building your own Life Cycle solution might look simple, but if you take everything into account, especially the ODI dependencies challenges it isn't that simple.
Actually, I just met a customer who developed his own versioning solution for ODI 11 but is now facing the challenge to do the same for ODI 12.1 and ODI 12.2.
Yes, developing something for the first time can be fun and may actually work, but:
- What when there are new releases to support?
- What is the cost of maintenance and upgrading?
So, the lesson they learned is: do your homework!
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!