Continuing in my series on the 2008 mashup predictions made by others, I'd like to talk about a recent ZapThink article by Jason Bloomberg. He makes several predictions about the future of SOA in 2008, to include the sale of ZapThink itself. I won't comment on the acquisition discussion except to say that it seems a bit odd for ZapThink to tack up a For Sale sign like that. I can only guess they are already in the final stages of negotiation and want to boost their price with a little self-promotion, or perhaps want to get an idea of how their current clients will react to the sale.
Whatever the reason, good luck with it.
In addition to ZapThink’s future, Bloomberg makes some straightforward predictions about SOA and mashups. To summarize: The economic downturn in 2008 may cause some businesses to slow down or cancel their SOA initiatives, especially if they are struggling with ways to define the ROI. This will be good for businesses that have already turned the corner on SOA, but bad for the businesses that cancel.
"...For those organizations, we do predict cancellations of SOA projects and deferments of SOA spending, to their detriment. Because after all, their competition might very well be leveraging SOA to be more successful during a downturn, leaving the unsuccessful companies out in the cold."
I agree with both points...to a point. In difficult economic times, businesses will tend to cut back on strategic spending, especially if the ROI is a bit ephemeral, as it can be in Big SOA initiatives. So yes, I suspect we will se a number of SOA initiatives delayed or cancelled.
However, I think this only applies to Big SOA, not to Guerrilla SOA. Guerrilla SOA projects will likely continue forward because their ROI is tied to the success of a specific business initiative, not to some hard-to-define measure of enterprise IT effectiveness. Organizations with Guerrilla SOA projects in the works will still be able to leverage their investment, "...leaving the unsuccessful companies out in the cold." See my previous post on the subject, as well as predictions made by Hinchcliffe and Chappell.
Later in his post, Bloomberg defines a mashup as a "...governed, managed composition of loosely coupled Services within the context of a rich, collaborative, Internet-based environment." Except for the fact that he left out human interaction, that's a pretty good definition. He goes on to say that "...enterprise mashups are what organizations actually do with SOA."
Organizations leverage their SOA investments in many ways. Old-style programmers can boot up Eclipse or VS .NET and use java, C# or other languages to build applications. When used this way the services available in the context of a SOA are really just another API. I'm sure to get hate mail for this, but for an organization trying to maximize their SOA investment, relying on old-style programmers won’t do the trick.
What about portals? Once the portal framework is in place, end-users can customize at will, without depending on expensive IT resources. Making use of a SOA infrastructure will help increase an organization’s SOA ROI. Unfortunately, portals don’t scale as well. Most people want one portal, or if necessary, two or three, but only under duress. See Oracle’s comments on portals. Portal proliferation is a problem that needs to be solved, so trying to increase your SOA investment's ROI by increasing the number of portals is a losing bet.
Another way to leverage SOA investments is through BPM initiatives. BPM and SOA have been joined at the hip for several years. Before SOA, BPM tools could define a process, but executing the process was something else. With integrated SOA BPM end-user could do their jobs while actually in the BPM tool. No more application-hopping. Additionally, with SOA the BPM vendors had a workable standard for integrations. Not every install had to have a unique set of adaptors built specifically to integrate the BPM tool with back-end systems. No more introspecting DLLs to figure out how to talk to home-grown applications. Give the BPM system a WSDL and it could move the world.
As with portals, BPM solutions don’t scale. They are big systems, mostly behind the firewall, built for process gurus to build big supply-chain-type solutions. BPM practitioners need to have training, they need Big IT support and they need to spend a lot of money to install and maintain BPM systems. So while BPM does help businesses get a bit closer to the sort of ROI the EA team promised as a result of Big SOA, it isn't enough.
Now let's talk about mashups. Specifically, business mashups. Mashups are easy to assemble. They are easy to deploy. They scale down beautifully, but scale to the enterprise as well. With new mashup platforms coming on the market, anyone with enough tech savvy to build Excel macros or administer a wiki can build a mashup. Better yet, mashups can take advantage not only of the SOA, but of the WOA as well, opening up the entire world to mashers. Best of all, business mashups put the aggregated data and display elements into the context of an actual business activity. You have the data you need, when you need it, and can take action on the data without having to jump from application to application.
So when Bloomberg says that enterprise mashups will become the killer use-case for SOA in 2008, I want to agree, I really do. But I don’t. First, I think business mashups are actually the killer app, not enterprise mashups. This isn't just a war over verbiage. Enterprise mashups don't include human workflow, but human workflow is a vital part of most applications. Maybe 2008 will be the year that the term 'enterprise mashup' starts to include human processes. If so, then I'll stop harping on business mashups. Until then I'll continue to make the distinction. Second, I think 2008 will be the year mashups get mindshare outside of IT. However, the business won't actually start cranking out mashups until 2009.
I hope I'm wrong and Bloomberg is right.
Good luck, ZapThink, on your pending sale. And thanks, Bloomberg, for your 2008 predictions