|
This performance area goes beyond the information quality, and assesses the overall capabilities of the system
Business Intelligence architecture makes it easy to add new business and subject areas:
This one talks about the extensibility and flexibility of your BI platform, in terms of business themes, and cubes. The architecture enablers for this are:
- Pre-defined logical data-models. Many vendors provide the pre-configured dimensional models, foundation dimensions and measures. This pre-configuration includes the pre-defined ETL routines as well as OLAP level aggregation. This provides the ability to add new business themes quickly. However, one needs to be savvy to manage the benefits from pre-designed models.
- Establishing the foundation dimensions: These are the standard dimensional tables for given dimensions which are common across all business themes and cubes. For example, a standard customer dimensional table irrespective of the business theme (refer foundation dimensions and measures)
- A centralized data-warehouse metadata: An enterprise BI metadata repository will be able to link-up all components of BI (ETL, DW, OLAP, End-user tools...). Ref. centralized BI metadata.
BI platform provides the capabilities to satisfy new requirements quickly:
This is mainly to do on how fast you can address the new requirements out of a given business theme, which is already functioning. This includes:
- Extensibility and flexibility of the dimensional model: To my mind, this is crux of making it happen. A well designed dimensional model goes a long way.
- Architecture ability to do the data lineage: which means that the tools you are using should be able to throw-up the end-to-end impacts of the changes you are considering. If you want to add a dimensional attribute, it should be able to specify the impacts on the following:
- Granular dimensional tables
- Aggregate dimensional tables
- Historical snap-shots
- ETL routines
- The end user tool database model
BI platform provides the capability to easily support the future application needs
Please refer Data Warehouse is not only for analytics. When you are modeling and designing a BI platform, it should be done in away so that it can sustain and cater to the new applications and tools which can sit on it. For example- You may just put enterprise reporting application on top of the DW+OLAP layer in the first implementation. As you move forward, you will place more end-user tools (like data mining, business modeling etc...) on top of the data warehouse.
Sometimes a question is asked on if data-warehouse and olap layer (the layer on top of DW, which provides extensive aggregation and analytics capabilities) can service such a diverse set of applications. The answer is yes, and that's why one needs to model the data warehouse to keep it ready for such wide and diverse use. At the same time, be aware that you cannot have a super-flexible data-warehouse.
BI platform architecture is scalable to handle increases in the number of users without negatively impacting the system performance:
All layers in the data warehouse need to be of industrial strength. The scalability has many different aspects like (you can refer BI OLAP evaluation), spanning both infrastructure and logical layers. There are many tricks you can employ to handle the increase in the number of users. examples are:
- Minimize the number of users giving ad-hoc queries: 95% people ideally should not be required to use ad-hoc queries. I should raise an eye-brow if a collections executive or a customer service executive fires an ad-hoc query. All the information needs for this majority of users should be pretty much standard and scheduled. Instead of accessing the DW platform directly, they can refer the reports which are available through the web publishing and can perform any search within a report. A good enterprise reporting tool can be a very potent asset.
- Use offline cubes: This is a general scalability trick. Enterprise-wide and industrial strength end-user tools (like enterprise reporting, analytics, data mining, information portals...) can have their own offline databases, which replicate the data in OLAP+DW layer to their captive databases. These captive databases or reports repositories or views etc... cater to the user-needs. Refer infrastructure estimate to consider all the layers.
BI platform is easily scalable to handle the increase in the complexity of queries:
Keeping other aspects constant, your architecture should be able to handle complex queries, which may need to run through multiple cubes and access data at lowest level. The fact is that apart from the dimensional models which contain data at lowest levels, the summary level dimensional models are based upon some prediction of the kind of queries which could be raised. The architecture components, which will determine the scalability for complex queries include- modeling, infrastructure, query handling set-up and level of aggregations in olap layer. More levels of aggregations in OLAP should ideally help in managing complex, unforeseen queries. When we say scalability, it means that with some effort and additional investments, you should be able to manage increased set of complex queries. Whether these complex queries are scheduled or ad-hoc also makes a big difference. For example, if there complex queries are pre-scheduled than it’s possible to do the impact analysis and take appropriate actions to enable your BI platform. The ad-hoc queries create more problems, and one needs to manage the set-up in way so that a single complex query does not slow-down the entire platform.
BI platform is scalable to handle the increase in the volume of data:
Keeping the other aspects constant, the handling of increasing data-volumes is again a question of logical layer (modeling, aggregations...) and physical layer (data-explosion management, cache management, infrastructure...). Typically a gradual and step increase in the data-warehouse will work, but when it comes to a quantum jump, one will need to do significant changes to the whole administration and performance management aspects.
BI platform supports and facilitates the integration of data from multiple systems:
From a business point of view, a BI platform should be able to pick-up and transform the data from diverse sources and from varying data-quality. Apart from the capabilities of ETL tools (refer BI tool evaluation); one needs to be diligent on our capabilities to design the complex transformation. This includes the data from the internal systems but also from external sources.
The sources of data for creating BI scorecard on systems quality:
The best source for this is to go through the change requests. Change requests will throw-up lot of information on the kind of changes and the related effort. You will be able to assess on if small changes are looking for a lot of effort or vice-versa. The other area to look at is the production support reports. This gives you inputs on the scalability and data issues. Finally, it’s also a question of customer feedback. |
