Can You REALLY customize your backup reporting product?

Pretty much every backup reporting product claims their product is customizable (including us).   Let’s take a closer look at this. With each backup product, there is a set of reports that comes with it. These are often referred to as “canned reports” or “out-of-the-box-reports” where, once you’ve installed, you can start generating these reports.  These reports typically are bound to a pre-defined timeframe (i.e. last 24 hours, last week etc..) and represent a pre-defined target (all backup domains, a tape library, a backup server etc…).
 
So, when someone asks “can I customize reports”, what do they mean?  What are they expecting?  The classic definition of customization says it’s  “modification to meet individual needs”.  Well, individual needs will most likely eclipse the canned report set – by a lot.  That is, generating reports above and beyond what’s included in the canned report portfolio as well us introducing additional criteria on top of the pre-defined reports. 
 
Now that we’ve defined customization, how is it done? Here is an important checklist.
 

• Tell the vendor to remove “customizable” from their data sheet if all they can do is let you tweak the canned reports.
• Is there any custom reporting capability engineered directly into the UI? Can you pick any columns from the database and generate a chart? 
• Can you filter on any column, include/exclude, establish high/low limits?  A true customizable product exposes these directly through the UI.
• If no engineered customization capabilities exist and the vendor requires their own or sub-contracted professional services (PS) to come in and do it, be wary.  Obviously it’s extra $$. 
• If you have resources, ask them why they can’t do it.  Are they willing to share the SQL queries for the canned reports?  Even better, does the UI or the logs expose the SQL from the canned reports?  These are a good learning tool and accelerate your learning curve of the data schema.
• For those that let you do custom SQL, will you have unfettered access to the database or is it a limited set of database views?  If the latter, this could well point to a design that is sub-optimal and certainly not intuitive.    
• Once custom reports are developed, do they operate within the framework of the product? How integrated are they with the utilitarian functions such as scheduling, exporting and emailing?  Will your end-users see these reports in the same package as the canned reports?
• When it’s time to upgrade to the next release, will the customization naturally follow-through?  Does the upgrade break the customization? For the vendors that send in their PS to customize, will they own up to issues during upgrade or will they require more PS (and more $$). 
• Customization also means bringing additional data into product (Ex – cost center info for charging back).  Is there an API through which this  can be done? Will the data model support such an import or new tables need to be custom built to store this?  Will existing reporting interfaces expose this data or yet additional reports need to be created just to expose them?  Last but not least, what happens to this data during an upgrade?  Is further development required (and more $$) after the upgrade to bring this data over or does the upgrade transparently handle this - which clearly points to a design with customization in mind.

Keep these in mind when evaluating competing products.  Don’t be misled by the base product licensing costs.  Like most, you’ll require some degree of customization and you should think about the total cost to deliver on your requirements. Your investment demands how efficiently, effectively and transparently customization is handled.