Business Intelligence Network - The Vision for BI and Beyond

ADVERTISEMENT

Techniques for Integrating Business Intelligence into the Enterprise, Part 1

Published: 18 July 2006

This series of articles looks at several ways to integrate business intelligence into business processes to fit with the role and job function of different users inside and outside the enterprise.

Editor's note: This article was originally published at http://www.businessintelligence.com//ex/asp/code.81/xe/article.htm.

In this series of articles, we look at several ways to integrate business intelligence (BI) into business processes to fit with the role and job function of different users inside and outside the enterprise. These include:

1. Integration of analytical applications with operational applications using an enterprise portal for access and exploitation by internal and external users.
2. Embedding analytics in operational applications during application development.
3. Introducing Web services to dynamically integrate analytical processing with internal and partner operational applications for supporting collaborative commerce.
4. Deploying event-driven on-demand processing for user alerts, real-time recommendations and automated actions. This approach includes business activity monitoring (BAM).

Note that this list of techniques for integrating business intelligence into business processes is not an exhaustive list. The techniques listed are merely popular examples. Other techniques are possible. I want to explore these options in more detail and look at the strengths and weaknesses of each of them. Also, I would like to point out that option 3 discusses Web services. In fact, Web services can be used in each of the other options as well as a standard mechanism to integrate business intelligence. More will become clear as we proceed.

Option 1 - Integrating BI into Enterprise Portals
The first thing to clear up is the definition of an enterprise portal. An enterprise portal provides internal and external users with a single, secure, Web-based user interface to personalised integrated content. I mean content this in the broadest sense such that a portal integrates applications, information and collaboration tools into a single user interface. Applications include internal or external operational or analytic applications. Information includes structured data, business intelligence (reports, cubes, graphs, charts, etc.) and internal or external unstructured content (such as documents, digital media, Web feeds, etc.). Collaboration tools include Web-chat, net meetings, email, instant messaging, etc.

Also, an enterprise portal is not the same as an intranet. A key difference between an intranet and an enterprise portal is that portal technology offers personalisation, whilst an intranet does not. With an enterprise portal, each user sees something different depending on his/her role. Enterprise portals are specific technology products that offer a lot more than a Web user interface. They offer an entire range of services. Examples of enterprise portal products include BEA AquaLogic User Interaction, IBM WebSphere Portal Server, Microsoft Office Sharepoint Portal, Oracle 10g AS Portal and SAP NetWeaver Enterprise Portal. Note also that a portal only offers user interface integration. It is not attempting to integrate business processes or applications. This is simply integration at the screen. Portals render content from different underlying systems onto the screen as a set of "portlets" to make it look like it is all one system. Portlets are simply parts of the screen that give the user access to application functionality, business intelligence, collaboration tools, unstructured content, etc. Figure 1 shows how portlets work while Figure 2 shows a SAP NetWeaver Enterprise Portal screenshot of a personalised role-based sales manager portal with sales business intelligence portlets integrated into the user interface alongside other portlets associated with other applications and collaboration tools. The point here is that the user is presented with what he/she needs to do his/her job. They just see content irrespective of what is providing it. Hence, the user has no idea of what business intelligence tools or analytic applications are providing the business intelligence.

Figure 1

Figure 2

