Of course a BI tool can be presented as a Web Service, but this doesn't solve the problems of the underlying data being out-of-date, the database needing to be queried, and unpredictable response times. Moreover, the types of analysis needed in SOA environments don't fit SQL well.

Figure 1 shows a matrix for matching user roles and functions to BI approaches in an SOA. This is worth thinking about quite closely: who is going to do what with BI, and when? Once you've answered this question, you can begin to consider the different approaches you might take. If you simply need reporting on processes after the fact then traditional reporting tools will suffice. But if you want to build analytics into business processes then you're into the realm of application development and real-time BI, depending on who the user is.

There are several new approaches to building streaming applications using Event Stream Processing (ESP) technology, which emerged from university labs. These provide stream-processing toolkits to IT - toolkits for developers to build ESP capabilities into the middleware layer.

Real-time Business Intelligence by contrast is used by business operations, not by IT, and sits on top of the middleware layer.

For BI to truly happen in real-time, the analysis of events needs to be "event-driven" in real-time and done in the context of history. It shouldn't be a query on a database. To be embedded in a process then a BI system must act differently. It has to be both process- and service-oriented.

It's important to understand that process-oriented doesn't mean process-based - the process doesn't need to be explicitly modeled in a business process management (BPM) tool. Rather, it needs to be oriented around optimizing the outcome of a particular process where the process itself may or may not be explicitly defined.

This process-orientation is a prerequisite for any closed-loop BI service, where actions can be automatically driven from the results of the analysis or operations staff alerted if the decision can't be automated. So both closed-loop and process-orientation are key components of BI in service-oriented environments.

Similar to the offline BI world the most interesting analyses in this new world are at the intersection of different services and processes. For example, the ability to analyze both supply and demand in real-time enables prices to be adjusted automatically, thereby increasing yield. In an SOA this has significant implications for your BI strategy if you want to build this type of intelligence into your processes.

Automated processes are driven by events; therefore, it's implicit that to create smarter processes, companies have to be able to view, analyze, and interpret events from across the service chain. This means analyzing data, event-by-event, either in parallel with the business process or as an implicit process step following a service request. You should usually expect that the events required will span multiple processes and services. Some of these processes may be modeled in Business Process Management tools, others not. In some cases the data will come directly from the Enterprise Service Bus (ESB) and in others it will be tightly integrated with one or more service requests.

So if you're using more than one kind of middleware, different rules and BPM technologies across your business then a common and independent BI service becomes an essential provision.

Middleware-centric Architecture Allows Stream Analysis
Service-oriented analysis is also fundamentally different than traditional query-based analysis since it's sequential rather than batch-based. Sequential analysis analyzes data as a stream "in flight" by tapping into the Enterprise Service Bus or enterprise application integration (EAI) software to compare each event, as it's happening, with historical patterns to determine whether a problem or opportunity exists.

This kind of analysis is particularly relevant to in-process decisions and is difficult to achieve in a SQL-based environment. A process might need to assess the impact of an individual event, a combination of events, or compare a current event with a historical "normal" - all of which can be challenging with SQL.

For example, a common requirement is to be able to detect when a particular customer is spending less than usual for an hour and day of the week or month. To do this, businesses have to be able to calculate, for example, the average order value for product X for customer Y in the last hour, for each hour of the day, and then compare this with the average sales for customer Y over the last three months for that hour and day.

To run this calculation continuously for every customer transaction, in real-time, when a business might have 30,000 products and 10 million customers is clearly beyond the capabilities of BPM and rules technologies.

Turbo-charging Business Rules Engines and BPM
Business Rules Engines (BRE) and Business Process Management (BPM) tools are often a significant part of your overall SOA implementation, and it's here that the business and process flow logic is defined. But due to the nature of these technologies, they're not designed for analyzing streams of data in the way that real-time BI is.

Often real-time BI engines are used alongside rules engines to provide additional fine-grain enrichment to the procedural rules defined. This can take several different forms: the rules engine can use real-time metrics as "asserted facts." Often these look like fine-grain real-time product or customer metrics that replace coarser estimates or averages. Examples here include velocity metrics, real-time measures of demand or service capacity, individual product sales, estimated delivery times based on calculations, and so on. Equally, since these event analysis technologies can detect significant events, they are also used in conjunction with BRE and BPM tools where the event is triggered to initiate a process or rule set. An example of this would be to initiate a customer retention process based on subtle changes in behavior by one of millions of individual customers.

Planning for BI in SOA
All SOA implementations will need some form of BI to fulfill objectives such as achieving greater business flexibility, information and application reuse, and real-time integration of business processes, so organizations need to plan for incorporating those capabilities from the outset.

For example, if a company will have to analyze a sequence of service requests that make up a process chain, it will need a common unique identifier in each service request. The organization only needs this for BI purposes, but it's clearly more efficient to build this in when the SOA is being designed than to try to retrofit it later.

Different software, middleware, and integration products have different ways of interfacing with the other components of an SOA, so it pays for organizations to consider how they will integrate them all.

Just as application architectures have changed to embrace SOA, BI is changing by becoming a real-time event-driven, intelligent service. Rather than reporting on the effectiveness of processes after the fact, BI can now, when properly integrated into an SOA environment, be used in the process to route workflow and support decisions in real-time, as customers act.