|
|
12-26-2007
Registered User
26,240,
27
Middleware and Event Processing Expenditures
Tim Bass
Wed, 26 Dec 2007 04:46:43 +0000
Paul Vincent of TIBCO Software in his post, Outside CEP: the infrastructure stack, makes a statement that “every $ a CEP vendor spends on middleware integration is a $ less on interesting CEP functionality.”
Opher Etzion of IBM, in turn, agrees with Paul in his post, On the envelope for CEP,*and discusses*how*there is much overlap between the capabilities in*middleware and CEP.
I agree with both Paul and Opher, from a purely*technical perspective.
On the other hand, if we look deeper into at the business aspects, we will see that, more often than not, EAI and CEP*projects*are (and will be) funded out of different part of the business organization.** There indeed*is an*overlap with CEP*in the pure middleware applications, as Paul and Opher mentioned; but there is also a quite*specific business domain aspect of CEP that is not*traditionally (or purely)*middleware related.
Recall that most*detection-oriented CEP applications (the reason that CEP exists - detecting opportunities and threats in real-time) are domain specific applications.** These applications may, or may not. be funded out of the middleware side-of-the-house (often the CIO).**
Middleware is sometimes a difficult pill for organizations to swallow.*
Organizations know they need to integrate, but many have glued together their business processes with seemingly free protocols such as SMTP, FTP, SQL*and HTTP for so long, that it hard to justify a large capital expenditure to rebuild the infrastructure.*** Most of these organizations realize that it costs a lot of money to maintain this glueware, but getting everyone on board to paddle the ship*in the same direction for integration is easier said than done.
CEP applications do not necessarily require such a broad coalition of people to work together because CEP is not purely about integration, it is about event processing - detecting opportunties and threats in real-time.****
The security team, working with the web team, can work*together on an*event processing project.**
The marketing team, working with the web team, can work together on an event processing project.
In other words, it may be easier to make business cases for specific event processing applications versus making a business case for a “revolutionize the enterprise” integration effort.
So, from a business perspective, I don’t necessarily agree with Paul and Opher that “every dollar spent on middleware is a dollar less spent on an interesting CEP application.”*
CEP is not purely a middleware technology.* Indeed, CEP*can certainly be used in the middleware space,* but it can also be used in domain specific applications that are typically not funded from the same pot of gold as middleware.
Source...
Wed, 26 Dec 2007 04:46:43 +0000
Paul Vincent of TIBCO Software in his post, Outside CEP: the infrastructure stack, makes a statement that “every $ a CEP vendor spends on middleware integration is a $ less on interesting CEP functionality.”
Opher Etzion of IBM, in turn, agrees with Paul in his post, On the envelope for CEP,*and discusses*how*there is much overlap between the capabilities in*middleware and CEP.
I agree with both Paul and Opher, from a purely*technical perspective.
On the other hand, if we look deeper into at the business aspects, we will see that, more often than not, EAI and CEP*projects*are (and will be) funded out of different part of the business organization.** There indeed*is an*overlap with CEP*in the pure middleware applications, as Paul and Opher mentioned; but there is also a quite*specific business domain aspect of CEP that is not*traditionally (or purely)*middleware related.
Recall that most*detection-oriented CEP applications (the reason that CEP exists - detecting opportunities and threats in real-time) are domain specific applications.** These applications may, or may not. be funded out of the middleware side-of-the-house (often the CIO).**
Middleware is sometimes a difficult pill for organizations to swallow.*
Organizations know they need to integrate, but many have glued together their business processes with seemingly free protocols such as SMTP, FTP, SQL*and HTTP for so long, that it hard to justify a large capital expenditure to rebuild the infrastructure.*** Most of these organizations realize that it costs a lot of money to maintain this glueware, but getting everyone on board to paddle the ship*in the same direction for integration is easier said than done.
CEP applications do not necessarily require such a broad coalition of people to work together because CEP is not purely about integration, it is about event processing - detecting opportunties and threats in real-time.****
The security team, working with the web team, can work*together on an*event processing project.**
The marketing team, working with the web team, can work together on an event processing project.
In other words, it may be easier to make business cases for specific event processing applications versus making a business case for a “revolutionize the enterprise” integration effort.
So, from a business perspective, I don’t necessarily agree with Paul and Opher that “every dollar spent on middleware is a dollar less spent on an interesting CEP application.”*
CEP is not purely a middleware technology.* Indeed, CEP*can certainly be used in the middleware space,* but it can also be used in domain specific applications that are typically not funded from the same pot of gold as middleware.
Source...