Build or buy? This question runs to the core of almost every major software purchase considered today. Should I try to find an existing application out there that does most of what I need done (with the risks of customization) or build something from scratch with core components (with the risks of multiple product integration)? Unfortunately, this article doesn't provide the answer to this timeless question. There's a new breed of "buy" products coming out that offer great promise to revolutionize how business analytics are performed; but the new sellers of these "buy" applications are some of the same companies that once insisted that the reason you should buy their ("build") product was to avoid the hassles of customization. The sales shoe is coming down on the other foot now, so let the buyer beware. While a packaged analytic solution may very well fit your needs, you should buy with an understanding of the risks you may face in implementation.

The Definition

First, let's define what we mean by a packaged analytic application (PAA). The PAA consists of a predefined and pre- integrated set of software components (usually separate commercially available standard software) designed to answer a specific set of business analysis questions. You could also think of a PAA as a "data mart in a box." When you buy the package, you receive a data model; an extract, transform and load (ETL) process designed to populate this data model (likely including a limited- use license for an ETL product); reports (again likely including a limited-use license for a reporting or business intelligence product) designed from this data model; and hopefully a very complete set of documentation explaining it all. Common PAAs on the market today include packages for Web site/clickstream analysis, supply chain analysis, customer relationship management analysis, manufacturing analysis, purchasing analysis, and so forth.

The Dream

Objectively, PAAs exist to fill a real need among customers. If, for example, you need complex clickstream analysis for your Web site and what you require isn't available from a shrink-wrapped product found at your local software retailer, then a packaged application offers significant appeal. Using enterprise-class database, ETL and reporting platforms, you quickly move beyond what a simple PC-based tool can offer in terms of scalability, flexibility and customization. Also, you already may have in-house standard tools for each of the major components (database, ETL, reporting) complete with trained developers, server platforms, etc. These applications sound very appealing when the respective software vendor representative comes to call showing his or her new wares.

The promise is seductive – install "industry standard" components, click a few places to customize, and you're up and running. Right?

The Reality

Well, not quite. You should take some time to really kick the tires before jumping at the first tool that appears to offer you something you need. Do you really have a defined set of requirements for what you want from the solution? What business questions are you trying to answer, and how well does this tool match these needs?

You should first ensure that you completely understand the product architecture. How, exactly, do the "integrated" components integrate? Do they sit cleanly on top of your existing software installation (if you are looking for tools from a vendor from whom you already have product) or do they require a standalone server? What database platform is the PAA natively written to support? Even in cases where the tool architecture closely matches your existing infrastructure, you may very well discover that the PAA version is tuned for a slightly different database version or incorporates a newer version of a reporting package than the one you currently use. These hassles may prove inconsequential compared with the value a tool can offer, but you should at least go into the project aware of what lies ahead. The distance you find yourself from the "standard" architecture should indicate the relative level of pain to be expected with the implementation.

How to Decide?

Three key factors can help you determine whether the PAA provides solid value for your needs:

Flexibility of toolset. You first need to evaluate the flexibility of the PAA toolset related to your operating environment. Do you incur any restrictions on frequency of data load? Will your PAA be expected to function in a near real-time environment or is it designed for batch updates? What if you don't use the exact architecture (e.g., a different database, ETL product or reporting package) provided with the packaged solution? Can any of these components be unbundled from the application design and still provide a functional system? Can the vendor describe nearly exactly the places where changes are required to support specific platform changes? One example is the supported database. If the PAA is developed for Oracle, can the PAA vendor state with certainty what functions in the ETL or reporting components need to be modified to support a DB2 (or Sybase, Informix, SQL Server, etc.) installation? Likewise, if the PAA report set is in a particular business intelligence (BI) tool unfamiliar to your staff, does the PAA vendor provide any migration support or assist in the connection of the PAA report set to your existing reporting environment?

Degree of customization allowed/needed. Each PAA design also comes packaged with certain assumptions about the source systems used to populate the PAA schema, as well as what you intend to do with the source data once loaded to the database. Flexibility to modify the design of the PAA thus serves as an important characteristic of any application. You can expect to require some customization in three areas – database, ETL and reporting.

For the database design, above all else you must review the data schema for two critical factors. First, is the schema designed at the same granularity as your source data? While this may seem a simple requirement, as a warehousing professional you know that determining the correct design granularity either makes or breaks your warehouse application. The same is true for PAAs. If you are in the financial services industry and want to have data at an account level but the PAA is designed for customer-level summaries only, then you have a problem not likely to be easily overcome from the initial installation. Similarly, in the telecom industry you may want call detail-level summary, but the PAA might only allow account-level summarizations. If the tool only provides for daily activity summaries but you require hourly detail, can this be resolved? As extreme as these examples may sound, they represent the nature of a data granularity problem; and you must know of these issues prior to purchasing the PAA.

