In the ’90s there was this crazy person on the TV. No Really. Some buzz cut, buff woman named Susan Powter (if that’s her real name). And she had these totally insane infomercials that forever changed the phrase “Stop the Insanity!!” Far be it for me to comment on stopping the insanity through more insanity, but I was thinking about that infomercial when thinking about integration problems.
Albert Einstein, reputed to be a very smart guy, said that insanity is, “doing the same thing again and again and expecting a different result. “ And that my friends is what we have been doing with systems integration. We throw out custom code to connect systems again and again and then wonder why we spend so much time mopping up the mess.
Around 2000 some pretty cool integration tools (read TIBCO et al) hit the market. We thought these were a Godsend. But they turned out to be these behemoth proprietary messes that took three times as long to integrate and failed miserably. Companies spend $300 Billion annually on systems integration. Of this only about $25 Billion is spent on integration tools. Why are 92% of integrations custom code? Simple, these tools take way too long to implement and cost too much. The business is not going to wait, and an IT manager is not going to bet his or her career on a project with a 70% failure rate. So we task a developer to bang out a custom interface. It gets done fast and cheaply to start.
But it also comes with the custom code problem. A friend of mine who also happens to be a CIO calls this the “bag of snakes” problem. When you do something like bang out
custom code (conveniently without standards, documentation, management tools etc…) it is like the developer handing over a bag of snakes to the CIO with a wink and a smile saying, “enjoy!” If you want to make this integration work you are going to have to open this bag of snakes. And that’s the insanity we have to stop.
Ok, I’m going to get off my soapbox, but suffice to say that is exactly what we are trying to do with K3. There are seven components to every integration. We have all seven of them completely off the shelf in K3. And with that I will end…except that thanks to this post our marketing person is now going to be asking me for a white paper…
Raj De Datta drops a really big buzz word in this TechCrunch article.
In a nutshell he’s calling out a supposed battle between “Software as a Service” (SAAS) vs “Big Data” (what he is calling BDAs or Big Data Apps). Maybe just trying to stir up controversy where there is none. So here is the truth.
SAAS: The distinguishing feature of a SAAS application is that it is accessed via a web services API. This is a mechanism of delivering software functionality. That’s it, nothing more.
noSQL: “Big Data Apps” or “BDAs,” as he calls them, already have a name: noSQL. This is a database structure and means of quickly processing/scaling large data. (see Big Table in Plain Language). That’s it.
So to suggest that noSQL will kill off SAAS means essentially that somehow noSQL will do away with the need for software delivered over the web? This makes no sense; they aren’t mutually exclusive. It’s like saying that digital cameras will end the need for special lenses. Instead, the future will be good noSQl using SAAS to empower business analytics like my 1 year old using his finger, using a tablet to learn the alphabet…and it will be awesome.
Raj, did you mean to say that noSQL will kill relational databases? This is at least debate-able material.
We met up with some executives of a large asset based company. They have a HUGE fleet of delivery vehicles. When we got on the subject of their fuel use, I asked them what their approach was to hedging. The answer: no approach.
- Build Market DNA
More discussion and it turned out that this was not actually true. Their hedging approach is to pass all the costs along to their customers in the form of fuel surcharges. They are traditionally “old school” and hate the idea of “being in the fuel business.”
Fair enough, but it got me thinking about different strategies. The structure guy in me went immediately to a “participating” structure. This is simple enough. You lock in a year’s worth of fuel (Futures/Forwards) at a fixed price. Let’s say RBOB at 3.00 a gallon. Then you add on a RBOB put option at, let’s say, 10 cents /gal. So, the company’s all in price is $3.10.
So, if prices go up? This company has capped itself with the futures at a fixed price. If prices go down, the put options come into the money and pay, effectively allowing the company to “participate” in lower prices. This will contain fuel charges and prevent a spike by keeping delivery constant and low. More than likely lower than their competitors who have similar no policy policies.
So, should they do it? Well, there is the real problem here: this company is missing key market DNA. I don’t mean to sound cocky, but I’ll bet a steak that 3/4ths of the company executives cannot come within 10 cents of the current RBOB price. The DNA just isn’t in place. Until the DNA is there, things like participating deals are pie in the sky. Can a company like this build market DNA? Sure, but nothing is really broken, so the motivation is lacking. There is so much momentum behind the status quo that I’m doubtful even simple DNA building has legs. It most likely won’t be until one of their competitors makes the leap that it becomes a big enough problem to solve.