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.

A very brief history over the last decades teaches us that 50 years ago there was nothing in IT: everything had to be handcrafted right down to the hardware itself. Mainframes came in wide diversity, and even the notion of application didn’t exist. Midframes entered the market, followed by client-server, and in the 90’s there was a choice between mainframe, OS400, UNIX and Windows.
Together with standardisation on operating systems, applications started to unfold. Those actually increased in diversity now the operating systems got sunk into the infrastructure layer – you see that everywhere when an underlying layer gets standardised, e.g. electricity, gas and water.
Then, to blanket the IT diversity, packages got introduced. They attempted to annihilate the (little did they know) evolutionary diversity by replacing everything by one package. Needless to say, this package consisted of a wild range of programs and applications itself, but it just bore one and the same name

Did they succeed? Hell no. Of course not. Requirements and customisation needs will persist throughout the next ages. I often compare IT to the car industry but that’s unfair as a car is just a means of transportation. Once your car is your primary and core business, you’ll customise it to death no matter what the costs – check your average F1 club.
So, where do we go now? Do we succumb to the failure of IT when it comes to satisfying our needs for a reasonable price, or do we just foot the bill?

In the light of SaaS, where customisation is at least a lot more limited than we are used to, how grim does our future look?
Well, here’s my answer – it looks shiny bright.
The pain of customisation is in building in that what you want into applications that might or might not be reasonably apt for that. You need knowledge of the business functionality you want, as well as the business functionality the application provides. You also need technical knowledge of the application itself, along with technical knowledge of how you want to solve the riddle in the first place.
It doesn’t get really ugly until you run into limitations in the existing application, its business logic, its usual work flow, and so on, and so on, and so on

Now what, if we leave the application alone? Intact? Just buy it off the shelf and have a go at it?
Well, you wouldn’t have the ability to handle the exceptions that would distinguish your business form the competitor’s, would you?
You wouldn’t – in the application itself

What if you could outside of the application? Of course you’d need to build an application for that, but getting let’s say 80% of what you want off the shelf, and having to build an application to get the remaining 20% in your own greenfield app is something that many CIO’s would be very interested in.
How? You need the information first – the data, the metadata, and all you need.
Well, event processing would enable you to do so. You’d only require a button or so in your existing application, that triggers an event. The event would be pushed outside of the application, picked up by your home-made one, handled and pushed back. Like I said in my last post, Portals are coming back to us and I can picture a web-based screen or frame that is right next to your usual ones, where the user can interact with it

Sounds simple? Yes. Will it be so? For a large part, yes. For a smaller part, not so much. And probably will it be impossible for a minute number of occasions. However, it would greatly, absolutely devastatingly dramatically enormously greatly, reduce the complexity and dependencies within and upon your existing application

Got an upgrade? It highly likely won’t touch your self-made button and the few parameters involved – if it does, it’s the proverbial 5 minutes involved (which usually amounts to a day or two, of course)

What do you think? I am absolutely exited and envision how we can replace everything we have by a whole lot of SaaS and just a bit of event-driven home-made apps. How about you?

(Cross-posted @ Business or Pleasure? – why not both)