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)

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)

AJAX remains one of the hotter topics around the industry with the initial excitement now translating into actual product announcements – most recently Tibco and JackBe. A lot of these announcements are linking strongly back into the SOA space and the cynical eye might suspect some bandwagon jumping is underway – however this time I am not in the cynic’s camp.

JackBe, a company with a strong ex-Sun contingent, has announced its Presto platform
will be released in the first quarter of 2007. This will support the creation of rich clients for SOA which are “Situational Applications”. Situational Applications are applications rapidly developed to solve a specific requirement and are typically written by developers with less technical skills and more context knowledge. To put it another way according to Dan Gisolfi, a Certified IBM Executive IT Architect:

“Situational applications are a way for people with domain expertise to create applications in a very short time. Many IT shops have a backlog of small little projects that their customers want. If it takes 3 weeks to get to a project, the need is gone before the developer even starts coding. We want to give knowledge workers the tools to solve their own problems.”

You might ask what that has to do with SOA. Of course, traditional middleware had little need for interfaces except for management purposes and message repair type facilities as all the user interaction occurred within applications. While this line has been blurring for quite a long time as the EAI vendors added Business Intelligence layers – the generic need for rich client capabilities was limited and this was reflected in features provided in most middleware products.

As you move into the SOA world, you are deploying more business processes into the middleware and more of the business processing resides there. Therefore it makes sense to allow direct user interaction with this layer and using AJAX is of course a way to write these rich user-focused clients. However, JackBe has gone further by realising that simply addressing the presentation and interaction side is not sufficient. If something will be deployed into SOA, it must be capable of conforming to the SOA governance rules and being a “good SOA citizen”.

Finally, what makes their offering a platform for situational applications rather than a generic rich client platform is what they call their “Enterprise Mashup Server” which acts as a consolidation point for the various services and streams of data that will be presented to the users. Of course as the use of the word Mashup suggests, the focus is on making it easy to create new client interface/applications from the available services and data streams.

All of which is clearly of potential benefit within any SOA based enterprise. However, I have two caveats. The first is the use of the term AJAX Service Bus – I am not sure we really need to invent a new term. The second, more serious one is the claim by JackBe of creating “situational applications”, a claim echoed by Jason Bloomberg of ZapThink:

“The Presto platform is poised to take advantage of the opportunity where enterprises are looking to enable business users to compose services into SOBAs (Service-Oriented Business Applications) that implement business processes in a flexible, agile manner.”

Will this really allow business users to do it themselves? This has been the promise of all sorts of client-side software for as long as I can remember (second only to the claim that programs will be auto-generated by modeling tools!). I can see how it will make it easier and require less technical skills for developers to build these situational applications. However, based on the webcam demo I watched, I remain to be convinced that it will really allow non-developers to start work. Having said that, I haven’t seen the released software yet and so I could be wrong!

Posted by rbradley in Market trends • Product news • SOA concepts • Web2.0 | Permalink | Comments (0) | TrackBacks (0)

Sometimes it feels like this industry resembles the old game of “whack a mole” just when you have whacked the last one, another pops up. The SOA community has recently risen up against the horrible term SOA 2.0 and I remain hopeful that this term will disappear as quickly as it appeared. Now another “threat” is bubbling under: The strange view (to me at least) that Web2.0 is in some way incompatible or even competing with SOA.

Steve Jones has written recently about this latest phony war in an excellent blog item. I guess in some ways it was inevitable: Both Web2.0 and SOA suffer from multiple interpretations and when combined with the blogsphere's love of a good row, it was just too easy to set up an “either-or” discussion.

SOA has also been suffering from an on-going naming and scoping discussion to confuse matters further - although I believe the smoke is clearing from the battle-field as we seem to finally agreed that SOA is not simply Web Services or an ESB and equally that SOA can use ESBs without being tainted and that while we may or may not like the term SOA that is what we are stuck with.

With regard to the SOA versus Web2.0 debate in particular, there has been unhelpful throwing around of what are intended as positive or negative terms depending on your side of the argument: 'lightweight' when discussing Web2.0 or 'enterprisy' when discussing SOA (a debate well covered by Joe McKendrik here and here ). This is dangerous as it leads to the mistaken view that the enterprise and all of its integration problems can be solved by either only the heaviest grade middleware or by only the most fluid Web2.0 style approaches. This can only be a plausible view to some software vendors who believe that their product can solve all known ailments or technology purists who believe their chosen technology can really make the world this simple! Instead as Steve Jones points out, there is a role and requirement for many different technologies and approaches: horses for courses -

One size doesn't fit all, and taking an architectural and particularly a business view of SOA helps you pick the right delivery approach for each service rather than trying to shoe-horn one method onto everything.

