BAM Solutions for CEP Engine Users

January 23, 2008

Today I noticed that SL Corporation has revamped their website with a new page, Solutions for CEP Engine Users.    The page is well written, reinforcing some of my earlier posts on the value proposition for CEP; so I hope the folks at SL don’t mind if I repost their excellent thoughts on BAM and CEP here. 

Solutions for CEP Engine Users by SL Corporation

© 1999-2008 Sherrill-Lubinski Corporation. All rights reserved.

Complex Event Processing (CEP) is a relatively new technology that is used to help companies detect both opportunities and threats in real-time with minimal coding and reusable key performance indicators (KPIs) and business models. Just as services are shared and reused in a SOA, CEP permits the sharing and reuse of KPIs in business activity monitoring while efficiently processing events so businesses can act on situations that impact business and take advantage of real-time processing.

Business activity monitoring, often referred to as BAM, is the capability that Gartner and other distinguished analysts use to describe this visualization capability in the business world. BAM introduces a human element to CEP. It is well-established that the human mind is, today and for the foreseeable future, far superior to machine intelligence in making sense out of complicated situations and events. Therefore, BAM is critical to the success of any complex event processing (CEP) solution.

Depending on an organization’s mission, BAM can be used in various levels within an event processing solution to help users visualize and understand the dynamics behind rapidly changing situations and critical business events. In other words, BAM plays a key role wherever there is a need for better insight into the myriad events that effect your business operations.

BAM provides real-time visualization and alerting capabilities for users to better understand how business events impact their organization. BAM software permits users to quickly prototype, build and deploy event processing business solutions. For example, a telecommunications company would find BAM useful to achieve event-driven SLA monitoring and management; and a large retailer would find BAM important as they stay on top of business-critical events in their supply chain.

Insight gained from BAM, in concert with event processing solutions, enable organizations to make better and faster business decisions so they can rapidly sense and respond to threats, problems and opportunities. BAM solutions permit applications to be designed, deployed and modified rapidly with minimal or no coding resulting in significantly lower development costs. Therefore, a key benefit of BAM in real-time event processing solutions is that KPIs can be deployed, monitored, revised, reused and utilized, economically and rapidly.

Depending on the business application, BAM-enabled visualization is required at numerous levels in an event processing architecture. For example, events from across the enterprise are typically processed by a CEP software platforms from companies such as TIBCO, BEA (soon to be Oracle), Progress Apama, StreamBase, Aleri, and Coral8.

Long before KPIs are displayed to the business users, BAM tools can be configured to assist application developers to monitor and visualize the raw event stream. For the developer, their business is developing applications, and BAM can be very useful when designing KPIs for event processing applications.

Fine-tuned KPIs that have been derived from an event processing application are displayed to the business user. These KPIs can indicate risks, threats, problems, opportunities and other emerging business situations that impact the business.

BAM, in concert with state-of-the-art event processing software, provides the framework for a complete sense-and-respond capability for businesses. Processing raw events and event streams for business opportunities and threats requires robust and rapidly deployable visualization solutions. This is the reason that many distinguished analysts believe that BAM and CEP are complementary and critically interdependent core business capabilities. We at SL Corporation agree, and are pleased to be the leading BAM visualization platform in the event processing/CEP ecosystem today.

© 1999-2008 Sherrill-Lubinski Corporation. All rights reserved.

Advertisements

The 2007 CEP Blog Awards

January 20, 2008

Here are the CEP Blog Awards for 2007, based on the three categories outlined in An Overture to the 2007 CEP Blog Awards.

The CEP Blog Award for Rule-Based Event Processing

Winner: TIBCO Software

TIBCO has a very robust and sophisticated progress-oriented event processing product, TIBCO BusinessEvents, with a proven event processing customer base. TIBCO has a rich complimentary software suite for business process and enterprise integration, management, visualization, personalization and optimization. TIBCO has been in business for many years and has a global reach for both sales and professional services.

