Pros:
- Leverage vendor knowledge from prior experience and other customers
- May fill in the gaps in enterprise domain knowledge
- Best if your IT dept does not have experienced data modelers
- May sometimes serve as a project, initiative, solution accelerator
- May sometimes break through a stalemate between stakeholders failing to agree on metrics, definitions
Cons
- May sometimes require more customization effort, than building a model from scratch
- May create difference of opinion arguments and potential road blocks from your own experienced data modelers
- May reduce competitive advantage of business intelligence and analytics (since competitors may be using the same model)
- Goes against “agile” BI principles that call for small, quick, tangible deliverables
- Goes against top down performance management design and modeling best practices, where one does not start with a logical data model but rather
- Defines departmental, line of business strategies
- Links goals and objectives needed to fulfill these strategies
- Defines metrics needed to measure the progress against goals and objectives
- Defines strategic, tactical and operational decisions that need to be made based on metrics
- Then, and only then defines logical model needed to support the metrics and decisions
Thoughts, comments?
Most folks combine how information is sourced/integrated and how information is used into a single EDW model. Add on top of that the challenge to keep everything "start schema"ish. The uses/use-cases of information are many and continue to evolve in any business. If we look at the Bill's corporate information factory, the EDW is an integration point for the enterprise and the datamarts represent various applications or uses of that information. Even when an organization does have the talent to develop an enterprise model, getting business to define things accurately and consistently might be a challenge. This is a problem no packaged or home grown model can solve. Bringing consultants in to facilitate might make the exercise a little more efficient at best. At the end of the day the organization has to appreciate the "value" of information or the "cost" of not doing so and business/IT leadership need to be articulate this well and press for neccesary change.
As usual, you are commenting on something very relevant and current. We get this question a lot and I hoping I can point my prospects to your Blog post.
I agree with all the Pros.
Regarding the cons:
I agree with all the Cons, but have questions/comments regarding the two below.
1. Competitive Advantage: I believe the competitive advantage derives from proprietary business processes. In this case, a packaged analytic model will not or at least "should not" support the proprietary business process. If it did, there was only an illusion of competitive advantage. There should be not fit. Typically vendors will pick business processes that are common to build a packaged analytic model, so that they can monetize he engg. investments and stay away from highly custom processes as it relates to packaging.
2. "Agile BI": Given that the model is ready, I would assume it would save time and deliver a faster deployment. Confused about this one, hopefully you can elaborate, what you meant.