The philosophy behind the Pentaho BI Platform and its solutions.

{scrollbar}

In many years of helping customers create reports and analytical systems, we have encountered a similar situation many times. The scenario is always different, but the basic need is always the same: a report is delivered or a particular situation is encountered in the data and something specific needs to happen - a decision must be made, causes must be discovered, or a process must be started. In these cases the information presentation, analysis, and delivery (BI) is a part of a larger process. This process exists to solve the business problem: it is the solution.

To clarify:

The Pentaho BI Platform is the first process-centric and solution-oriented Business Intelligence platform.

Sure we can throw in a little bold text and make it look grand but how do we back up a statement like that when other BI providers are claiming to be adding process-centric features?

Workflow at the Core

The Pentaho BI Platform has several options available for executing activities. The default execution engine is a built-in, lightweight, Business Flow Sequencer. This sequencer allows the solution developer to build solutions from collections of Business Flows that are generally linear and success oriented utilizing passed parameters and a minimum of looping. For example: run a query to find out which departments are over budget, run a budget report for each of those departments, and finally email each report to the department manager.

When the business requirements require user interaction, parallel tasks, deadlines and extensive error handling, there is built-in support for utilizing a comprehensive workflow engine. The workflow engine uses a standard language, XML Process Definition Language (XPDL), to execute the Business Flows within the system. An example of this type of solution would be a Human Resources new hire process where multiple departments have to be notified about the new hire, actions would need to be coordinated and a final task to verify all resources have been issued and all paperwork is complete can be verified and marked completed.

In the case where a solution needs to be coordinated externally, any Business Flow defined in the system is available as web services and return their results via SOAP packages. This allows actions to be coordinated via an orchestration technology such a BPEL workflow engine or a remote application.

Components may also be embedded directly into a custom Java application. This can be important when your solution needs to be part of an existing application or you just need complete programmatic control.

No matter what deployment option you choose:

The platform is built on processes and process definitions.

Service-Oriented Architecture (SOA)

This is rapidly becoming a meaningless term with every application that accepts URLs claiming to have a SOA. When you design a system with a workflow engine as the conductor and director every activity in the system, every step of each process, every bubble in your process diagram must be implemented as a standalone, re-usable component that can be directed to execute the activity required.
This is not just an SOA, this is a Service-Implemented Architecture (SIA). Every activity in every process can be a web service because all activities only ever execute as services. They know no other invocation. The three rules to web services success are: invocation, invocation, invocation.

Services are the building blocks of automated business processes.

Process Integration

Every process and activity in the Pentaho BI Platform executes as a service. If you want to call a process or activity defined in the platform from a process executing in another system, you can. It's easy.

Every activity in the system understands how to be part of another process.

Rules, Rules, Rules

The definition of the platform processes are externally defined, but what about the rules that govern the workflow? XPDL has built in support for complex routing control, and we have added support for multiple rules engines so business logic can be integrated easily into the processes. Multiple rules engines are supported and required because it is unlikely the logic for every decision in every process can be defined easily by only one rules engine.

For example, the business rule to determine the credit analyst for a customer might be best described three different ways in three implementations:

If the credit analyst for each customer is stored as a record in an ERP system, trying to maintain the rule in a different system will be a redundant effort with additional cost, additional risk, and no added value.

Flexible business rules are a critical part of automated business processes.

Business Intelligence / Business Process Boundary

The line between business intelligence and business processes is flexible in the Pentaho BI Platform. This is because the line between business intelligence and business processes is blurry and should be up to you. If you have a BI platform that clearly defines the boundaries between it and your other systems, you probably have an application silo that is hard to integrate the way you need it to. It is your processes, your data, and your software.

Case Study

Problem: When an employee shows up for work at a health care organization with an expired license, there are two outcomes. It may be noticed and a more costly agency worker must replace the employee until their license is renewed, or it is not noticed in which case a patient safety hazard and a liability risk occurs

Business goals: increase patient safety, reduce liability of unlicensed employees, and reduce money spent on agency staff covering for unlicensed employees.

Current process: Each manager maintains a list of license expirations for their department.

Proposed 'solution': Scheduled execution of a report from a central database that lists, by department, licenses held by each employee, and the expiration date of their current licenses.

Solution 1: Give them what they ask for

Create a 50 page report and deliver it to each department once a month.

Resulting Business Process:

This solution is incomplete because it only automates the information delivery, it does not help the real process that has to occur. The business goal is reached at best as a by-product of the reporting solution.

Solution 2: Give them what they need

This solution solves the business problem.

Conclusion

In order to deliver this solution you need reporting and analysis tools that:

You also need a workflow / business process engine that:

You also need to provide real-time and historical process performance reports

This is the Pentaho BI Platform.

The Pentaho BI Platform is uniquely process-centric and solution-oriented.

{scrollbar}