Best Practices, Part 4: The Technology Domain
Business Intelligence Collaboration
Information Management Online, August 18, 2005
Planning the BI-C: Level One - Project
The Technology Domain
To continue on the themes of the last two months, we'll move forward with the approach to plan a business intelligence collaboration (BI-C) environment by expanding on the methodology to perform a readiness assessment an organization has to accept, plan, build and implement a BI-C.
We have covered the People and Process domains and this month we'll cover the Technology domain by continuing with the same example, at the project level: a DW/BI application that addresses a specific, internal business need based on the measuring, monitoring and controlling a process.
Advertisement
Figure 1: Four Domains of Business Intelligence Collaboration
As we discussed in earlier articles, the one key ingredient missing in most collaboration programs, and especially within a specialized area like the data warehouse/business intelligence area, is the capability to automate the overall BI-C program - common process workflows and knowledge repositories; and for BI projects integrating a BI-specific methodology of best practices, deliverable templates/examples, plans. While most organizations have knowledge repositories, work plan repositories, methodologies, development processes, etc., none are contained within the same integrated and automated platform. Collaboration can only work well when developers, analysts, project managers, program managers, strategic planners and business sponsors are all working with and using the same data, processes and information to plan, build and deploy BI applications. The capability to automate sharing and interaction is a necessity.
The Technology Domain is driven by the other domain's requirements like most applications - top down based on people, process and information needs. Yet the Technology Domain is a little different for BI-C programs since no off-the-shelf technology exists aimed directly at the problem. This poses a risky problem to solve for those responsible for the plan/build/delivery of BI-C programs. With no one solution on the market, typically a development team will pick a collaboration "development" environment and make due with patching together of framework of loosely couple BI-C components. This can work in some cases, but usually without some very astute planning and design work by the development team, the business is left with a non-integrated, hard to navigate application.
In this article, we hope to help the reader ask the right questions around the Technology Domain to ensure they can build a true automated, collaborative business intelligence environment.
Readiness Assessment: BI-C Level One - Project
Domain - Technology
System Infrastructure The system objectives to automate the BI-C capability must be aligned with the business objectives with the system architecture supporting the BI-C business goals. At the same time the system architecture must be flexible to meet future needs and growth. |
Hardware, DBMS, Software...
|
Data - Structured and Unstructured Data as it relates to the BI-C comes from every source within an organization. Traditional structured data kept in logically organization computer and paper files to unstructured date such as a screen shot of a BI application design. The need to understand the sources and how one is to integrate data for a BI-C poses a unique challenge and very important to a successful BI-C program. |
|
Page 1 of 2.