The CEP Blog Award for Event Stream Processing

Winner: Progress Apama

Similar to TIBCO in middleware status, Progress Apama has a strong event stream processing product with a proven customer base.  Progress has complimentary software suites for business process and enterprise integration.  Progress also has been in business for many years and has a global reach for both sales and professional services.

The CEP Blog Award for Advanced Event Processing

Winner: Reserved.

None of the software companies currently marketing themselves as event processing platforms meet the our criteria for the Advanced Event Processing award in 2007.


Orthogonal Blogging at the SOA Horse Races

January 20, 2008

Dear friend Opher Etzion responds to my post Betting on the SOA Horse with a discussion on how SOA, EDA and CEP are technically orthogonal, concluding:

“Event Processing can have different interactions with SOA, and when IBM’s announcements in this area will be available you’ll realize that there are different entry points. Event processing can also work in legacy and non-SOA environment.”

Richard Veryard, who also kindly reads my blog (and Opher’s blog) replies with Technological Perfecta where he opines,

“I think there are some mutual dependencies between these technologies, but they are what I call soft dependencies.”

Opher, Richard, you guys are technically right, but you are blogging orthogonally to the message in Betting on the SOA Horse.

First of all, my post was not a technical discussion, it was a discussion about business, marketing, timing positioning and the software industry in general. Therefore, it is a bit humorously orthogonal to reply to a marketing metaphor about investments, competition, software postioning and horse racing with architectual posts about technology and how they are related or interdependent.

In a nutshell, here is why….

Candidly speaking, despite what many analysts want you to believe, end users rarely build “SOAs” “EDAs” or CEPs”. End users have IT budgets to solve business problems with the most cost effective technology they can find; and they do not care (if they have a clue) what cute three letter acronyms have been created by analysts to describe momentum in the software market. Sorry, it is true really.

For example, I remember when I was in Tokyo where the very capable and conservatively risk adverse Japanese executives told me time and time again, “We don’t care about SOA we simply want to integrate our systems.” They were quick to remind me, “You guys in America must realize we don’t care what the western analysts, supported by software companies, say. They have a conflict-of-interest anyway and they are not end users. What we care about are mature technologies with solid reference clients and proven implementations.”

By the way, this is one reason I admire Japanese business so much. They are not impressed with handwaving hyperbole. They just want to see results. In other words, “Prove it, don’t just say it.” The devil is in the details, as they say. The Japanese are highly skillful at cutting through the smoke-and-mirrors. I think this is one reason the Japanese are among the leaders in so many industry sectors, but that is a blog story for another day.

To this point, if you are in front of customers and you are pushing SOA because your software company has “bet the farm” on positioning themselves as an SOA company, you are making a mistake. Three letter acronyms and technology jargon do not solve business problems. In fact, for the most part, they are a red-herring. The same is true of EDA and CEP. This was the main message in my post Betting on the SOA Horse.

How do I make such a statement?

Because for over 20 years I have worked as a consultant working on the opposite side of the table of hungry software vendors who come into our house (organization) tossing out buzzwords, acronyms, and jargon. My job was solving real business problems, not selling software. We used to wonder when all the scrabble and babble the software companies were tossing at us was going to turn into a business language that solves real business problems easily, rapidly and economically. That day never came.

Then, I made a conscious decision to take a break from a long career of consulting to get an insiders perspective on, and perhaps even transform, the software industry (What was I thinking?). This experience, working for a software company, was an eye-opener.  

Candidly speaking again, some software companies tend to live in “La La Land”.

They create go-to-market strategies based on jargon, buzzwords and three letter acronyms that have little to do with understanding their customer’s business problems, risks, and culture. They spin, position and reposition in a market of smoke-and-mirrors happy to sell you a gold disk of “the-answers-to-all-your-problems.”  Then, they leave you the gold disk, and your business problem, as they drive away, looking at your business in the rear view mirror as they count the revenue from their victorious campaign.

