The Roadmap to 'Hadoop in the Cloud'

The Twitter ball started rolling again just now. Matt Asay posed an interesting question about Forrester suggesting Hadoop isn't a great fit for the cloud. (Even) without context Vijay Vijayasankar and I started firing off questions and answers which inevitable led to my promise of writing down the transition plan for it

Here it is

5+ garages to service your car? Sure

[Image by Expressive]

After a very lively conversation with Holger Müller I decided on "posting it up" - Twitter is fine for conversations but sometimes the 140-char limit just doesn't cut it.
We discussed Integration, within enterprises. Along the analogy of a garage, we found out that every enterprise has more than a few garages "to serve their car" - meaning integrating their applications

Yes that can be true, but it doesn't need to be - some of the work I do involves "Integration rationalisation", meaning bringing back the number of Integration solutions to -preferably- one

Holger told me what is happening, and has been happening, in his world - and I don't disagree with his facts. I just think that there are far, far better ways of using your time and money. "Free Integration Tools" you get with purchasing an application or ERP module don't always usually mean that they are

A pyramid scheme is bad form, Cloudwork

As some of you might know, or rather, should, Integration is my middle name - you might even call me a one-trick pony and I'd take that as a compliment. So, when I saw that Cloudwork offers unprecedented integration (cough), I signed up immediately! I was even so enthusiastic, I even forgot to use a fake identity - and very much regret that now

Cloudwork didn't have me sign up. No, Cloudwork baited me into giving away my email address, so they could decide themselves when to send me that valuable invite to their beta:

How and why common sense will beat REST

In my previous post I described how REST would replace SOAP. If you paid close attention you will have noticed that I actually didn't say anything in favour of REST, but everything at the expense of SOAP.
Because it indeed seems like REST will be the new SOAP - which is in contradiction with the idea that today's Enterprises that have any form of Service Oriented Architecture will replace their current implementations by those fit for the future

Because "REST" just doesn't make any sense in that context. Mind you, I'm talking about the REST that the low-level techies hijack; exactly what I described, i.e. JSON with the four HTTP verbs. Not the REST as Roy Fielding intended, i.e. a verb-independent style. Apart from all the heavy caching on every side of any connection, which really enabled the scale he was looking for. Without cache, there would be no Internet. Period.
And in case you want to know what Roy thinks of the current hijacking of REST, just read this and this

How and why REST will beat SOAP

In the past weeks and months, the REST versus SOAP debate has flamed yet once again - however, the balance this time definitely is in favour of REST.
So it seems like REST will be the new SOAP - meaning that today's Enterprises that have any form of Service Oriented Architecture will replace their current implementations by those fit for the future

That would mean, to a good extent, replacing XML by JSON, and SOAP RPC by HTTP's CRUD: PUT, GET, POST and DELETE

Resource identification is not a REST invention

An article on programmable web - pointed out to me by Fred Verheul (thanks Fred!) - gave me an adrenaline rush.
It was so full of bollox that I almost started to hyperventilate - which is a pun on the abundant use of the word hypermedia in that same post

Let me just quote one part of the post:

This subtle shift in the source of application control information makes it possible for the same client code to recognize and execute new features as they appear over time without the need for patches or downloads

The post contains more nonsense like this. Let me quote yet another brilliant piece, and be done with quoting:

How CEP will make SaaS the killer app

I got the insight at TIBCO's Transform event I blogged about yesterday - how we can finally solve the Customisation Riddle we've been unsuccessfully combating in IT for decades.
Software as a Service is breathing down our necks and guaranteed to replace quite a few on-premise apps in this decade alone. Starting with your tertiary (cleaning, reception, catering, leasing) applications and also your secondary ones (reporting, payroll, timesheets and maybe even some HR), it is likely to halt at your primary systems that support your core business

Why? Because the need for exceptions increases between the three types. Yes you can customise your SaaS and many will do so in the beginning, but it will only make your SaaS more expensive in the end - someone has to foot that bill.

TIBCO Transform - it says it all

I attended TIBCO's Transform event in London.
Located at the Westminster Bridge Park Plaza hotel, around 600 people were there. Kicked off by Raj Verma, Senior VP of worldwide Marketing, a 2 hour session started that never bored for a minute. Very smoothly Raj led us through a full history of TIBCO, showing impressive figures like a 21% CAGR over the last 15 years, reaching almost a billion dollars in revenue with currently 3,000 employees

Having spent $130 million in R&D last year, the total R&D sum over the years accounted to $1 billion - a huge amount that proves how serious TIBCO is about innovation and fulfilling their goal of "making this world a better place"

Hybrid mobile apps will conquer the mobile enterprise

[Image by HLundgaard]

There is a difference about how we thinks things will evolve, and how they do. I've been wondering about Mobile and app stores for a while - they seem contradictionairy.
Mobile has taken such a great flight because of lowered cost and increased availability of Internet for mobile, the old-fashioned telephone has turned into a smartphone with the power of a desktop

So, with all this ubiquitous Internet around, what is the next hootest thing for Mobile? App stores, where you can download applications onto your mobile! Isn't that odd; why not browse to an app in the cloud?

Brian Katz wrote a great post on this, and I'll to it here

Simple Service Enterprise - part 6

In my latest post, I recapped on the previous posts and started to take Integration from a business point of view. I'll continue to do that here, and try to mix in technical details without it getting too confusing. Wish me luck!

Here's the conversation again:

Simple Service Enterprise - part 5

