Dave Linthicum's Podcast Channel« Responses to my 'No Programming for Integration Movement' | Main | Make sure to listen to the Podcast tomorrow »
May 26, 2006Business Intelligence within SOAs being sold at the Wrong Layer
I’ve seen a ton of BI solutions in my years, and now that SOA is hot they are attempting to bind their solutions to SOA, calling it real-time business intelligence.
First of all, there is clear value with the analysis of data in real time, I’ve written about it and spoken about it many times. However, in selling real time BI in the context of SOA, many are becoming confused as to where that pattern should exist. Clearly, not within a BI technology product just attached to a SOA stack. Hear me out.
While the current BI solutions are looking to “bolt-on to a SOA” (exact quote), they really need to exist at a very specific level, for a very specific purpose, and do some very specific things,….in my world that’s Level 5 (see levels below). It exists there for a few reasons, and may indeed not be a particular BI product, but abstracted into the orchestration layer altogether.
Here’s my thinking:
Within the orchestration layer all of the abstractions exist, and are indeed re-abstracted into solutions, or processes. Thus, the BI layer needs to exist within the orchestration layer to take advantage of these higher-level services. Many are attempting to place BI components directly on core or primitive services and data sources and sinks, that won’t help you much considering the larger strategic nature of SOA.
The BI layer is needed within the orchestration layer for BI services, or the ability to leverage BI services within the solution instances. Thus, we can make process decisions based on real time or near time information; it makes all the difference.
The problem is that BI products, especially real time products, are not being sold at the orchestration layer, but are more tactical in nature. Thus, they won’t have much of a life when you leverage them within the context of a strategic architecture such as SOA.
Dave’s SOA Levels
Level 0 SOAs are SOAs that simply send SOAP messages from system to system. There is little notion of true services, but instead, they leverage Web services as an information integration mechanism. Hardly SOA, but certainly a first step.
Level 1 SOAs are SOAs that also leverage everything in Level 0 but add the notion of a messaging/queuing system. Most ESBs are level 1 SOAs, leveraging a messaging environment that uses service interfaces, but really does not deal with true services (behavior), and instead moves information between entities as messages through queues.
Level 2 SOAs are SOAs that leverage everything in Level 1, and add the element of transformation and routing. This means that the SOA can move information from source and target systems, leveraging service interfaces, as well as transform the data/schemas to account for the differences in application semantics. Moreover, by adding the element of intelligent routing, you're able to route the information based on elements such as source, content, and logical operators in the SOA.
Level 3 SOAs are SOAs that leverage everything in Level 2, adding a common directory service. The directory provides a point of discovery of processes, services, schemas, and such, allowing all those who leverage the SOA to easily locate and leverage assets such as services. Without directories, the notion of service reuse--the real reason for building SOAs--won?t work. Directories are typically standards-based, including UDDI, LDAP, and sometimes more proprietary directories such as Active Directory.
Level 4 SOAs are SOAs that leverage everything in Level 3, adding the notion of brokering and managing true services. Here is where the brokering of application behavior comes into play. In other words, at this level we are not only about managing information movement, but the discovery and leveraging of true services.
Finally, Level 5 SOAs are SOAs that leverage everything in Level 4, adding the notion of orchestration. Orchestration is key, providing the architect with the ability to leverage exposed services and information flows, real time business intelligence, creating, in essence, a "meta-application" above the existing processes and services to solve business problems.
Posted by davel at 01:58 PM in
| 
Digg This | 
Add to del.icio.us
