First I wish to all of you a really Happy New Year! I hope that 2011 can be the best year ever to all of us!
Second, sorry, sorry and sorry. We “abandoned” our blog this last few weeks. I got a lot of new responsibilities on my formal job and Dev was in vacation with his family. We are going to try to be more present from now forward.
Third (and last) let’s talk about scenarios!
I created this title “Scenarios, a lot in the first delivery makes maintenance very simple!” in the hope of a full understanding about what this post is in just one phrase once I would like that after we finish to discuss it you can tell me if the title is right or not…
I Oracle Data Integrator, our famous ODI, is very common to develop all objects that you need to your integration and, at end of the development, add all of these at a package, create a scenario and that is it. Test and go to production.
That is the common way in all ODI environments that I saw until today… let’s discuss this.
When we are developing a it’s normal to have several tables to load in some order (parents, children, etc), procedures to performs some “not interfaceble” task and variables that uses code (refreshing type). Then, all we do is add all of this in a package, generate de scenario and our development is done.
OK, now let’s think about it from the Software Development Life Cycle (SDLC) perspective, I mean, everything that is developed will get some maintenance in one of his “pieces” some day.
As we change just one piece from all our package, of course we should test just that piece right?
NO! And here is the problem!
Who can guarantee that none of the others pieces (or ODI objects) was changed? In fact, using a trusted SDLC, you need to execute the complete test plan (the same that allows the first delivery) once all code was “compiled”, I mean, regenerated (in ODI terms).
Do you agree?
And if we split the development in small pieces of scenarios, as small as possible, even at object level (as we can generate scenarios from objects ) and then create a package (or packages) that orchestrate the execution of this small pieces????
Of course that the first delivery will have a lot of scenarios to be imported at production but when some change is necessary you can update only the relevant code and, too, test only it.
In this way your SDLC will get less errors and the cost (HR, Financial, Hardware, etc) of tests will decrease substantially and plus, you can always re-use any of the object scenario.
If you pay attention, you will see that we are talking about the old concept of Object Orientation, nothing new.
And now, what do you think? Is the title right? 🙂
A tip to use this approach is to have the Operator (scenarios tab) organized in folders. This will avoid the endless list of scenarios and brings organization to the environment.
Well friends, that’s all for now. I hope you keep traking us!
Once again, Happy 2011!!!!