LiteBytes from Lustratus Research

Don't be afraid to ask for SOA help

While the number of SOA success stories grow, there are a lot of companies that are finding SOA a struggle. As often happens when something gets heavily hyped, managers are almost embarrassed to admit that they are having trouble. But the truth is that for many, getting outside help may be the best way forward and end up giving great returns.

There seem to be three common SOA 'failure' scenarios.

• This SOA-based project is blowing its schedule/budget/SLAs
• We are diligently implementing SOA, but we just aren't getting the returns we expected
• Everybody agreed SOA was a great idea, but now nothing is actually happening

It is easy to feel that these scenarios must reflect badly on management or technical efforts, since other companies seem to have succeeded with no problems. But in fact, it is perfectly natural to find SOA difficult. In essence, SOA is REALLY different - it is a different way of working, the tools are different, programming is different, design is different.....and so on. However, an important corollary of the success of SOA in other companies is that there is a growing pool of knowledge around SOA procedures and best practices. Already, there are some professional services organizations that have embraced all this accumulated knowledge and developed service offerings specifically designed to unblock the SOA logjam - getting projects moving again, finding why the SOA strategy is not delivering, and clearing up any organizational or procedural blockages.

Companies should not feel bad about asking for help. It really can be worth it, even if there is an initial investment hit. And fortunately, once IT and business professionals get the hang of SOA, they wont need the outside help, so the cost hit does not have to be an ongoing one. The key is to make sure companies choose the right partner. This is a subject that is discussed more in a recent Lustratus Report, "A little help goes a long way", that can be downloaded for free from the Lustratus web store.

Steve

IBM events make an impact on SOA

IBM certainly seems to see SOA as a key initiative, if its annual SOA show is anything to go by. The IBM Impact 2008 even in Las Vegas attracted more than 6000 attendees, and they can't all have gone just for the weather! But the most salient aspect of the event as far as I was concerned was the 'event' support - not the army of people ensuring the party ran smoothly, of course, but the addition of the WebSphere Business Events product.

Event handling has always been possible with WebSphere, but it was messy. Triggers could be set on different queues, and conditions could be detected in various ways, but the whole thing was pretty technical and complex. However, IBM's new product, based around its acquisition of AptSoft technology, delivers exactly what business users are looking for; the ability to write business rules in their own language that can control operations.

One of the key characteristics of SOA is that it breaks monolithic application stacks into individual services, each executing a discrete piece of business functionality such as 'Get Customer Details' or 'Book Delivery Date'. In addition, information flowing in and out of these services is cleanly architected in a standards-based fashion, and is therefore easily accessible. But this opens up a magnificent opportunity to deliver business control over operations through the use of business rules that implement corporate policy by changing execution and flow.

For example, if a bank wants to offer students the opportunity to make payments from their accounts with no charge, a business rule could be written that says 'If account holder is a student, then skip the charge calculation step'. This is a simple example, but with the addition of a correlation capability IBM has ensured that much more complex rules can be put in place. Consider the type of rules needed to mitigate the risk of fraud, for instance, where multiple conditions from a range of different systems would need to be assessed to detect suspicious activity patterns.

The key is that these things can be achieved with the use of business rules that the business analyst can understand. This makes change quicker, and reduces the risk of misunderstandings between the analyst and IT technical staff.

With the addition of WebSphere Business Events support, IBM SOA has finally grown up. I guess the next step could now be a comprehensive BAM solution......we can but hope.

Steve

Selling EDA and SOA to the business

The second Integration Consortium conference call on EDA was held yesterday - kicked off with a short presentation by Lustratus. These conference calls are primarily discussions by practioners and how the discussion pans out can be very different to what might be expected at the beginning. Yesterday was no exception, the starting point was how to build a business case for EDA but moved to a more specific issue: How do you (and even should you) introduce the concept of EDA to an organisation already committed to and busy with a SOA strategy.

There is no simple answer to this: Much of what a good SOA programme brings to an organisation in terms of enterprise architecture and governance is immediately transferable to EDA. And I have previously written about how EDA can be used in conjunction with SOA. The more general issue is how do you translate a technical architecture into business benefit. Much has been written about this in the context of SOA over the last couple of years and it is easy to formulate generic approaches that sound plausible (my favourite in SOA arena is the recipe proposed by some that starts "get a senior management sponsor" - sounds easy, right?).

However at the end of the day, business cases are business specific and quite often EDA or SOA will slot into an unexpected project (as is highlighted by Mike Kavis here - ) because the capabilities EDA or SOA delivers match the project goals, not because having SOA or EDA is a requirement. If you want to get a EDA or SOA kicked off, it is often a matter of understanding the value delivered and matching these values to projects that have to happen anyway.

Ronan

Clearing up the confusion over EDA, SOA, services and events (pt 1)

I thought this better be part 1, since I think this may have some way to run! Lustratus was privileged to be invited to host a telecon discussion in the Integration Consortium SOA series, on the topic of SOA (service-oriented architecture) and EDA (event-driven architecture). The discussion proved extremely interesting, and got me to thinking more about trying to clarify the relationship of SOA, EDA, services and events. This is a subject Lustratus has been involved in for some time - indeed we produced a paper on EDA vs SOA recently.

