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.

Where are We Now?

The industry is currently between level three and level four. Most organizations using any type of BI and performance management systems combine prebuilt applications and custom platforms.

As stated earlier, finance organizations were early adopters of prebuilt applications. There are three main reasons why finance adopted BI and performance management applications first. The first reason is availability. Vendors offered prebuilt applications to functional areas such as finance years before they offered them to other functional areas. Second, the standardization that exists in the finance business area, such as adherence to Generally Accepted Accounting Practices (GAAP), made it more economical and easier for both vendors and customers. Third, finance is very metrics-based and was a natural fit for the adoption of BI and performance management.

BI and performance management applications are not limited to finance, though. Other key areas where prebuilt applications have taken hold include HR, supply and customer service.

Build, Buy or Both

As new business requirements in BI and performance management emerge, organizations should take a structured approach to evaluating whether to build, buy or do a little of both. This involves a multistep evaluation process:

  1. Understand the business requirements. Organizations must be able to express their business requirements. Whether this is in the form of use cases, structured specifications, report layouts or any other business documents, it is critical to understand what you want before deciding to build, buy or do both.
  2. Evaluate components of the application. Prebuilt BI and performance management applications have different components that will be applicable to different organizations. The main components are: data model; ETL, key performance indicators (KPIs) and metrics; reports, dashboards and analytics; and metadata. With business requirements in hand, an organization can evaluate the match to each of these areas. For example, how closely do the application data model and hierarchies match the business needs? Are the KPIs and metrics matched to what the business requires? Does the ETL come prebuilt for the ERP and customer relationship management (CRM) sources in place? Most organizations will find that the result of using a structured approach to matching requirements to applications will be that at least part of their needs will be satisfied by a prebuilt application. With a match at hand, it becomes a financial decision on TCO of the prebuilt application versus trying to build your own.
  3. Understand the financial impact. Unmatched requirements will need to be addressed through a custom coding approach, which would be subject to the same TCO. In reality, most organizations will use a combination of buying prebuilt applications and building extensions or customizations to the applications. However, the financial impacts must be quantified and communicated.
  4. Stay the course. Investing in prebuilt applications is a strategic decision with both strategic and tactical impacts. Once a decision has been made to commit to prebuilt applications as at least part of a BI and performance management landscape, applications become part of the organization’s long-term strategy. Any data governance or portfolio management processes must take this shift into account and be prepared to make appropriate decisions addressing future BI and performance management requirements by implementing prebuilt applications - when feasible and financially viable. Often, this will involve a cultural shift from custom only to custom and prebuilt applications. But just as ERP went through this shift in the 1990s, BI and performance management will experience cultural change. IT experts who have made careers out of building custom databases, ETL programs and queries to support BI and performance management requirements will be most threatened, but they also have the most to gain. Their insight into the legacy of BI and performance management will allow them to lead organization through this change. These experts must also realize that most of their skills and value to the organization will survive. For example, business analysts, regardless of whether the end product is custom built or prebuilt, will remain both critical and unchanged. While prebuilt applications come with defined schemas, the understanding of these schemas for both usability and extensibility requires a keen data architect. For ETL developers, the BI and performance management applications do come with prebuilt applications, but chances are that the ETL will need to be configured, customized or extended throughout the life of the product, making ETL developer skills just as relevant. Because most of the BI applications are built on BI platforms, all the skill sets of BI developers for building both metadata and user interface layers remain relevant. Similar to ETL, much of the metadata will come prebuilt, but extensions and configurations to the product will still be required.

Seven Tips for Deciding to Build, Buy or Both

Understand your business problem. Without a defined business problem, you will be shooting at a moving target. Take the time up-front, either by using in-house experts or outside consulting help, to fully define the business problem and requirements. Evaluate all portions of the application. Consider more than just the front end of the BI application. Take the time to understand the applicability of the data model, ETL and metadata. They are the biggest factors in driving down TCO.

Be prepared to both buy and build. Because most organizations are somewhere between maturity levels three and four, it is highly likely that the final application will be both build and buy.

Learn from example. Most organizations have some form of BI or performance management application in their finance organization for functions such as consolidation, planning or budgeting. Take the lessons learned from these teams of how a prebuilt application works within your environment. They can speak from real- life experience.

Understand your architecture. Prebuilt applications may offer architectural options ranging from database configuration to ETL frequency. Be sure to investigate architectural alignment with your organization. Also, by digging into the data models with the prebuilt applications, you will get insight into how to scale your storage to meet these robust models.

Keep business involved. Even with a business case in hand, do not squander the opportunity to keep the business involved in decisions of build versus buy. Form a business steering committee from the start and keep accountability within the combined realm of business and IT.

Keep abreast of updates. As your organization makes a move from build only to build and buy, new opportunities will arise for retiring older custom applications. By staying up to date with the product direction of your BI and performance management application vendors, you can continue to monitor and/or drive down TCO.

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