Integrated Infrastructure Blog

Progress Software Announces Q4 results - Here are some highlights

Progress Software (NASDAQ: PRGS) just announced their Q4 earnings release. To summarize, it says "Earnings Up in Q4; Progress® Actional® Revenue Up with Triple-Digit Growth; Progress® Apama® Revenue Up with Double-Digit Growth." What I really thought was interesting was the Q4 highlights. The majority of wins involve building or enhancing an integrated infrastructure, and application modernization - both topics we cover in this blog. In case you missed the release, I've included these highlights below. Enjoy!

Q4 Highlights

• Progress Software announced that the Progress® Sonic® ESB (enterprise service bus) is deployed and operational at British Airport Authority’s (BAA) Heathrow Airport Terminal 5.
  
  The Progress solution enables BAA to provide airport integration capabilities using the Sonic ESB product. This includes the creation of reusable integration services for new Terminal 5 systems and of specialist adaptors for the integration of existing key operational BAA systems, such as the Airport Operational Database Integration. (Tag: Application Integration)
  
  
• Progress Software has successfully enabled more than 250 Independent Software Vendors (ISVs) to deploy thousands of on-demand, SaaS applications over the past five years.  These ISVs use the Progress® OpenEdge® SaaS platform to build applications that are used in some of the most demanding and diverse business environments in the world. (Tag: Cloud Computing)
  
  
• British Airways selected Progress Software SOA Solutions to upgrade their travel experience.  The UK’s largest international airline, British Airways (BA), will use the Progress portfolio of SOA solutions as a key part of its travel program to upgrade its IT systems by integrating over 600 different electronic systems and processes involved in getting BA passengers in the air. The flexibility of the Progress SOA portfolio allows BA to extend the features of its e-commerce site right through to its airports, by allowing greater self-service functionality and 'plug and play' capability. (Tag: SOA Success)
  
• match2blue stands out from the crowd with the Progress® Apama® Business Event Processing (BEP) platform by adding real-time capability to next-generation social networking. Enterprise platform enabler for mobile solutions, match2blue (www.match2blue.com), has selected the Apama platform to empower its social networking platform with real-time information on location, ideas, news and trends.  The Apama BEP platform will form a crucial part of match2blue’s back-end infrastructure, providing the performance and scalability needed, as well as supporting its business partners, who will be operating the location-based services to control and monitor their operations through dashboards. (Tag: Complex Event Processing)
  
  
• Alphameric Solutions Ltd, the leading solutions provider to the gaming industry, selected the Sonic ESB to revolutionize the way it handles content and messages across its network. Relying on highly complex and automated processes to deliver odds, prices, race information and documents across a distributed architecture – most needing to be handled in a sub-hundred millisecond timeframe – Alphameric needed a simpler way to incorporate new or updated information in real-time. (Tag: SOA Best Practices)
  
• West Bend Mutual Insurance Company has selected the Sonic ESB (enterprise service bus) and Actional products to underpin a service-oriented architecture (SOA) based IT infrastructure.   West Bend Mutual Insurance, a property and casualty insurance carrier, is pulling together dozens of disparate internal policy administration applications into a single integrated insurance portal. (Tag: Distributed SOA)
  
• Progress Software announced the availability of the Apama 4.2 Event Processing Platform.  The Apama 4.2 release extends the capabilities of the previously announced Apama Parallel Correlator, and introduces significant new developer productivity features that accelerate the deployment of event processing applications. The Apama Parallel Correlator leverages multi-core, multi-processor hardware to deliver high throughput, low latency execution that has achieved seven-fold performance improvements, as benchmarked with real-world customer applications. (Tag: Event Driven SOA)
  
• Slumberland, a leading furniture retailer, is now using standards-based data connectivity products from Progress® DataDirect® for reliable, high-performance support for all their major databases and 64-bit operating systems, for reliable connectivity to their Oracle applications, and streamlined reporting to improve fulfillment and customer satisfaction. (Tag: Semantic Data Integration)
  