As a second database concern, you may want to add references to existing data warehouse dimensions or user-defined fields not included in the standard PAA schema. How easily does the PAA design incorporate your changes? Does the PAA define specific fields for you to use in enhancing the application without risking a modification that "breaks" during the next upgrade of the application? Users of ERP systems have certainly encountered this problem when the millions of dollars of customization code written to optimize the application for their business essentially rendered the application impossible to upgrade without incurring millions more dollars to upgrade the customizations as well. Learn from history and ensure you avoid this mistake. Note here that in no way do I suggest that you not customize the application, only that you carefully review the PAA vendor's design methodology and understand where the danger points of customization lie within the PAA design. Most PAA vendors allow user- defined fields and encourage you not to make other changes to the database schema, for example; however, not all vendors can clearly explain exactly where in the ETL design process used to populate these custom fields you should or should not add customization to avoid conflicts with future product releases.

As noted, the ETL design may require customization to adapt such things as mundane as a different incoming source date format, provide lookups to handle special case values in the source data, etc. As such, you need to ensure that your developers are comfortable working with the ETL components used in the PAA and that the PAA vendor provides clear and explicit documentation regarding the assumptions behind each of the ETL steps. For example, if you are processing clickstream information through a PAA tool, has the vendor assumed the URL strings include the leading string or not? Where would you find this and make a change to accommodate your actual input data format? How would any changes impact the reporting or other aggregations generated by the tool? As you know from the implementation of your existing data marts, ETL represents the most complex phase of the project, so don't assume it's all magically simplified by the shrink-wrap around the PAA product.

Finally, you will want and need to customize the standard reports provided by the PAA design in response to the needs of your user community. Knowing this, how comfortable and skilled are your developers in working with the specific reporting/BI tool provided with the PAA? Does the PAA vendor provide documentation regarding why and how the reports are designed, or do they leave it to you to "discover" by dissecting the reports after you've installed the products? Vendors will tell you that they have discovered the magic report metrics used by the targeted vertical to which they are selling the PAA. Ensure you review their metric definitions (the actual formulas or calculations) before you purchase the tool to guarantee that someone else's magic definition of customer churn matches your own.

Prove the ROI. Most fundamental to the purchase decision is whether the PAA will truly pay for itself with time. When faced with the outlay of $100,000 or (much) more to purchase and implement a PAA, what truly is the savings or benefit that you could hope to achieve? In some areas, this concept is relatively easy to measure. For example, in procurement, the ability to standardize suppliers and obtain bulk pricing contracts for goods you purchase can easily run into the millions of dollars (depending on the size of your business, of course). As such, the purchase decision becomes less "Should I?" and more "Why haven't I already?" With more murky things such as clickstream data or customer retention, the PAA itself may not generate analysis specific enough to truly save money without an effective analysis program to see and act upon the patterns derived by the tool. Ensure you have an action plan for what to do after you install the PAA; specifically, you must know how you will measure and obtain the ROI necessary to pay for the investment and that you have the business support to act upon the information gleaned from the analysis.

Danger Points

Some last areas to consider before you sign the purchase order include the following:

Time to truly implement and customize. How long after purchase will it take to implement and fully deploy the PAA solution? Does the vendor expect your staff to perform the implementation, or is special training on the PAA design itself required? Will the vendor or their partner perform the integration on a fixed bid or is every implementation considered "custom" and performed on a time-and-materials basis only?

Customization (a.k.a., "Hey wait, isn't this a 'standard' application?"). Do you have a clear understanding of the additional customization you will require to fully deploy this solution in your business? Have the customizations been identified in a project plan and is your team or the chosen integrator prepared to execute on the plan?

Customization risks during upgrade. Has the vendor clearly identified which customizations you intend to apply might cause future upgrade issues? Is their upgrade design policy clearly documented as part of the license/user agreement? If you follow the customization guidelines and there is a future problem, what support will the vendor provide?

Integrated support. Who owns a problem once the package is installed? We all have plenty of vendor technical-support horror stories. Do you clearly understand which vendor's support line to call for problems with the PAA? Be especially careful here, as the PAA vendor may only be reselling the components (database, ETL and reporting) outside their core product set. If a third-party tool is packaged with the PAA, ensure you have confirmation as to how problems with that software component will be resolved. If you are already using one component of the PAA software outside of the PAA, will the PAA components also be covered by your other support agreements?

Documentation, reality or philosophy? Has the PAA vendor shared the documentation with you before the purchase? Can you clearly see how to install the product and in which order the individual components should be installed? Does the documentation allow for a prior installation of the ETL or reporting platform used by the PAA? Does the documentation clearly outline both how to customize the application and where you should not make changes to avoid upgrade difficulties?

The packaged analytic application provides the significant opportunity to improve your business functions quickly and efficiently. Your purchase of a pre- integrated set of applications should ensure that tool integration issues and other fundamental architectural constraints have been identified and resolved prior to delivery of the software. Careful preview of the PAA design remains the one critical step you should perform to ensure you purchase an application that can live up to the vendor promise. Applied correctly, a packaged application can generate huge returns for your business by implementing targeted analytics quickly.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access