Note also that there can be several portal pages, each consisting of a set of portlets rendering content from different systems. Also, these portal pages can be designed such that they are not only personalised to a role but also task specific (i.e., the portlets on a portal page could, for example, be associated with particular tasks of a business process performed by a person in a specific role. Furthermore, portals are device independent; thus, they can cope with users accessing business intelligence and other applications on mobile devices.

Many of us working in business intelligence are perhaps more familiar with business intelligence portals. Examples of business intelligence portal products include BusinessObjects InfoView, Cognos Connection and SAS Information Delivery Portal. These products are more restricted than enterprise portals in that they provide internal and external users with a single, secure, Web-based user interface to personalised integrated business intelligence (reports, cubes, dashboards, scorecards, tools). Some also support the ability to integrate unstructured content and collaboration tools alongside business intelligence. Business intelligence portals also help organise BI. A screenshot of BusinessObjects InfoView is shown in Figure 3. BI portals often only provide access to the reports, cubes, etc., associated with one single business intelligence vendor toolset and also tend not to offer the range of content integration that enterprise portals do. What is more common is to integrate business intelligence portals with enterprise portals. This is especially important if you have multiple business intelligence portal products already installed in your organisation because you may need to integrate business intelligence from multiple different BI tools and analytic applications into a single user interface to support a specific user. Figure 4 shows an example of BI and enterprise portal integration with InfoView portlets integrated into SAP Netweaver Enterprise Portal.

 

Figure 3

Figure 4

To make this kind of integration between business intelligence and enterprise portals possible, there either has to be a proprietary interface between two specific portal products; or, alternatively (and preferably), the BI portal needs to support the publishing of portlets as Web services using the Web services for remote portals (WSRP) and JSR 168 industry standards (Figure 5). In addition, portals need to be able to interrogate a UDDI registry for remote Web services and create proxy (dummy) portlets that can access these remote Web services via a standard simple objects access (SOAP) protocol with and XML request message to get at the appropriate intelligence.

Figure 5

In practice, business intelligence vendors may simply allow user facing Web services in their BI platform to be integrated directly into enterprise portals (Figure 6), thereby bypassing the BI portal altogether. In this way the business intelligence vendor simply acknowledges that the BI portal is not needed.

Figure 6

What is clear is that Web services make it fairly easy to integrate business intelligence into portal products as well as to integrate BI portals with enterprise portals. Several BI vendors such as Cognos, Hyperion, MicroStrategy and SAS, for example, all provide Web services support in their products to allow their BI tools and also BI objects such as reports, cubes and mining models to be published as Web services. If a portal product supports the WSRP and JSR 168 standards, BI tools and BI objects can be integrated into portals via an industry standard mechanism.

Other kinds of Web services can also be integrated into portals using this mechanism. For example, several data integration products can be invoked via Web service interfaces to integrate data on demand. If you have business intelligence in several data marts and warehouses that need to be integrated you can do this using a data integration tool that can be called via Web services to pass the integrated data back to the requesting portal in XML form. Each data integration query can be a Web service such that BI can then be presented on demand in different portlets alongside other content from other systems. This is shown in Figure 7.

Figure 7

Hence, as soon as the portal page is accessed, data is integrated on demand from one or more BI systems and other data sources to provide content for a portlet. The portal simply thinks it is asking for data in XML form from a remote Web service using SOAP XML requests. If several portlets request on-demand data integration in this way, then of course the ETL tool or EII (enterprise information integration) product is invoked as many times as required.

Integrating BI into portals as an option to create a closed-loop intelligent business environment has a strengths and weaknesses. The strengths of this approach are that it is a fast and economical way to deliver personalised role-based BI to a mass user base. In addition, implementing portals with scorecards, dashboards and collaboration tools seems particularly well suited to executives, managers and power users who need to strategise, evaluate and collaborate before making a decision. Also, portlets may be developed or be available out of the box to support any type of business information, application, or service using this kind of technology.

The main weakness of this approach is that it is presentation-level integration only with manual closed-loop processing (i.e., the user still has to interpret the intelligence before taking any kind of action). This may not be sufficient for operations personnel who are tied to a specific application when performing their job function. The obvious example here might be a call centre operator tied to an application such as Oracle's Siebel. A person in this kind of job function has no time to use any kind of BI tools and may not have time to even interpret the BI to decide what action to take with regards to the customer they are talking to at the time. They may simply want to be told what to do for this customer (i.e., they require an on-demand automatic recommendation). In this case, another integration option may be preferred.

Read other installments of this series: Part 2, Part 3 and Part 4.