• Progress unveiled the industry's first mainframe SQL engine for non-relational data, which can leverage zIIP specialty processors for lowering a mainframe’s total cost of ownership (TCO), with the announcement of its DataDirect Shadow Release 7.2.1.  The DataDirect Shadow release includes ANSI SQL-92 to Non-Relational Data with zIIP Offload and new capabilities that lower costs and attract new process-intense workloads to the mainframe.

CEP as XTP, in SOA Environments

I have been tracking caching based application platforms such as Gigaspaces for sometime now, and I was surprised to see a new spin on these - as XTP (Extreme Transaction Processing) complimenting SOA. They are extending the caching capabilities to SOA solutions. Labeling this stateful SOA environment as a SOA Grid, and projected as an enabler to build next generation applications are in the areas of fraud detection, trade resolution, and risk management calculations away from the mainframe to low cost commodity hardware. Now, this is exactly the pitch from complex event processing (CEP) environments as well. And even CEP is seen as extending SOA infrastructure to support the capabilities to handle large volume event streams such a the banking or credit-card transaction events, needed for fraud detection.

At some level, the notion of "stateful" SOA grids proposed in the above paper is a contradiction of sorts. SOA is by definition discrete and loosely coupled services environment that are brought together in an orchestration environment to realize required business functions. Products such as Progress Sonic ESB do extend the orchestration capabilities to a more distributed environment (itineraries). Here one can see some value for a distributed state information (that caching products such as Giga and Terracota provide). But expecting this to provide the required capabilities for large volume event stream processing is a real stretch!

For starters, CEP is more than (surely, different from) a fast data-access/query mechanism, which is what caching solutions are. Caching solutions essentially extend the database processing model by providing a faster access to data. While CEP is less about data and much much more about quickly 'reacting' to events and detecting temporal patterns that occur in and across these large volume event streams, combining this within an SOA that can emit the events (based on the biz processing occurring within), or provide the required biz processing after the complex-event is detected, is in itself an XTP environment. It is capable of processing a very large volume of event streams and it needs to detect complex patterns in these streams. And, largely due to the unique approach used in the Progress Apama Correlator engine, it flips the conventional store-and-query approach (which is where caching products come in) to a look-ahead-and-react mode. This has already been proven in some of our successful Apama CEP deployments, such as Algorithmic Trading and Fraud Detection (the very same cases referred in above blog post). See the diagram below to see how Apama CEP works:

Who Needs DW? Welcome, Real-time BI !

Last week I got a last minute invite to speak at the Silicon India BI conference (last minute for a good reason I guess... me & BI? Hmmm... :-) My database background notwithstanding!). Initially I resisted as couldn't think of anything of value, especially because the participants were expected to be architects and senior tech folks. As Pradeep (heads Silicon India) nudged, a thought crossed. I recently also came across a BAM use case where the kind of questions they wanted the solution to answer bordered on BI. And, in this solution they needed both SOA and Complex Event Processing (CEP).

Isn't using CEP for BAM in some form real-time BI? I deliberated for a few minutes - the CEP SOA synergies seemed to really make sense, so I agreed to speak. When asked for the title, I submitted "Design Approaches for Real-time BI".

BAM (business activity monitoring) is an extension of traditional business intelligence; adding event monitoring to scheduled, batch-based reporting. As I see it, BI can be of a few different types (when seen from the tainted SOA lens :-) ):

• Simple BAM is watch ‘as-is’. Most BAM software supports simple aggregation and watches for thresholds, et al.
• Complex BAM can watch for more complex patterns.

At some level isn't complex BAM BI? It provides insight and information that traditional OLTP systems cannot give. For BAM or BI, the discrete steps in the decision cycle are the same: Track/monitor; Analyze; Hypothesize/ model; Decide; and Act . The only difference being that BAM (however sophisticated) may not be able to answer adhoc queries and what-ifs. It can only answer pre-defined and pre-modeled situations. Nevertheless, this is BI. And it is real-time!