This Lustratus report contained a table comparing the characteristics of SOA and EDA, the top line of which characterised the activity model of the two approaches - action-based for SOA and events-based for EDA. Action-based means that activity is driven by a user-initiated action, where user is in its broadest context. In other words, the SOA approach is based on services being driven to fulfill some user-driven operation, such as an order entry. The EDA approach is based on activity being driven when an occurrence, or set of occurrences, happens, such as a target sell price being reached to trigger a sale of a block of equities.

This is quite an interesting premise. Some people will say they are doing EDA because they are using an asynchronous message-driven connectivity bus such as WebSphereMQ or a JMS. After all, this is not synchronous but asynchronous, and therefore since events are asynchronous activities, this is EDA. But the previously stated premise would not class this as EDA, since the fact that the transmission of information between components is asynchronous is not relevant to the nature of the operation.

What if we take this further? So, I am performing an order entry service, and using an asynch message bus for communications, but I am running this from the laptops of my agents. When they meet with a client, and enter the order, there is no connectivity yet to the back-end system, so the request is queued, to be executed when the user hooks the laptop up to the phoneline at the end of the day. Is this EDA? After all, the event of the user hooking up to the back-end system triggers the processing of all the order entries.

I would claim this is not the EDA model, because the fact that asynchronous communications mechanisms, including queuing, are being used is an internal implementation detail - in terms of the business operation, the agent is driving a service to enter the order.

To me, the key is this. I may be using events as part of an implementation of a particular service, but the real question goes back to the activity model discussed at the start of this post - is the activity at the highest level, that is the business operation, user-driven or the result of a set of pre-defined occurrences happening. In the case just discussed, it is clearly still user driven.

Perhaps we should distinguish between events, and event-driven architecture. But similarly, we may need to distinguish between services and SOA. Turning things around, suppose I have implemented a particular business process in an event-driven architecture - perhaps these are compliance processes, where the system needs to watch and correlate operations to ensure that required limits are maintained. Activity here will be driven based on determination that an event has happened - for example the total exposure to a single supplier across all purchase orders exceeding a pre-defined limit.  This operation, triggered by the event occurring, may have a number of steps to be executed, such as generating a report of purchase orders concerned. But it may well make sense for these steps to be services in the SOA sense, to facilitate reuse etc.. So does this mean this is not EDA, but SOA? No, because the activity is event-driven even though services may be involved.

However, perhaps the top conclusion in all of this is that the A may be the real source of confusion. Architecture seems to imply that this is the choice for how IT systems as a whole are implemented - that in some way the choice of EDA or SOA is a binary one. In fact, everyone on the IC SOA call agreed that just about everyone will want to have both approaches, depending on the business process need. I guess as long as IT components are accessible as loosely coupled services, then they can be driven in either an event-driven or user-driven mode, and the choice of which will depend on what the process needs to do.

Steve

So what event-driven (EDA) patterns make sense with SOA?

The illustrious Dr. Ronan Bradley of Lustratus, a regular contributor to this blog, will be leading a telecon discussion on EDA and SOA next Friday, 10th August, at 11:00am EDT. The discussion is part of a series on SOA hosted by the Integration Consortium (IC), a global not-for-profit consortium for anyone interested in integration.

Ronan will be setting the scene, clarifying the confusions over EDA and SOA and how they mesh together, and then the discussions will focus on what real-world patterns make sense in terms of events and event-driven activity within an SOA deployment. The IC discussion series is usually members-only, but the IC is relaxing this restriction for this one, so it will be open to all. Details, registration and call-in information can be found here.

From my own point of view, I welcome the topic. Once the confusion of SOA vs EDA has been cleared up, I believe events have a key role to play in many different aspects of SOA operations.

Steve 

Complex Event Processing (CEP) and SOA: Sitting side by side in finance

A perennial SOA discussion is whether it is a universal architecture or whether there will be complementary or even competing architectures.  This article in Water’s Online focuses on this issue in the context of where SOA is being used and more importantly not being used.  While the tone of the article is probably negative to SOA, it is interesting to notice how established SOA is in the large investment banks with quotes featured from both HSBC and Bear Stearns.

To briefly cover the argument:  SOA has obvious overheads if messages are encoded in XML and used synchronously.  This makes it unusable in some of the trading and market data applications where the volumes of data are huge and speed is everything.  In this space, Complex Event Processing (CEP) tools such as those from Progress Apama and Streambase are clearly more suitable than SOA based on business processes and synchronous processing models.  To quote a well balanced view from a senior IT person at Bear Stearns:

"The more glamorous parts of the trading system typically involve super high-performance networks, data-distribution models, and technologies such as CEP that are 'in line' with information coming from and going to the markets," says Moschetti [chief architecture officer at Bear Stearns]. "But other aspects of the system, such as entitlements, configuration, loading of baskets, lookups on reference data, and so on, can use what the industry conceives as SOA—that is, Web services, XML over message busses, and so on," he adds.

Therefore, it isn’t a matter of one approach dominating the other is some strange Darwinian struggle.  For industries where the processing requirements include real time streams (and in particular where the stream volume and complexity exceeds what ‘static’ approaches based on variations on data warehousing can handle), CEP will have a bright future.  That means at the moment: front office in financial services, some government security applications and Massive Multiplayer Online Gaming (as shown by Streambase’s recent announcement).   Apart from that CEP has an important role to play in control and monitoring within the SOA layer as Steve has previously blogged about.

Ronan