Readers who lived in the UK in the 1970s will have been surprised at IBM's announcement of SMash. IBM’s SMash isn’t in fact a relaunch of a rather chemical instant potato mix made famous for its slogan ‘For Mash get Smash’ and iconic robots of its adverts . Instead, SMash is a potentially significant development in the maturing of the mash-up in the enterprise. (I say potentially because IBM isn’t telling us much until April.)

To quote form the press release:

“SMash addresses a key part of the browser mashup security issue by keeping code and data from each of the sources separated, while allowing controlled sharing of the data through a secure communication channel.”

The possibility of leakage between sources is a key issue not only from a security perspective but also from an Intellectual Property perspective (the content may be licensed for specific use and this sharing may incur additional fees). I look forward to discovering if IBM’s proposal manages to balance the need for security against the need for usability. While this is the classic trade off with all security, it is particularly acute for Mash-ups which have the ease of creation at the heart of the value proposition.

Ronan

Posted by rbradley in Market Trends • Mash ups • Product news • Web2.0 | Permalink | Comments (0) | TrackBacks (0)

Mash-ups are one of the hot areas for trialing in 2008 and a likely major project area in 2008, 2009 and beyond. The concept is appealing to business users and allows rapid development of useful applications. As I have previously blogged about, mash-ups put a strain on the infrastructure. However the impact is not on the infrastructure alone, it also puts unexpected pressure on the applications supporting the mash-ups. An early adopter in a global investment bank was quoted in a recent article in Waters as pointing out:

"you can't create a service that is designed to support 100 trades per minute and then let someone with a black-box trading system connect to it and expect happy results. The resulting automated traffic would bring the service to its knees and those supporting it would be faced with fielding phone calls from users letting them know the system had gone down."

However, system outage is only one problem - you must also ensure that mash-up user is entitled to use the data (both from an authorization perspective and also from a rights-management perspective as the data may not be licensed for use by the mash-up user).

The only solution is to increase the level of control and governance by defining and enforcing SLA and so on - in effect bringing mash-ups back with the framework of enterprise IT. The challenges will then be

- Finding out where mash-up development is happening in the organization. The very ease with which mash-ups can be created will tend to put them under the radar.

- Convincing the users and developers of the mash-ups that governance is there for good business reasons and not simply central IT attempting to regain control and squash innovation that they do not control.

Ronan

Posted by rbradley in Financial Services • Mash ups • SOA concepts • Web2.0 | Permalink | Comments (0) | TrackBacks (0)

Faced by the uphill struggle of justifying SOA to business managers who find the benefits of SOA hard to understand let alone quantify, it is tempting to link it to other areas of technology innovation which are (we hope) easier to justify. I have previously blogged about the attractiveness of the enterprise mash-up and impact on the infrastructure associated any wide-scale adoption of such mash-ups.

The announcement from Abode about the latest version of its RIA platform reminded me that the issues are not only associated with the ‘back-end’. In particular, the RIA space is developing fast but is still immature. The world has certainly moved well beyond the appearance of Google maps and AJAX. (Of course, AJAX was always a confusing term in that it gave the impression to outsiders that there was a well-defined piece of software rather than a general approach to creating RIA.) However, the RIA space remains an incredibly busy space as can be seen from the list of 25 different RIA frameworks listed here . This diversity reflects a great level of innovation which is good in the long term. And it is fair to point out that RIA is a wide definition – some of the 25 are focused on specific types of applications such as the Ruby on Rails for developing database backed web applications while others such as Tibco’s General Interface are clearly intended for use with enterprise middleware at the back.

This poses the challenge for the enterprise architect of which horse or horses to back. The easy answer that I have heard is that it doesn’t matter: RIA is supposedly easy to replace and are often used to create opportunistic applications (quick to create with short life-spans). If you change your mind (the story goes), simply rip and replace with another RIA. Equally, (the story continues) it doesn’t matter if one department goes for one RIA and another a second.

I remain unconvinced. Yes it is true that it is easier to replace an RIA than to replace infrastructure software such as message queues. To stretch an analogy, if switching message queuing is like a lung transplant, then switching RIA might be grafting back a finger – while I definitely wouldn’t like the first, I wouldn’t volunteer for the second either. What is being ignored is the cost of replacing or maintaining in parallel RIAs based on old tool-kits and new. What is also being ignored is that the users of these applications are the sensitive business users who will not appreciate the disruption of their favorite tool which follows on from switches in strategy.

All of which means that we need to look at the RIA options with a great deal of care: The opportunities and benefits are certainly considerable. However as with other bets on early markets, there are significant downsides as we inevitably make the wrong choices from time to time.

Ronan

Posted by rbradley in Mash ups • Product news • SOA Predictions • SOA concepts • Web2.0 | Permalink | Comments (0) | TrackBacks (0)