SOA and CEP form a good basis for realizing this. Conventional (read 'simple') BAMs may not suffice. BI is more than just thresholds or SLA violation alerts. One may need to detect a pattern involving a series of biz failures that could potentially cause a much serious eventual failure, which if detected and alerted in time, can be averted. This is where more complex pattern recognition come into play. The CEP engine. Given that we are talking about business events from all over the enterprise as the inputs, SOA infrastructure fits right in as the potential vehicle to deliver these events to the CEP engine.

SOA+CEP for real-time BI! An interesting proposition! And surely something traditional DW solutions cannot handle. DW & real-time? Nah. Now, can we extend this basic real-time BI to also include adhoc querying and such? Something to ponder about.

Embedded Not-so-lightweight ESBs

David Linthicum touched upon a very prevalent problem of technology not living up to its expectations set during the hype curve! He says, "With cloud computing, SOA, or whatever we come up with next, we still need to figure out core issues within our enterprises that no set of technologies or emerging trends can solve." In the service-oriented architecture (SOA) case, we all know that the widely professed use cases of systems "automatically" looking up service registries on the web/intranet, locating the required services, getting the interfaces, picking the right one, and actually making a service request is just a pipe dream! The reality is nowhere close! It is difficult to even find enterprise wide service buses, much less the dynamic on-the-fly service-look up-and-use!

I recently came across a scenario where even a large international bank has SOA infrastructure solving regional problems - and not necessarily as a corporate backbone! I was at this tech discussion with the regional technology head of a large bank, exploring how Apama (Progress' Complex Event Processing (CEP) engine) fits into a biz requirement they have. Specifically, he wanted to understand how Apama works and how it is a good fit for their biz problem. They were trying to build a business performance tracking solution (a la GRC) that involves tracking key biz activities, ensure due process is followed, and then proactively detect potential service-level agreement (SLA) failures so they can be averted. A classic use case for Apama!

Now, when we started to see where the business events information came from and how they could be "wired" to emit the required events into Apama, we suggested that they could just tie into their enterprise service bus (ESB)—we knew they had standardized on one. As we dwell further, it turns out they are using an ESB to solve departmental integration requirements, and there are multiple instances and no central ESB that can help integrate these "departmental integrations".

Now that was a revelation. (I am not complaining because suddenly our opportunity now included Sonic ESB, along with Apama). While we have been reading (and I myself have been blogging and talking) about how SOA failed to live up to its expectations, I still expected at least a large number of banks to have standardized backbones. But not to be! I guess, like in many large enterprises, even here SOA adoption has started purely to solve departmental integration problems—more as localized islands of "integration". And its nothing like the enterprise-wide integration platforms or service bus that we have so much noise about since 2004. This reality check at this bank was a clear validation of this failure! It seemed clear that the technology promise was something, and the actual on the ground realization was something totally different!

Come to think of it, it does seem like a good model for use cases such as BAM or GRC - to have a complete platform that in addition to the CEP engine and dashboard, it also includes a "local/embedded" ESB. Now, embedded is not about being lightweight or smallas it is about being available out of the box when you get the platform. In this case, the ESB is available along with CEP, well integrated - so no surprises as you start using it. And the purpose is to "wire" exchanges from existing ESBs or applications in the enterprise to the CEP environment.

Not a bad idea at all! Embedded ESBs!

SOA and Events - Two Sides of BAM?

I came across a prospect recently (new markets so engineering help is always welcomed :-) ) - a domain consulting company now building a Governance Risk and Compliance (GRC) solution. Now, this very much being in the area of BAM, one would expect that traditional Business Activity Monitoring (BAM) would be used. But as we were discussing it more, it turns out that more often than not, GRC is about triggering the risk assessment and compliance/governance checks as business events occur. Here again, the trite assumption (that even I made) is that the organization has SOA imbibed all over and so it can easily tie in BAM and use that BAM environment to 'detect' and trigger the necessary checks/rules. And here again, I was proven wrong because SOA is not as widely prevalent as we all would like to believe! The consulting company, a group with a strong domain expertise in Governance & Risk/Performance, who is building the solution said they wanted an "extremely loose" integration, but their prospects were unlikely to have a mature SOA infrastructure. Which means, they cannot really expect BAM to be practical.

