1. Decisions are the unit of work to which BI initiatives should be applied.
2. Providing access to data and tools isn't enough if you want to ensure that decisions are actually improved.
3. If you're going to supply data to a decision-maker, it should be only what is needed to make the decision.
4. The relationship between information and decisions is a choice organizations can make--from "loosely coupled," which is what happens in traditional BI, to "automated," in which the decision is made through automation.
5. "Loosely coupled" decision and information relationships are efficient to provision with information (hence many decisions can be supported), but don't often lead to better decisions.
6. The most interesting relationship involves "structured human" decisions, in which human beings still make the final decision, but the specific information used to make the decision is made available to the decision-maker in some enhanced fashion.
7. You can't really determine the value of BI or data warehousing unless they're linked to a particular initiative to improve decision-making. Otherwise, you'll have no idea how the information and tools are being used.
8. The more closely you want to link information and decisions, the more specific you have to get in focusing on a particular decision.
9. Efforts to create "one version of the truth" are useful in creating better decisions, but you can spend a lot of time and money on that goal for uncertain return unless you are very focused on the decisions to be made as a result.
10. Business intelligence results will increasingly be achieved by IT solutions that are specific to particular industries and decisions within them.
Substitute a standard web services interface for a speaking tube, a business rules management system for his encyclopedic knowledge of policies and regulations, data mining or predictive analytics for his customer knowledge and adaptive control for his experimentation and you have Decision Management. The Answerer but on an industrial scale.
The recently coined term «Event-Driven Business Process Management» (EDBPM) is nowadays an enhancement of BPM by new concepts of Service Oriented Architecture, Event Driven Architecture, Software as a Service, Business Activity Monitoring and Complex Event Processing (CEP). In this context BPM means a software platform which provides companies the ability to model, manage, and optimize these processes for significant gain. As an independent system, CEP is a parallel running platform that analyses and processes events. The BPM- and the CEP-platform correspond via events which are produced by the BPM-workflow engine and by the – if distributed - IT services which are associated with the business process steps. Also events coming from different event sources in different forms can trigger a business process or influence the execution of a process or a service, which can result in another event. Even more, the correlation of these events in a particular context can be treated as a complex, business level event, relevant for the execution of other business processes or services. A business process – arbitrarily fine or coarse grained – can be seen as a service again and can be “choreographed” with other business processes or services, even between different enterprises and organizations.
Service-oriented architecture has proven to be a boon in the computing world. At its core, SOA provides enterprise patterns for systems development and integration where legacy systems are viewed as discrete business capabilities and packaged as standards-based services interfaces. SOA also typically describes an IT infrastructure that allows different applications to exchange data with one another as they participate within business processes. Over the past few years, SOA has grown almost exponentially in popularity, becoming one way for companies to knit together applications and processes in a flexible, reusable and cost-effective way. SOA separates functions into distinct units, or services, which developers make accessible to users over a network, ideally allowing them to combine and reuse them in the creation of business applications. These services communicate with each other by passing data from one service to another or by coordinating an activity between two or more services.
- First, event management is primarily about the identification and generation of business events from the ambient events. Similar to what Carole-Ann and I had written in previous posts.- Second, IBM wants to introduce high level EPLs to express the logic for that processing that are business-centric, something very similar to what Business Rules Languages and approaches are in the business rules management area.
- leave anything related to transport, communication to other layers- use this revised CEP to express and execute event-relevant logic, the purpose of which is to translate the ambient events into relevant business events- have these business events trigger business processes (however lightweight you want to make them)- have these business processes invoke decision services implemented through decision management to decide what they should be doing at every step- have the business processes invoke action services to execute the actions decided by the decision services- all the while generating business events or ambient events- etc.
D. Rosca, S. Greenspan, M. Feblowitz, and C. Wild. Requirements Engineering, 1997., Proceedings of the Third IEEE International Symposium on, (January 1997)
E. Mohyeldin, M. Fahrmair, W. Sitou, and B. Spanfelner. The 16th Annual IEEE International Symposium on Personal Indoor and Mobile Radio Communications (PIMRC05), 11-14 September 2005, Berlin, Germany, (2005)
M. LeMay, R. Nelli, G. Gross, and C. Gunter. HICSS '08: Proceedings of the Proceedings of the 41st Annual Hawaii International Conference on System Sciences, page 174. Washington, DC, USA, IEEE Computer Society, (2008)
T. Bucher, R. Fischer, S. Kurpjuweit, and R. Winter. Enterprise Distributed Object Computing Conference Workshops, 2006. EDOCW '06. 10th IEEE International, (October 2006)