Tag Archives: DB2
There were two recent events that inspired me to write this blog entry. The first was an Informatica Users’ Group meeting where I was invited to speak about Informatica’s new offerings in the data replication space. Like many of my presentations I like to begin by asking the audience to share their exposure to replication technologies, how they are using it, how it is working for them, etc. After quizzing this particular audience I was astounded by the number of customers that were writing their own extraction routines to pull data from various data sources, it was over 80% of the audience. I started to ponder this concept as I delivered my presentation and tried to point out specific areas where building might not be as effective as buying.
The second event was the Saturday after the Users’ Group meeting. I had taken the family to Disneyland and my daughter wanted to visit Build-a-Bear. Now I ask you, how can any doting father refuse a 10-year old’s plea for the “The most special bear in the whole world, I’ll name him Daddy Bear”. Yeah I know, I should have “Sucker” plastered on my forehead. However, as I was going through the process of building this special bear with my daughter, I started to consider correlations on how this might pertain to building a replication technology verses buying one. The amount of staff is what first caught my attention, someone to help pick through the inventory of choices, someone to help pick a heart, a customized sound, a stuffing station, there was someone to assist in picking out accessories and clothes, I mean after all you can’t have a naked bear. Of course no bear is complete without being a member of the “hug club”. After all of this specialization was complete I ended up with a great memory and a bill in excess of $90.00.
I started to consider the issues the customer group faced when attempting to build their own extraction routines. Most had a variety of database sources, Oracle, DB2, MS SQL, etc. Each required a different person with different skill sets to write the extraction routines. Given the resources this could vary from database to database and even department to department. I’m thinking the hidden cost of staffing this exercise is probably overlooked by upper management.
There also didn’t seem to be a common approach to how the extraction process is maintained. After further analysis most elected to extract the data was through Triggers or using SQL Select routines. OUCH, that is a pretty intrusive approach to pulling the data out of any source environment. I’m thinking a membership to the “hug club” might be in order once the overhead requirements are analyzed. But there is a distinct reason for this choice; it is straight forward and easier to troubleshoot.
Why? Because Build-a-Bear can quickly train new staff members on how to work each station, but specialized IT personal are harder to come by, and they come and go from organizations all the time. Writing a customized routine for extracting data might provide job security, but it might also paralyze an organization if errors are encountered after an upgrade, or change to the environment. Delays can be exacerbated if the author of the code has moved on and no longer works for the organization.
This topic has intrigued me and before I closed the presentation I inquired if anyone would be willing to participate in an ROI study to validate whether building verses buying would make sense in their organization. I had several willing candidates. Over the next several months I invite you to follow along with my blog series on this subject. I intend to document my findings and share it with a wider audience that might be considering an investment in a replication technology verses building your own.
For those of you who will be attending Informatica World, I’d like to invite you to join me at the Demo Booths and Hands on Labs. I’ll be there all week and would love the opportunity to meet with you in person.