After looking at the biz analysis they had already performed, and taking the time to breakdown the GRC system into a bunch of flow-charts (one for each scenario), they found a pattern:

• a business event occurs as part of ongoing business processing
• the event includes the relevant business data
• a series of GRC checks and rules are executed
• any violation is recorded and an alert raised

This consulting company has gone a step further and also modeled the whole biz domain (they were targeting a specific sector in the financial space) - in a very interesting manner. As a set of key business events, anyone in the domain can immediately understand what each of these events mean. Each business event includes a clear definition of the accompanying data. In effect, they flipped the complete domain business ops as a set of business events! Hmmm...

So far, we have seen models that show the enterprise as a bunch of business processes that invoke a set of services. With the above flipped view, the enterprise modeled as a bunch of biz events is very unique. The former is a view of defining the business flows (processes) that form the enterprise's biz processing. The latter view is more of a snapshot of the enterprise post the fact - as business events that "occur" in the enterprise. Both very clearly model the purpose and the data involved, but in the former method, it is the data that flows through. And with the latter approach, the data that gets "generated" post a business activity.

From this consulting company's point of view, modeling the enterprise as a set of business events and the data that each event emanates was a more practical view. The communication to their clients was that they have modeled the GRC flow for each of these biz events. And the integration of the GRC solution involved the client's IT team "wiring" in these events into their existing solutions - wherever the said business activity occurs, and in any technology they may have, SOA or no SOA.  When they wire this, they will also need to pull out the data from their existing systems and "emit" the same as per the defined event data structure.

Pretty neat idea! Is anyone else seeing it this way? Is a GRC solution more about events and less about SOA? Is SOA primary and events incidental, or are events primary and the SOA infrastructure that could generate this be incidental?

The Rise of Events and Eventing

One of the key things I saw in 2008 was the rise of events and eventing through Event Driven Architecture (EDA).  While "events" have always existed, they have primarily been used in specific markets such as algorithmic trading where our Apama product is commonly used.  The shift in 2008, and moving forward, was that events became more mainstream and that meant that the business and their technical developers were looking to see how they could harness events.

In contrast to traditional SOA infrastructure that use service orchestration such as BPEL to control all aspects of the flow, event based architectures can be used to implicitly enable process to occur.  An event typically happens on a state change or document passing between organizational boundaries or similar.  In order for the event to be useful, it needs to be published to everyone who could possibly be interested and as such, an event consumer can correlate multiple event instances to define new logic and/or to monitor the business event in action.  The key benefit for the enterprise is that the events and their correlation do not have to occur at the initial development time, they need to be captured in a single flow. Handling business events in this way allows a much more organic growth to the logic to be implemented.

Now, any changes in practice will always create new challenges you will need to overcome, not least of which will be the ability for people to assume that business will implicitly happen when there is no end-to-end picture, such as what people expect from BPEL or UML. With guidance, we can overcome these issues because typically the number of processes that are discretely modeled within an organization are few.  One of the key things that has to happen is the idea of event modeling. While there are elements of this in UML through state change diagrams, other tools may have to be used.  Another thing to consider here is that the dynamic aspects of the business will need to be captured and displayed in real-time to allow business decisions to occur when an event really occurs rather than hours or days later. 

In these challenging and opportunistic times that currently exist, I see the arrival of event based architecture as arriving in the mainstream at a very convenient time.  Businesses are restructuring through mergers and acquisitions, so IT professionals need to be able to satisfy this change, plus forces in our market are causing new approaches to be taken, including the idea of clouds that become more than mere hosting platforms.

SOA What? I too agree with Dan Foody that the conventional SOA is not dead by any means. It will actually continue to grow and serve more needs. However, I believe you will see that EDAs will rapidly augment existing projects to initially provide real time visibility and then gradually it will help lift some of the burden on the business as your EDAs evolve and grow.  When that happens, you will start to see more business users being able to implement business logic in real-time rather than having to go back to IT.

EDS AirlineSOA Goes Public

I'm a bad blogger. I've been very quiet lately. It's that time of year, after our fiscal year ends, but before we announce our results, and so I've obviously been busy with customers (remember them?) but can't really share the excitement.