Web2.0 is of course more than just a set of technologies - it can also be considered to be a set of business models, and a philosophical approach to developing software around participation and easy access and these are certainly challenging to the attitudes often entrenched in the enterprise.

This is the interesting discussion to be had: how the Web 2.0 technologies, philosophy and even business models can be used in the context of the Service Oriented Architecture. And it is going on in many places for instance here – but somehow, perhaps, it is all less interesting than a good fight.

Posted by rbradley in Market trends • SOA concepts • Web2.0 | Permalink | Comments (0) | TrackBacks (0)

It has often struck me as strange that while SOA is all about loosely coupling, the principle hasn’t often been extended to user interaction which after all is almost always at either or both the start and end of business processes. Instead even in a SOA environment, most enterprise users still interact almost all of the time with one application at a time through tightly coupled clients or browsers.

This neatly brings us back to the Web2.0 technologies which are after all primarily a revolution in user interaction and user interface. To narrow the focus a little, lets consider only the following elements of Web2.0:

- The evolution of browser based user interfaces (thanks to AJAX) into something richer and closer to the familiar desktop interface. This is exciting because client side computing hasn’t really changed since the browser first appeared in the late nineties.

- The concept of the mash-up as a combination of services into a single client-built interface has spread in the consumer web.

(While user interaction can be created through wikis and blogs, I won’t delve into these primarily knowledge management tools although they have a clear potential role to play in service definition/reuse and governance and I will focus on the social and collaborative implications of Web 2.0 in the next blog item in this series.)

The implication of much better user interfaces – and hence must more functionality embedded comfortably within those interfaces - and the ability to combine connections to multiple back-end systems as mash-ups has big implications in the enterprise: the client can now evolve towards being a peer of the back-end systems. Although clearly still a peer with limitations – it is now capable of initiating actions independent of a single system and capable of interacting with many systems in a much more intelligent way.

Furthermore because it is easy to create these interfaces and mash-ups, the client can become truly decoupled from the applications as they are now capable of rapidly adapting to handle new applications, new data feeds and new services.

A further implication of the simplicity (and productivity that I previously commented on) of some of the Web2.0 tools is that it creates the potential to take central IT function out of the implementation of these clients completely and instead focus them only on the associated governance issues: allowing less IT expert, but more business focused individuals to solve their problems themselves.

You may wonder whether this can actually happen: can non-IT people create their own interfaces. I don’t think the AJAX tools are even close to being mature enough to support this just yet – they are still built by techies for techies – unlike wikis and blogs which are usable by most people. However, I think the concept is completely plausible – look at the way Microsoft Excel is “programmed” by non-technical people to carry out very sophisticated calculations. Imagine if the same could be done with could be done with a end-user focused AJAX combined with an enterprise edition of myYahoo.

Posted by rbradley in SOA Predictions • SOA concepts • Web2.0 | Permalink | Comments (1) | TrackBacks (0)

Dennis Howlett has added some comments to my recent blog on Web2.0 and SOA. Dennis makes three points, one of which I agree with, one I don’t and a final one which highlights an interesting issue. To paraphrase Dennis’ points:

1. SOA is already a dead concept: “The real problem lies in the term itself, its vagueness and its associations with blue sky projects that demonstrate little more than debatable business value.”

2. SOA is poorly named and would be better called Service Based Architecture.

3. SOA projects need to be applied to specific edge projects – as Web 2.0 projects have been.

I won’t argue point 2 – the Service Oriented term echoes (of course) Object Oriented and indeed service based would be a closer match to what it is about. However, the fight is long over on this one, and we will have to live with Service Oriented.

I will argue with point 1 – Dennis’ points of evidence are application vendors such as SAP saying it is dead and EAI vendors claiming that it is nothing new. SOA is potentially deeply threatening to application vendors such as SAP who sell tightly integrated suites of applications as SOA in its essence encourages mix-and-match. On the other hand, EAI vendors have embraced SOA and following the usual software marketing approach claim that they were doing it for years before the term was coined – we simply didn’t notice.

Moving onto point 3, Dennis is absolutely right that SOA projects need to be prove value and there is a tendency to redefine the term to stand for Seriously Overly Ambitious – turning them into big bang projects which are hard to fund and hard to demonstrate RoI on in many cases. This is not necessary – SOA implementation can and should be done incrementally. Furthermore Dennis hits the nail on the head when he says that one of the distinguishing features of Web2.0 has been the strong focus on productivity: it is easier to work with and therefore encourages innovation. Why doesn’t SOA seem to follow the same path? In our keenness to stress the architecture, as proponents of SOA we risk missing the point that the tools and approaches used can and indeed must be productive if we to prove the benefit of SOA quickly enough to maintain momentum within the organization.

