Businesses today face increasing pressure to open up their business intelligence (BI) capabilities to business partners and customers. Whether called a customer portal, vendor information system or partner BI, businesses ranging from consumer products to pharmaceuticals to high-tech manufacturing need to tackle this challenge. While the core methodology for building an external data warehouse is similar to that of building one for internal consumption, there are specific factors critical to the success of an external-facing BI application. These distinguishing factors include performance, security, compliance and user interface tools.
Opening up a BI system to external users may increase the number of users by thousands or tens of thousands over the original internal warehouse. Underestimating the impact of this influx of users is one of the most common mistakes of earlier attempts at creating external-facing BI systems. I worked with an organization that tried to fix the problem by adding more servers and memory, with less than successful results. The influx of users actually required a look at the complete architecture, not just the hardware. Key areas to examine include:
- Technical architecture. Have appliances versus dedicated servers, usage/upgrade of a storage area network, backup strategies, transaction throughput/wait time and disaster recovery been designed and deployed correctly?
- Extract, transform and load (ETL) architecture. Will the current ETL cycle handle the latency and volume needs for external users?
- Data architecture. Are the current structure (star schema, snowflake, etc.) and the aggregation strategy in line with external data query patterns?
- Information architecture. Is the external BI system part of a larger portal strategy geared toward external users?
Best practice: Examine the architecture in the whole. Dont just add horsepower.
The internal data controls and security must be updated and kept up to date to enable safe access by external users across the BI application. There are various methodologies and techniques for the physical implementation of this security, ranging from secure Web pages to individual user authentication through a VPN. The data management professional must involve IT security members from the onset of any external-facing BI system.
Best practice: Involve the security team from the onset to avoid rework or pitfalls.
Besides the technical security, there is also a nontechnical consideration of compliance and legal constraints. Particularly in regulated industries, this is critical. For example, the data protection rules for FDA-regulated industries are quite complex and require specialists in this area to assess risk and exposure. In todays litigious society, enlisting the support of the corporate legal department is critical to protecting the organizations legal exposure. Information opened up for access by business partners may become subject to subpoena if that business partner becomes involved in some form of legal action. The legal department of most organizations can provide guidance on what the legal risk is for exposing certain types of data. Best practice: Seek guidance from compliance and legal before engaging with external customers of partners.
User Interface and Tools
Many internal BI systems have set the bar very high for user interface capabilities. The tools available to developers have greatly advanced in breadth and width. Where there may have just been tabular reporting interfaces in a first-generation internal BI system, newer generations have choices in graphing, complex tabular reports, interfaces to spreadsheet and office systems, and interfacing with portal products. In the past, graphing tools were limited to simple functions commonly found in spreadsheets, but now it is common to find advanced graphing and statistical functionality within products. In dealing with the external user, though, keeping it simple is normally the best way to start when designing the application. Because the data management professional will have less interaction and influence with the external user, a simpler interface will have a higher chance of meeting the requirements of the user. More complex interfaces require more communication with the end user, which usually is limited with external users. Subsequent phases of external-facing BI can tackle the more complex user interfaces for a select group of key partners or customers. Best practice: Keep it simple to start and build on success. Often business groups such as customer service, sales, marketing or supply may not have a full grasp of the technical and nontechnical implications of building an external-facing BI application. This is where the data management professional must be the informed voice of reason and experience in how the application is built and deployed.
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
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access