I was trying to find the recording from last month's online eBizQ conference and ran across a blog entry by Joe McKendrick (one of my "must-read" industry analysts) talking about EDS' AirlineSOA initiative, and in particular the Lufthansa Airlines project.

SOA What?

Well, which SOA management vendor do you think underlies AirlineSOA?

I'd also point you to a recent post by Anne Thomas Manes that highlights the single most important "new product" that should be budgeted for in SOA implementations... that of a management solution.

It's interesting that both Anne and Joe blog about the same thing... Anne in the abstract, and Joe in the specific. I know AirlineSOA and Lufthansa in particular, use a host of different technologies from various vendors including TIBCO BusinessWorks. But, the only "fashionable" product used differently from the past (when it was just "airline" not "airlineSOA") is Actional.

What do you think of that? (I think it's pretty cool; but clearly I'm biased.)

And, there's more. Why do you think EDS selected Actional?

Performance.

For those of you reading this evaluating your own solutions, I'll share that EDS put a big effort on behalf of Lufthansa to make sure the performance was what they needed. This wasn't a simple "show us what you got, we're going to dump on the vendor" POC. They knew their environment and they invested the time in understanding our architecture, how it mapped to their environment, and how to optimize it all together. If you're serious about evaluating an enterprise tool, you need to make a serious investment in understanding it.