Posted by rbradley in SOA concepts • Web2.0 | Permalink | Comments (1) | TrackBacks (0)

Jason Bloomberg of ZapThink writes about what he thinks the killerApp for SOA will be and to paraphrase him: it will be the mother of all modeling tools, spanning service definition, BPM, extending into deployment with monitoring, policy, management and so on. It will also be the mother of all dashboards – pulling together all the information currently scattered through multiple dashboards and monitoring tools. The twist is that for Jason, the killerApp will be an enterprise mash-up :

We spoke of the SOA Killer App as containing modeling and development capabilities, a wide range of dashboards, and the capabilities of every service consumer under the sun. But that doesn't mean that you'd expect to buy such a thing as a shrink-wrapped package from a single vendor. Instead, the SOA Killer App enables the creation and evolution of itself as a composition of services -- an enterprise mashup tool that is itself an enterprise mashup.

It highlights again what is becoming apparent to more and more people: the technology of Web2.0 is as applicable and attractive within the organization as across the internet. (For anybody wanting a good starting point on Web2.0 read Tim O'Reilly's article)

I agree with Jason’s view that the mashup approach to creating rich user interaction is the way forward in the enterprise – although there are clearly lots of issues around identity and security to figure out as the openness of the consumer web is not appropriate inside the organization. However, I do not think that on its own it will be a killerApp for the following reason:

Clearly, SOA and Web2.0 both add load onto both the applications being interacted with and the level of network traffic and the complexity of flows through the network. In the case of SOA, the load probably won’t cause major problems as the number of applications connecting will remain relatively small.

However, enterprise mashups could be used by every person in an organization. As their popularity grows the number of data flows will increase exponentially. Furthermore, dashboards are likely to be popular components of these mashups and these will be polling (using RSS for instance) with customized queries to get at the data – putting potentially high load onto the queried applications and flooding the network with traffic.

This of course means that for enterprise mashups to scale, the load put onto the network and the queried applications needs to be controlled and to do this a whole infrastructure of enterprise centric aggregators and harvesters need to be put in place as well as traditional management and monitoring capabilities. This doesn’t mean that mashups aren’t a great idea – simply to my mind it is in this area of flow control and management the opportunity to stir things up and create a killerApp lies.

Posted by rbradley in Web2.0 | Permalink | Comments (1) | TrackBacks (2)

I am struck by the difference between discussions around SOA and Web2.0 – don’t panic I am not going to get involved in the REST versus SOAP debate or the debate about which is more hyped or a vaguer term!

What has struck me is the way the big software players are talking up the concept of a SOA platform in a very traditional way: as a stack of vertically integrated software all of which is required to solve the SOA problem, and recently covered on ebizq.net here and here . Bizarrely RedBoss, the new boy in town which should surely be rooted in the new world rather than the old, is taking it even further back in time by suggesting an Operating System is also needed in the stack!

At the same time as all of this, the analyses of what have already happened on the Web and what is accelerating with Web2.0 shows that the very concept of a platform is changing. This is best summarized by Tim O’Reilly’s much referenced article on “What is Web2.0”. The point of relevance here is that the Web 2.0 battle is not between a platform and an application or even between competing but broadly similar platforms – it is between radically different platforms with radically different business models.

So why is this not happening in the enterprise? The old claim that integrating the stack removes the need to integrate multiple vendors’ products and hence reduces cost and risk must be much less true than it was. Open Source in particular has demonstrated that it is possible and relatively easy to stick together multiple products/projects.

Obviously there are many different business dynamics at play in the enterprise than across the consumer focused web. One dynamic is the need in the enterprise to limit the number of vendors (‘one throat to choke’) and incumbency is also important both from a skills and relationship point of view. However, this can’t justify the view that a single integrated stack is the right way to go, unless the stack is at least a good-enough solution. Furthermore, integration in particular is clearly not about tightly coupling homogeneous single-vendor supplied software: Its essence is spanning across platforms, applications and organizations.

The question is therefore will the changes coming from consumer-centric Web-world change the way the enterprise-centric SOA-world to the same extent?

We are already seeing the use of technologies related to Web2.0 (RSS, AJAX etc) growing in the enterprise. However, these are towards the edges of what SOA is attempting to do as they are about user interaction rather than system to system integration: This is important but not yet core.

What I do not believe we have yet seen is the appearance of a google equivalent (which could be an open source project) for SOA – a company which solves the problems in a radically different and much better way and hence dislodges the good enough solutions. Until that happens the big vendors will continue to push enterprise software the same way they have pushed it for 10 years and more.

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