When everybody starts to agree that something is bound to be the next big thing, I get jumpy. When people start ramming the Business word in to create a new acronym, I get really jumpy. Complex Event Processing has been getting hype for a while and now IBM (according to Joe) has committed the crime:

“IBM wants to take the technical allusions out of the term itself, referring to it as “Business Event Processing.” The renaming to BEP makes sense, since I doubt if a concept that starts with the word “complex” is going to win a lot of converts.”

However, I don’t disagree with sentiment that CEP could be the next big thing. It has been considered and used a little to deal with the general increase of data volumes in some industries (financial services being in the “lead” as I covered here ).

However, there is potentially much more opportunity in the SOA context as IBM seem to recognize. As the volume of network traffic related to SOA increases, the need increases to monitor, manage and react to anomalies. Anomalies which could correspond to simple human error, to unexpected loads and even to illegal or fraudulent behaviour. Detecting an anomaly may require looking into an event, detecting specific sequences of events or any arbitary combinations of the above. CEP provides a good approach to detecting subtle anomalies occurring in massive message flows in real-time. While you could have used CEP (if it had existed) in the pre-SOA world, it would not have made much business sense: SOA potentially divides many more business processes between applications (into the SOA layer) and also increases the total volume of messages. The combination makes the total value of the messages in the SOA layer significant and therefore controlling the SOA layer becomes as important as managing applications.

The caveat is how quickly and in how many organisations if at all will this level of SOA deployment occur. I remember talking to a senior architect in a US bank last year who was pro-SOA but would never consider shifting the centre of gravity of business processes out of applications. Hence he would never need the sort of CEP control layer capability that I was proposing.

Time will tell – as with most “next big things”, it will take longer and be less massive but CEP will certainly be discussed and used in increasing levels throughout 2008 and beyond. And no, I don't think many people will call it BEP any time soon.

Ronan

Posted by rbradley in CEP • Mash ups | Permalink | Comments (0) | TrackBacks (0)

It is almost 9 months since I have blogged on ebizq. In 2008 I intend to make this my main blogging platform although I will continue to blog from time to time on the Lustratus blog as well. While I intend to change the focus of the blog from exclusively SOA related issues, I am restarting almost from where I left off 9 months ago. In particular, the hot topic was then and remains how to build a SOA business case. Joe’s SOA in Action blog returned to the topic quoting from David Linthicum

“SOA proponents need to redouble efforts to emphasize the business case, and de-emphasize the technology aspect, he said. "It all boils down to architecture." Still, he said, the reuse inherent in SOA can be made to work, and projects where CEOs can see demonstrable value -- such as a real-time analytics dashboard -- can achieve quick success.”

Meanwhile David’s ZapThink colleague, Jason Bloomberg told SearchSOA that

"Furthermore, enterprise mashups are becoming the killer use-case for SOA, that is, the ostensible reason for doing SOA from the perspective of the business. So, SOA is stronger than ever, it's just becoming part of the woodwork. Enterprise mashups are the part that shows."

I think that for better or worse these quotes reflect the reality. SOA is not an easy proposition to sell to business on its own – it is about what you use SOA to do. SOA is certainly a better way of doing internal application integration but these traditional application integration projects are not particularly interesting to the business sponsors. Lack of interest means that cost is everything and SOA can be a very hard sell as early projects have to bear the brunt of the SOA set-up costs (called the SOA tax by some). Therefore, SOA is more likely to flourish in areas where the additional initial overhead can be justified by greater returns and more importantly returns that are of greater interest to the business.

The concept of an enterprise mash-up has been attracting interest outside of the IT department. The concept is inherently attractive to business users as it suggests that there is a way to easily combine the information the business user cares about without apparent interference of IT departments with their long and expensive project cycles. Potential applications from CRM to executive dashboards quickly jump to mind.

Unfortunately, there remains no such thing as a free lunch. Enterprise mash-ups rely on the availability of reliable mechanisms to access the data and suitable access controls to ensure that only authorised users get to what could be very sensitive information. While it is possible to roll out pilot mash-ups, over time proliferation of mash-ups will have a much greater impact than the casual observer might expect: Each mash-up user touches potentially many systems and mash-ups often rely on directly polling the system at regular intervals. This means that large scale roll-out of mash-ups will put large and potentially unexpected pressure onto the applications and infrastructure if not carefully controlled.

Which brings us back to SOA: Large scale deployment of mash-ups will require enterprise grade integration infrastructure as provided by SOA. The challenge for IT departments will be to explain to the irate business user that the reason why their mash-ups don’t work so well any more is because they have to invest more in those vague and intangible concepts: middleware and architecture. We may arrive back to square one but at least our business colleagues may better understand why we need to be there!

Ronan

Posted by rbradley in Market Trends • Mash ups • SOA Predictions • Web2.0 | Permalink | Comments (0) | TrackBacks (0)