« July 2008 | Main | September 2008 »
August 31, 2008
To Build or Buy? - The Answer is ROI
For Business Intelligence project managers, sponsors and decision makers, things are getting lot more interesting (and complicated) with the advent of packaged BI Applications. Packaged BI is not new but this domain has been getting a big push in recent years from all the major enterprise application vendors.
The logic behind Packaged BI looks sound and bullet-proof. It goes like this - The enterprise applications vendors understand the business aspects very well and have handled complexity of a high order. The collective experience over many years have been distilled into creating specific BI solutions (Financials, Supply Chain, Operations, Sales etc.) and these come packaged with data models, pre-built ETL jobs, standardized reports and high-end predictive analytics. For an example, take a look at this blog describing the packaged BI Applications from Oracle.
So what's the problem - Why can't everybody buy packaged BI applications and live happily ever after?
It appears that the choice is not so simple. Packaged BI has certain drawbacks some of which are outlined below:
1) Packaged BI imposes a certain way of capturing business entities and metrics (euphemistically termed best practices), which might go against an organization's way of doing things.
2) The pre-packaged data integration jobs (ETL) stays relevant only for a plain-vanilla implementation of enterprise apps. Customization done to transaction systems would involve customization to pre-packaged ETL jobs and reports that involves considerable effort and is error prone.
3) Packaged BI apps come with embedded ETL and Reporting tools that might be different from the already chosen enterprise standard tools.
From my own experience, I have seen that the packaged BI comes with so many entities and attributes for each domain that it appears "bloated" for companies taking a first step into performing analytics for that particular domain.
Ultimately, the current situation is such that, BI decision makers are grappling with the question of "Build or Buy" - Should I build the BI application from scratch or buy one of those packaged applications? One way to overcome this problem is to build a strong ROI (Return on Investment) framework for BI initiatives in your organization. ROI is computed by dividing the Net Present Value of cash flows over a time horizon by the initial investment. The details of ROI computation and financial assessment in BI will be discussed in subsequent blogs.
For now, let's assume that you have computed the ROI for a Build solution and also for a Packaged BI solution. Once this is done, the choice becomes a little clear - If the ROI for Packaged BI solution is better than expected and the organization can manage the typical pains of implementing a packaged solution, then consider the "Buy" option, else look for a "Build" option.
Now here comes the little twist - In my experience, I have seen customers looking at a shorter time-horizon where the ROI of a build solution is typically higher and then move onto a buy solution with a longer time-frame in mind. The extra advantage of this approach is that the organization understands its analytical needs much better before implementing a Packaged BI solution. So it is strictly not a "Build vs Buy" question but can also be a "Build and Buy" scenario.
Thanks for reading. Please do share your thoughts.
Posted by Karthikeyan Sankaran at 6:15 AM | Comments (0)
August 16, 2008
The End Point of Business Intelligence Value Chain
An interesting aspect of Business Intelligence is the fact that there are many end-points possible in a BI Value Chain. Let me explain a bit here and build a case for creating "Reference Architectures" in the BI domain.
In my view, there are typically 5 different configurations for the BI Value Chain that leads to 5 possible end-points. They are:
End Point 1: Reporting and Ad-hoc Analysis
This is the most common type of enterprise BI Landscape. The objective here is to provide business users with standardized reports and ad-hoc analysis capabilities to analyze the business. With that objective in mind, data warehouses and/or data marts are created as data repositories and semantic layers developed for analysis flexibility.
End Point 2: Data Hub or Master Data Repository
This is a scenario where the objective is to consolidate data and create master data repositories. The consumption of this master data is typically left to individual consumers to figure it out for themselves. The complexity in this type of configuration is more in terms of data quality and governance mechanisms around the data hub, as the business value increases only if more systems utilize the data hub.
End Point 3: Source Systems
This configuration indicates a fairly mature landscape where the feedback loop from the analytical systems to the operational ones is in place. The concept of Operational BI is built on this foundation where the data from transaction systems go through the analytical layers, gets enriched and reaches its place of origination with the intent of helping business make better informed transactional decisions.
End Point 4: Data Mining models
This is a configuration that helps organizations compete on analytics. Integrated, subject oriented, cleansed data that is taken out of data warehouses / marts are fed into data mining models in a seamless fashion. The results obtained from the data mining exercise are used to optimize business decisions.
End Point 5: Simulations
Here is a configuration that I haven't seen in practice but have a strong feeling would be the future of BI. I have some experience in working with Simulation tools(Powersim, Promodel to name a few) where the idea is to create a model of the business with appropriate leads, lags, dependencies etc. The starting criteria (set of initial parameters) would typically be fed by a business analyst and the output of the model would indicate the state of business (or specific business area being modeled) after a period of time. Given this context, I think it would be more powerful to have the simulation models being fed with data from analytical systems in an automated fashion. Presuming that the simulation models are built correctly by experts in that particular area, the output tends to be a better illustration of the future state of the business than compared to "gut feel" extrapolation.
Outlined above are the 5 different configurations of BI systems. The logical next step from the technology standpoint is to publish reference architectures for each of these configurations. This would help organizations get an idea of the components involved once they decide on a particular configuration for their business.
Reference Architectures and Simulations in BI environments are areas that will explore more in the subsequent posts.
Thanks for reading. Have a great day!
Posted by Karthikeyan Sankaran at 3:30 AM | Comments (0)
