BI Application Convergence: Build, Buy or Both?

Trends in BI Applications

Information Management Magazine, September 1, 2008

Anthony Politano

I started my career in the 1980s, assigned to the controller’s IT department at a major insurance company. My first project was a custom-built general ledger system. More than 20 years later, it seems almost unthinkable that someone would build a general ledger system instead of buying one. In a lot less than 20 years from now, we will be looking back at our business intelligence (BI) systems with similar amazement. This article examines the convergence of custom-developed and prebuilt BI applications.

History Repeats Itself

To understand the trend in applications, one needs to look no further than the history of enterprise resource planning (ERP), which has gone through four levels of maturity.

1. Custom code. Until the mid-80s, the type of project I described was the norm. Organizations designed their own databases, code, screens and architecture.
2. Individual, off-the-shelf applications. The next wave was a series of individual applications that came mostly prebuilt. Two examples are general ledger systems and manufacturing floor systems. Both came as prebuilt applications that required configuration rather than custom coding. In most cases, the applications were standalone. For example, an organization’s data processing department (as IT was known in those days) was required to code a custom interface from each related financial system (payroll, etc.) to get transactions into the general ledger. There were a limited number of off-the-shelf applications, and many of the financial feeder systems were still custom systems.
3. Integrated applications. Following the success of individual applications, software companies started offering integrated application suites with similar functions or users. An example of this was the general ledger/accounts payable/accounts receivable combinations that formed the basis for the next wave.
4. End-to-end applications. Moving beyond integrated applications, the focus became end-to-end processes. Two examples are procure to pay, handling all functions from procurement through payment, and hire to retire, designed to handle all employee functions through the duration of employment.

Currently, BI and performance management are undergoing their own maturity evolution.

1. Custom code and online analytical processing (OLAP). Early decision support systems were custom databases running on PCs and other standalone systems. Data structures, loading and reporting code were all manually created. Adding to the challenge was the fact that coding standards prevalent in many of the mainframe systems were not adhered to in this first wave. It was very much the Wild West of BI.
2. BI platforms. As BI became more important to organizations, software vendors responded with integrated platforms that combined the database; extract, transform and load (ETL) tool; reporting; and analytics. These platforms allowed organizations to build applications that reached across various functional areas such as finance, marketing and HR.
3. Combined applications and platforms. Certain functional business areas were faster to adopt an application approach, such as finance with various consolidation, planning and budgeting applications. Additionally, as the enterprise resource planning (ERP) vendors consolidated, it became much more practical for vendors to prebuild the applications supporting these highly related business functions. Custom code is still required to provide management and performance intelligence on a wider analysis chain basis.
4. End-to-end BI applications. Similar to how ERP has defined end-to-end applications, BI will be able to provide seamless intelligence and performance management applications.