These same companies bet on jargon like SOA, EDA, CEP, BAM and they hedge their bets with different combinations of the above, the theme of my post Betting on the SOA Horse, which was not a technology, architectural nor implementation discussion, in any way.

Is it any real wonder why SOA has become, for the most part, complex, vendor-driven jargon barely making a dent in the practical real-world, whereas social-networking and other grass-roots user-driven technologies, most without trendy jargon, has left SOA in the dust for the past few years?


Want Great Technology? Buy TIBCO (TIBX)

January 18, 2008

We all know that Oracle just bought BEA.

Personally, I would have recommended Oracle to buy TIBCO instead of BEA. TIBCO has great technology and their software stack is richer and more diverse that BEA’s. TIBCO spends a lot of  development resources on their graphical user interfaces and design-time and modelling environment to make business integration very easy.  TIBCO’s stockholders, like most great companies with a long history of the same executive management and management style, would greatly benefit from the acquisition.

Citigroup’s John Reilly Walsh upgraded TIBCO (TIBX) shares to Buy from Hold based on Oracle’s purchase of BEA. John thinks TIBCO, the last real middleplayer on the block, will also be purchased, and names IBM as the most likely candidate, “but adds that SAP, Hewlett-Packard (HPQ), Oracle (ORCL), Sun Microsystems (JAVA), EMC and Cisco (CSCO) all could potentially be interested.”

If Oracle bought TIBCO, a very interesting idea, that would leave Oracle the King of Integration (KOI). I don’t think HP, EMC or Cisco would want to purchase a company that is so fundamentally different than their core business.

This begs the question, should Sun buy TIBCO and challenge Oracle, now that Sun has purchased MySQL?

So the three most likely scenarios are:

  • IBM buys TIBCO
  • Sun buys TIBCO
  • Oracle buys TIBCO

In my opinion, the most interesting scenario would be Sun following their purchase of MySQL with a purchase of TIBCO. This could create a strong competitor to Oracle.

On the other hand, Oracle would benefit from the purchase, if only a defensive mechanism against a Sun/MySQL/TIBCO triple-threat, and they would get great technology at the same time.

I would be surprised if IBM buys TIBCO, but if they do, this would also keep things interesting!

From a cultural perspective, the TIBCO culture and the Sun culture are the best match.   I don’t think that the SAP or  IBM cultures are very suitable for TIBCO employess.  So, if you toss in the cultural perspective, Sun, cash rich and in acquisition mode, seems the most likely candidate to buy TIBCO.


The ART of Event Processing: Agility, Reuse, Transparency

January 18, 2008

The other day I discussed CEP in Layman’s Terms: Reuse and Agility. Today, our topic is CEP and transparency. One of the major benefits of “white box” event processing solutions is transparency, something not readily available or obvious in black-box solutions.

Friend and colleague John Bates, Progress Apama, often discusses the benefits of white-box algorithmic trading platforms in terms of increased time-to-market and other competitive advantages. I agree with John and would like to point out that there is another key benefit, in simple layman’s terms, transparency.

For example, let’s say you have designed an event processing solution for operational risk management (ORM). It is time for your favorite auditors to come by and they wish to take a look at what is going on with that proprietary black-box ORM application running quietly in the server room.

The nice auditors ask you, “What does that application do?” and you reply “Well, it looks for evidence of insider trading,” and they ask “Do you mind if we ask how?” and you respond “Good question, do you mind to wait a moment while I get you the contact info for the vendor because we don’t have access to the source code or the actual key indicators (KIs)?”

Now, let’s look at the white-box scenario:

Again, the nice auditors ask you, “What does that application do?” and you reply “Well, it looks for evidence of insider trading,” and they ask “Do you mind if we ask how?” and you respond “Yes, sit down and we will pull up our insider trading key indicator models. These models are stored in XML format and viewable in our graphical KI design studio. We can print out the KI models for insider trading if you like!” and the smiling auditor says “Thank you, your system is much more transparent than the last place we visited!”