In my first post on SSE I explained why and how I want, and can achieve, and have achieved, an Enterprise Integration paradigm that will give you a device-agnostic, platform-agnostic, tool-agnostic architecture that will free you from being crushed by the two tectonic plates in IT at the moment: diversity in devices, platforms and tools on the inside, and diversity in devices, platforms and tools on the outside

In my second SSE post, I explained why the approaches of the last decade and more (XML, ESB, SOA and SOAP) have failed, and in my third post I dared to state that REST is never ever going to be a solution to solve the issues either.
The reactions I got to that mainly showed me that myopic perceptions persist across techniques - yet replacing SOAP by REST and XML by JSON without questioning the business value of any of those is now being undertaken by the most zealous, and I simply won't have it. Not on my watch

Simple Service Enterprise - part 4

Today we'll take a REST from REST and I'll touch upon one of the issues I ran into today: the two types of data there are. REST assured however that at least a few of the next posts will be about yesterday's topic, as it has led to fierce debates here and there over the course of the day. Yes, pun intended

There are two types of main data: Master Data and Transactional Data. And both have very different CRUD models, requirements and needs

Simple Service Enterprise - part 3

My previous post showed the fundamentals of information interchange: exposing business functionality, currently encapsulated in the back-end, to the outside world via services. These services are a one-to-one translation to back-end functions, which are one-to-one translations to business process steps themselves: the smallest level of business transaction.
I also showed that the How of exposing these services, e.g. in which format, largely if not solely depends on a healthy amount of opportunism

This post will explain why REST is a bad idea, while taking the previous one a level deeper

Simple Service Enterprise - part 2

Yesterday's post was about Simple Service Enterprise, and showed the basics: to keep up with the growing diversity inside and outside your enterprise for getting the same functionality on different devices and platforms, you need an Integration layer (the red in the middle). Can't argue with that, point-to-point integration is a neat quick and dirty solution for very small IT landscapes and doesn't scale cost effectively

SOA attempted to do so via ESB, but there a few reasons why that failed:

Simple Service Enterprise - part 1

I plead for a Simple Service Enterprise.
One that is ruled by Business, not IT.
One that is interoperable with any other business, customer or consumer, regardless of the platforms they operate on.
Regardless of the vendors that dominate those platforms.
Regardless of the programming languages used on those platforms.
Regardless of the devices used.
Regardless of the operating systems running on those devices.
Regardless of the programming languages used on those devices

I wanna have it all, for free - or almost free. I want a fuss-free, cost-efficient, business that scales horizontally, vertically, diagonally even if that's what I need; because either my customers demand it, or it allows me to gain market share - be it regaining lost share, cannibalising existing services that will be cannibalised by others if I don't do it myself, or simply gain market share in new markets

And I need IT to follow me where ever I go, sustain me all the way, not in the future, not in the near future, not when ever their partners decide to, I want it now. NOW!

I sympathise with you - and offer the solution right here

SAP gets the Future of Integration

OK, I'll admit it: this title is heavily (heavenly?) influenced by the previous Easter weekend - yet has no relation to it whatsoever. Or has it?

Let's skip the usual introduction, here is the message from Vishal Sikka that absolutely thrilled me

@MartijnLinssen @steinermatt we do.The Gateway. It will simply be services in HANA.Also PI, NW rules engine, MDM, EP, all in or on HANA
— Vishal Sikka (@vsikka) april 12, 2012

I have never been a big fan of SAP. I presented my Enterprise Integration 101 at Sap Inside Tech NL last year, and the Borg picture of poor old Jean-Luc Picard is some representation of my feelings regarding any (ERP) monolith

Yet, after this tweet, I have been turned. Into a Borg? Maybe - I just couldn't care less at the moment

Why API's suck, and what they lack

The Social Media Movement is slowly moving towards monetisation. Social Business, yes even Social Enterprise, is nigh.
Infographics bite the dust in an ever-increasing frenzy to prove that social is here to stay, to rule, to conquer the world!
And as yet another evidence of that, API's are brought forward - by the hundreds, no the thousands - to prove that the Brave New Open World has finally (yeah, really finally this time, right?) come

Well, I don't think so. API's suck - big time

Will SaaS kill ERP? No, but it should

It's been a busy few days. First a post on ZDNet by Eric Lai invented a few problems for Cloud, or rather SaaS, and especially multi-tenancy: inflexible, less secure, less powerfull and maybe more costly - is what Eric claims multi-tenancy SaaS to be.
Thomas Wailgum neatly nailed that via a counterpost, as did Frank Scavo, to whose post Eric commented, and back again

The circle of Inspiration? Yes, it evolves hardest and finest on Twitter. And here are my thoughts: we need to grow up

SAP, Integration and Star Trek: the future is now

I commented ranted on an SDN post yesterday. Submitting it failed, and I lost the +/- 500 words. A bit more miffed after that, I wrote the comment anew in Notepad, and copy/pasted that - it worked.
I got a few reactions, some of which inviting me to post on the topic on SDN via a blog post in stead of just a (lengthy) comment. While I appreciate the invite, I'll just do it here for now

Pervasive's Integration World Europe 2012

I was at Integration World Europe 2012 today, organised by Pervasive at the Cumberland hotel in London.
A nice environment and a party of a hundred plus, today's topics were Big Data, Data Integration, Cloud and Strategic Business Solutions.
Clear divisions were made on Cloud: IaaS, PaaS and SaaS, and public, private, community and hybrid

Shawn Rogers from Enterprise Management Associates showed an extensive amount of tips and tricks on how to make sure you get the Cloud solution you need, being honest about the small print. The 50-page report he squeezed into one presentation showed many insights, and I'll certainly study it