Of course, I still haven't found that recording (in part because I wrote this post). EbizQ has a new face on their site, and it's a big improvement, but old recordings are still hard to find (or, I'm just an idiot).

The relationship between CEP, EDA and SOA

I published a post on our sister CEP blog last week. The topic has wider relevance than CEP so here's a link to it and I include the original text below. Enjoy.

I’d like to add my voice to the debate this week (here, here and here) on how Complex Event Processing (CEP) fits into the wider software architectural themes of Service Oriented Architectures (SOA) and Event Driven Architectures (EDA). Although I think I know how these three areas relate to one another fairly well, I was able to further clarify my thinking this week by spending some time with Neil Macehiter of Macehiter Ward-Dutton Advisors, a UK based software analyst. I found our discussion enlightening as Neil had a slightly different way of looking at these things than I had heard expressed previously. So let me try and express my own view on this in as clear a way as possible.

• CEP is a technology. SOA and EDA are not technologies. SOA and EDA are philosophies for the design and build of modern distributed computing architectures.
• A SOA is a loosely coupled set of services, the functionality of which closely reflects an organisation’s business functions and processes. A SOA will typically use modern, Web services technology and standards for implementation, but is not required to. Building SOA infrastructure requires much thinking about the services that the SOA will use.
• An EDA is a loosely coupled architecture, the endpoints of which interact with one another in an event-driven fashion. Information flows around the EDA as events. An EDA will have endpoints which produce events and endpoints which consume events. An EDA works in a “sense and respond” fashion. Building an EDA requires much thinking on the event-types that the EDA will use.
• An EDA may use business focussed services as endpoints. An EDA may therefore also be a SOA but it does not have to be.
• CEP is a capability within an EDA, providing analysis and matching of multiple events being sent between endpoints. You can have an EDA without CEP.
• If you’re building your architecture and focussing on defining event-types, it’s very likely you’re building an EDA.
• If you are using CEP then you have at least the beginnings of an EDA because you will have been focussing on event-types. Your EDA may a simple one, with one event producer and consumer, but it’s still an EDA.

Comments welcome!

Event-driven SOA vs CEP. What is the difference?

Technology blogs and online communities have been chattering about event-driven SOA and many of our customers have been asking "How does event-driven SOA differ from CEP?" In this podcast, Giles Nelson gives an example of an event-driven style of business, and how today’s SOA infrastructure benefits from an event processing backbone is.

Listen to the entire interview below:

Subscribe to the SOA Infrastructure iTunes channel.

Than a Speeding Bullet—Are You Ready for Event-Driven Business?

Progress Software sponsored webinar will examine the impact of event driven SOA

Hub Vandervoort, CTO of SOA Infrastructure products, will participate in an InfoWorld webinar titled; "Faster than a speeding bullet—are you ready for event-driven business?" on June19th, 2008. During the webinar, Mr. Vandervoort will discuss how event-driven SOA infrastructure can be used to streamline businesses' provisioning and visibility.

When: Thursday, June 19th, 2008 at 2:00 p.m. EDT
Where: To register visit: http://www.infoworld.com/5266

What: In the "Faster than a speeding bullet – are you ready for event-driven business?" webinar hosted by InfoWorld, Hub Vandervoort, CTO of SOA Infrastructure products, Progress Software, shares strategies businesses can implement today that will keep systems ahead of the increased business velocity. He will discuss how event-driven SOA infrastructure—from the enterprise service bus (ESB) and real-time data services to complex event processing (CEP)—can be used to streamline provisioning and visibility.

Why: "Faster than a speeding bullet" doesn't just refer to superheroes anymore; it's the velocity businesses need to compete. Financial trade settlement has accelerated from three days to two hours in just a few years. This trend is repeating itself in almost every industry. The result: current systems can't keep up with the ever-increasing velocity of business processes.

Gain Better Enterprise Visibility of Your SOA

What if you could gain better visibility of business systems and services across your SOA infrastructure? At Progress Software, we believe that you can achieve the promise of SOA without compromising your architecture or getting locked into a single-vendor approach. Listen as Giles Nelson, Director of Technology at Progress Software, presents his observations on the challenges that you and other enterprises face when trying to identify business requirements, deploy smart solutions that will support these requirements, and how - at the end of the day - you'll be able to monitor and analyze operations so that you can make smart decisions that will improve ROI and reduce risk.

Subscribe to our iTunes channel for more SOA Infrastructure podcasts from Progress Software.

Learn more about SOA Infrastructure products from Progress...

• Enterprise Service Bus - Sonic ESB
• SOA Management - Actional
• Complex Event Processing - Apama
• Data Interoperability - DataXtend
• Mainframe Integration - Shadow

How the Wii Will Impact SOA

I am eagerly awaiting delivery of my Nintendo Wii Fit so that I can snowboard and ski in the comfort of my living room.  The Wii has changed the way that people play electronic games.  No longer do I have to contort five of my fingers in a specific manner to cut open a patient or have an 8 year old tell me how to play soccer; a game that I have played for many years.

Here is a new way for humans and computers to interact and it is available for the masses. Even my sister, a self confessed hater of anything with a keyboard and screen attached, is telling me how she has completed the latest run on the snowboard. (She is in England where for the first time in living memory the electronic toys have been released before us in the US.)

Anyway, the way that computers and humans have interacted has had a large impact on new possibilities and the increasing the demands on processing power, i.e. you can do a lot more with DOS than with punch cards, and more with RIA than DOS. But imagine what you can do when you are wearing the interface and how many more users will now want to access the system... (See how many Wiis are sold compared to its competitors.)

SOA What? You are creating and designing your SOA infrastructure with web services, portals and RIA applications in mind, but can it scale up and provide the ability to allow the masses to access your systems and provide services that we have not thought of at this time?  The vision of the future is here. Can you and your SOA adapt???

Loose coupling versus decoupling ...

Last week Jeremy Suratt made an interesting point on the Infor Tech Talk blog.  He says that event-driven architecture (EDA) is different from traditional service-oriented architecture (SOA) in the manner in which applications are related - or not related.  In particular he says "key to event-driven SOA is the ability for decoupled, asynchronous operations."  I agree wholeheartedly with Jeremy and think this point is one of the least well understood aspects of modern enterprise architectures and the complexity inherent in large integration projects. 

There is a great book on this topic entitled "Software Fortresses" by Roger Sessions.  Though the book doesn't mention the term SOA (it largely predates SOA and the current hype), it does point to the fundamental need for decoupling of systems through asynchronous messaging.  In the book, one of the golden rules is "never let transactions cross software fortresses."  I may be misquoting this a bit ... but the essential point is that between application domains, which are referred to as fortresses, you should allow for no dependencies which might block a transaction's completion.  This rule flies in the face of what most SOA infrastructure advocates today suggest is the very purpose of this new architecture.  Aren't we to just make a Web Service call when we want to leverage components in other systems?  Roger says - just because you can doesn't mean you should.  Once you grok these simple architectural best practices and the power it brings through "isolation", you're fast on the road to understanding the difference between traditional SOA and event-driven SOA.  The latter abides by the golden rule by inverting the control of intra fortress communications - using an event publishing rather than a service invocation model.  The former decouples the applications and the latter couples them - albeit loosely through Web services. 

Perhaps this is a long winded "dah" moment for you, but for many organizations it's still something they wrestle with daily.   Progress chose this decoupled model for the design of our integration backbone, Sonic ESB.   As a result, applications integrated with Sonic ESB are naturally decoupled.  This means you can shut down any application without impact to the overall operation of the other applications.  Unlike systems that link through traditional SOA request/reply invocation... Sonic ensures that messages get through when the application comes back online.  Now this is very different from other ESBs on the market or available through open source today.  These ESBs employ a "traditional SOA" architecture - meaning that applications connected through them are coupled via service-proxy rather being decoupled through asynchronous message forwarding.  I don't want to belabor the point, but a loose coupling of Web services is an insufficient architecture for large integration projects.   If you're not familiar with this type of ESB, I encourage you to download our latest Sonic ESB 7.6 version and go through the tutorial on "batch to real-time" processing - which shows the power of event-driven integration in the form of a continuous pipeline processing example. 

Where is the next opportunity?

Whatever disaster occurs next, there is always someone able to turn it into an opportunity.  Look no further than the last dip in the economy and the associated Enron scandal.  Here was a company that lost millions of dollars overnight, causing distress to investors and employees alike.  However, from Enron came Sarbanes Oxley and as such a number of companies were created or changed direction to support SOX compliance and then went on to make money on the back of that disaster.

Now as we watch the latest downturn happening, we should be wondering what opportunities there will be and whether IT is ready for these changes.  Personally I can see a couple of things that are going to happen...  In the banking sector there is going to be new products that are going to appeal to buyers that are being cut off now.  For this, look no further than the 100% mortgages that were common in the UK just a few months ago and that have gone the way of the dinosaur. What is going to replace them when these banks must look to open up other revenue streams?  Governance is probably going to be one of the main areas of opportunity so that repeats of Bear Stearns are avoided at all costs.

From a technology perspective, I believe the following will be important: For those that have invested in SOA infrastructure, this is your moment to shine and to continue seeing the benefits.  Events will become important, and the ability to extract and view events, and then correlate them to monitor and also to drive new business processes will have a leading edge.  The other thing that is probably going to happen is M&A activity as values of companies go up and down. And as such those that have invested in agile, distributed and heterogeneous SOAs are going to show the wisdom of their investment as they give the business an opportunity to recoup their investment many times over.

SOA What? You should ensure that your SOA is ready for the new opportunities that will come.  What does that mean?  It means that the future is going to be a test of how quickly your SOA can change. It means that the rules may need be rewritten every month to support the constant change that is going to happen.  Will your SOA cope?

Web 2.0 and RIAs is Driving SOA Middleware Growth

An interview with Gordon Van Huizen, Vice President, Products, at Progress Software

If if haven't had a chance to read the interview by Jeremy Geelan, Sr. Vice-President of SYS-CON Media & Events, take a moment to read it.

Middleware is one of the fastest growing segments of the software industry today because of SOA. Gordon talks about why and how he believes that the increased interest in Web 2.0 and rich Internet applications (RIA) will further accelerate this growth. He also explains what he believes are the current barriers to SOA adoption and that IT infrastructures need to move toward normalization, as opposed to homogenization, and that the adoption of SOA infrastructure such as enterprise service bus (ESB) and SOA management will help normalize infrastructure interactions with backend systems.

Gordon also talks about the Progress Software approach and how he believes 2008 will be the "year of the events" and that events are the decoupling agent in modern enterprise computing architectures and are as important as services and processes.