This scenario also applies in looking for why certain KIs were not detected that should have been; or when performing a root cause analysis to see why the KI you used in your wrong business decision was inaccurate.

So, CEP in layman’s terms is what we might refer to as the ART of event processing:

  • Agility
  • Reuse
  • Transparency

Please feel free to reuse these idea, but please don’t forget to reference the author and this blog 🙂

Kindly share and reuse by reference, because all content in The CEP Blog is ©2007-2008 Tim Bass – All Rights Reserved. Thank you!


CEP in Layman’s Terms: Reuse and Agility

January 18, 2008

We often hear a lot about the core benefits of SOA, which include reuse and agility.

This week, I was in a meeting with Manoo Ordeedolchest, Board Member of Software Park, Thailand, Former President of the Software Industry Promotion Agency (SIPA), Former Dean, The School of Technology, Shinawatra University and a Lecturer at Chulalongkorn University, National Institute of Development Administration (NIDA), as well as other universities. 

We were discussing CEP and our proposed CEP Center of Excellence concept for Software Park.  One of the topics we touched upon today was CEP “in layman’s terms.”    After some brainstorming about CEP, it we were moved to draw a parallel between the SOA and CEP concepts of IT agility and reuse.

Just as SOA is centered around service component reuse and the agility to create new applications from service components quickly and economically; CEP can be considered to be centered around the reuse and sharing of domain knowledge, key indicators (KIs) and other intellectual property (like analytics) when processing events.

In an SOA, we modularize services and a service-component architecture in order to share services and build new applications from these service components.

One of the business goals of CEP is to modularize and standardize declarative programming logic and reuse this logic with event processing platforms from a variety of vendors.    This permits both reuse and agility when building event processing applications, at the application logic level versus the SOA service component level.

So, in laymen’s terms CEP can be discussed using the same SOA concepts of reuse and agility, applied to event processing application logic and KIs.

In a future post, I will talk about about CEP and transparency in layman’s terms.


Oracle to Buy BEA Systems for $8.5 Billion

January 16, 2008

After three months of wrangling over prices, Oracle Corp. will acquire BEA Systems in a $8.5 billion deal.

This means that Oracle will now have an event processing platform, the Oracle WebLogic Event Server to compliment their product line.

Reference:  Oracle Strikes Deal to Buy BEA Systems for $8.5 Billion  (Wall Street Journal)

By JOHN FLOWERS
January 16, 2008 8:14 a.m.

Oracle Corp. said it will acquire BEA Systems in a $8.5 billion deal three months after BEA slapped away an Oracle takeover offer as too low.

Oracle would pay $19.38 for each BEA share, a 24% premium to Tuesday’s close price of $15.58.

Oracle made an unsolicited $6.7 billion, or $17 a share, takeover proposal in October, but the company let it expire weeks later after BEA said the bid was unacceptable. At the same time, BEA added it was looking to start negotiations with interested parties willing to pay at least $21 a share.

“The addition of BEA products and technology will significantly enhance and extend Oracle’s Fusion middleware software suite,” said Oracle Chief Executive Larry Ellison. “Middleware” is a general term for any programming that serves to mediate between two separate and often already existing programs.

BEA Chairman and CEO Alfred Chuang called the deal the culmination of a “diligent and thoughtful process” to maximize stockholder value. The company’s largest shareholder, billionaire Carl Icahn, had called for an auction to sell the business-management-software firm.

BEA is one of the few independent, midsize software companies left in Silicon Valley as the technology industry consolidates. Oracle has for years eyed BEA as an acquisition target.

BEA has been battling Oracle, International Business Machines Corp. and others in the market for middleware. BEA, with a product called WebLogic, pioneered one category of middleware called application servers that are used to build Web services.

Oracle expects the buyout to boost earnings by one cent to two cents a share, excluding items, in the first year after the deal closes. That is slated to happen by midyear.

Shares of Oracle fell in premarket trading to $20.80 after closing Tuesday at $21.31.