I - Solution Oriented Approach
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:
- Often the solution to a business problem is a process that includes Business Intelligence.
- Therefore: the Business Intelligence, by itself, is not the solution to the problem.
- If Business Intelligence is part of the process, the Business Intelligence tools are, unavoidably, also part of the process.
- A Business Intelligence tool that does not understand processes, or how to be part of one, will be hard to integrate into the solution.
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 understands the nature of processes because everything in it is one.
- The processes are defined in a standard process definition language that is externally viewable, editable, and customizable.
- There is no hidden business logic.
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:
- A simple piece of script: if (customerNo < 3000 ) return 'Bob' else return 'Mary'
- A complex chaining algorithm that bases the decision on the customer's current sales pipeline, service level agreement, lifetime value, payment history, industry segment, and location
- A call to a database or ERP system to lookup the analyst for the customer
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.
- The default engine executing processes within the platform allows you to easily script a light-weight workflow
- When required all or part of the light-weight flow can be implemented with a full-featured workflow engine
- The Pentaho BI Platform includes multiple rules engines
- The Pentaho BI Platform activities are easily integrated into other processes
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:
- Running of report is not audited. If it does not happen when expected how long before someone realizes?
- Managers in each department are required to read the report and filter the information. Reports get lost, managers take vacations, and dates get misread.
- When managers spot upcoming license expirations they leave a note in the employee's mail box. Notes get lost or placed in wrong boxes.
- Employees try to schedule preparation, application and certification time. Schedule conflicts arise, preparation suffers.
- Employees fail certification with no time for further preparation or certification before license expiration.
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
- Create business rules that determine the lead time required for adequate preparation for each type of license and escalation paths for problem cases.
- Run an audited report every day or week that lists those employees within their lead time. For each employee initiate a defined license renewal process:
- Deliver the information electronically to both manager and employee
- Require electronic acknowledgment from both
- Direct employee to schedule preparation time
- Direct manger to approve schedule
- Require employee to enter certification test date
- Escalate warnings if insufficient re-test time has been allowed
- Require manager to validate new license
- Deliver notifications on certification failure to manager and scheduling application.
- Provide on-line, real-time reporting on the license renewal process
- Produce audit reports of monthly and quarterly performance
This solution solves the business problem.
Conclusion
In order to deliver this solution you need reporting and analysis tools that:
- Support the business rules needed
- Audit report execution and delivery of information
- Integrate seamlessly with a workflow system
You also need a workflow / business process engine that:
- Handles time-based escalations
- Audits execution of activities within the process
- Integrates with reporting and analysis tools
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.
- It is process-centric because it is built ground-up to be process-based.
- It is solution-oriented because the solution for many business problems is a process, and the platform includes all the major components required to implement process-based solutions.