Business Intelligence Network - The Vision for BI and Beyond

ADVERTISEMENT

Intelligent Integration Depends on Business Intelligence, Part 3

Published: 6 August 2008

In this article, Devlin discusses how business intelligence skills can contribute to the user interface for SOA projects.

In Part 1 of this series, I showed that enterprise-wide application integration projects based on service-oriented architecture (SOA) bear an uncanny resemblance to the enterprise data warehouse projects that business intelligence (BI) departments have been undertaking for years. The staged roll-out approach to SOA described in Part 1 and repeated in Figure 1 here is based closely on the experience of data warehouse projects from as far back as the mid-90s. This observation clearly begs the question: What other skills, techniques and knowledge can BI professionals bring to the current and ongoing SOA craze? Part 2 discussed one of the key cross-over areas: data modeling. In this article, I want to discuss how BI skills can contribute to the user interface for SOA projects.

Figure 1: Rolling Out an Integration Infrastructure

Application Interface or User Interface?

Back in the good old days (were they really all that “good”?), a significant chunk of development resources were dedicated to the design, layout, development and testing of the user interface (UI) and later the graphical user interface (GUI) of any application built by the IT department for the business. The success or failure of the application, its speed of adoption and its perceived value were all closely related to the design, ergonomics and performance of the UI. As a result, IT organizations invested in UI design skills to present the business systems to the users in the best possible light. Through design standardization and attention to a “common look and feel”, successful IT organizations were able to achieve a largely consistent and integrated UI that at least partially hid from users the disparate, individual applications that were needed to run the business. The aim then, and achieved in part, was a common user interface (with the focus on the users) as opposed to individual application interfaces (focused on the application functionality).

The widespread move toward commercial, off-the-shelf (COTS) applications in the nineties changed this situation significantly. Purchased applications came with their own individual interfaces, and users were forced to once again adapt to the applications’ needs and had to bridge the semantic and syntactic differences between the companies’ chosen sets of applications.

In this decade, SOA shifts the paradigm yet again. Large applications, either bespoke or COTS, are slated to be replaced over time by sets of services, brought together as required for a particular process in particular circumstances and often with a specific set of users in mind. The focus has returned from the application interface to the user interface, but with a difference – we now need to integrate the interface needs of disparate services (or parts of applications) into a common but adaptive browser- or portal-based user interface.

The Link to Business Intelligence

Now, the BI-savvy among you may be asking: What has any of this to do with our skills? When was the last time a business intelligence developer even thought about the user interface? Good questions! To understand the connection, we need to step back from pure user interface considerations to what this new SOA interface needs to achieve, and then see how that can benefit from prior BI knowledge and experience.

Consider the portal layout shown schematically in Figure 2, where each of the five numbered boxes represents a portlet that exposes the user interface needs of its underlying service. The five corresponding services (represented by hexagons) beneath are linked in a simple workflow or process. Because the services are, by definition, basic business tasks, we can assume that the user interface within each portlet is well-designed. The real user interface challenge lies in the interaction between the portlets, an interaction which conceptually reflects the red arrows joining the services – the interfaces or data flows between them.

Figure 2: A Simple Portal Workflow

Ahhh! Do I detect a flicker of interest from the BI community now that I’ve mentioned data?

An example will make things a lot clearer. The process here could represent a call center workflow as follows.

1. Problem description portlet and service
   The customer service representative (CSR) enters customer and problem details.
   Problem details are made available to portlet/service 2.
   
   
2. Problem analysis portlet and service
   Using textual analysis of the problem database, the analysis service returns possible existing problem descriptions, which the CSR can select for deeper investigation.
   Selected problem ID is made available to portlet/service 3.
   
   
3. Similar customer problems portlet and service
   Details of the customer background, problem and solution for the item selected in portlet 2 are displayed. The CSR can discuss with current customer and switch back and forth between problems and customer reports in portlets 2 and 3 to (hopefully) identify a matching problem that has been previously solved.
   If an appropriate solution is found, solution documentation and other information is passed to portlet/service 4.
   
   
4. Problem resolution portlet and service
   If a solution has been found previously, the CSR gives the customer any required advice and closes the problem, which is then added to the problem description database.
   
   
5. Problem escalation portlet and service
   If this is a new problem which requires further investigation, the CSR sets up a problem tracking record and e-mails details to technical support.
   Customer and problem information is requested from portlet/service 1.

The technical details of how data is passed between portlets or services are dependent on the portal or enterprise service bus technology used; and they are not the focus of this article. However, when we look at the content of the inter-portlet or inter-service messages, we are in an area where BI skills are useful.

BI Skills in Data Meaning and Timeliness

Clearly, BI experts can bring the data modeling knowledge we discussed in the previous article in the series to the design of these interfaces. BI data modelers have long experience of the challenges in bringing together data from sources that weren’t designed to work together. Just because two data elements have the same name, there is no guarantee that they mean exactly the same thing. In fact, they refer to quite different business entities. Subtle differences in the meanings of flags or subsidiary fields can render comparisons or conclusions instantly false. The skills and hard-earned knowledge of a BI data modeler can mean the difference between success and disaster in the design of a complex workflow, especially where it crosses departmental boundaries. Is an e-mail a binding contract? What about an instant message? Does it depend on the value of the contract?

The experience of BI developers and designers of working across departmental boundaries can be invaluable for an SOA project. BI team members have had to learn (often the hard way) how to take an independent stance in inter-departmental discussions on who has the “correct” or “best” interpretation of the data, and are often instrumental in creating department-neutral, commonly-agreed definitions. When does a prospect become a customer? When she’s bought and paid for something (the finance department’s view), when she’s signed a contract to buy the goods (according to the sales department) or when she’s discussing the price (says the salesman!)?

Developers with expertise in extract, transform and load (ETL) design can bring further valuable knowledge to the SOA project. ETL designers understand the importance of timing almost as much as comedians! But with much more serious consequences. Data in one part of the system can often be out of synch with data in another part. ETL designers know this because they’ve had to deal with it in the batch load or update processes they previously designed. With SOA, the unspoken expectation is often that all the services required for a process can be linked together in real time. The value of the ETL developer here is that he can bring a dose of reality to bear on these expectations.

While it may be argued that we’ve strayed far from the traditional skill set required for user interface design – and indeed we have, what we see here is that the process and skills needed for user interface design in the SOA world are considerably different than those we depended upon in the past. The reason for this is that SOA user interfaces are primarily about the integration of the existing “interfacelets” associated with the underlying services. And while there are clearly ergonomic and UI design issues that arise in this interface integration, the added dimension is the data integration required. And data integration is most certainly the forte of the business intelligence community.

Coming Next

More knowledge, skills and techniques that BI developers can bring across to SOA, with particular emphasis on that old chestnut – metadata.

If you found this article helpful and would like to receive the latest insights each month from Mike Ferguson and other experts featured on the Business Intelligence Network, please subscribe to the UK Business Intelligence Network Newsletter.