Opinion | Stop the Insanity!!!

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

Enjoy!

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…

Dumb Things We Saw Today | Big Data vs. SAAS

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.

Architecture | What is the Cloud Anyway?

You keep using that word, I do not think it means what you think it means.

I was at my doctor and even he was talking about “The Cloud.”  And of course I am thinking to myself (accent and all) the famous words of Inigo Montoya, “You keep using that word, but I do not think it means what you think it means.”

So we cooked up a graphic to describe Cloudiness.  Generally, cloudiness is driven by the ability to scale by abstraction.

More later on how total cloudiness applies (if at all to energy trading).

Cloudiness

Architecture | Crouching Tiger, Hidden Trading System

I am not sure if this is a trend yet.  But it’s worth noting.  Over the past couple months I have talked with a total of three major energy trading entities that all have one thing in common: Projects to “hide” the ETRM system entirely from their traders.  Traders will not use, see, touch or smell the ETRM system of record.  Rather, they will see in-house developed, deal entry and position reporting that is fed by the ETRM system.

So there you go.  Why?  Well, the rationale is pretty straightforward.  ETRMs can be too noisy for Traders.  The trading systems are too hard to configure.  Too hard to get the information they really want.  It is as it always has been.

I’m going to chalk this up to a generalized “Ux” failure.   Ux is short for User Design and something that has been badly neglected in the ETRM space.  Remember that BlackBerry you used to have?  Or, that one you are suffering with now?  Ok, now think of the Apple iPhone.  The difference?  User Design, of course.  Steve Jobs was fanatical about Ux.   BlackBerry does one thing great….email.  That’s it.  Browse, App Store,App functionality…all garbage.  It is not that BlackBerry does not do these things.  It’s that it does these things with poor Ux.  And we hate them for it.

Some suggestions for Ux.

Never Let the Users Design User Design.  Remember that Simpsons where Homer designed a car called the Homer?  User driven, user design nearly always results in “a Homer,” and I don’t mean a home run.  But the users know exactly what they want, right?  Yes, but put those people with a Ux pro to drive out the requirements.  You will end up with something that is functional and easy to use, rather than functional and a pain in the neck.

Never Let Developers do User Design.  Writing code and designing GUIs is not the same thing.  A good developer will nearly always admit that they hate designing GUIs.  Just don’t let them do it.  Every time I see pop-up window after pop-up window, I know that a developer designed the GUI.

Watch For Developer vs. Ux Conflict. If you use a User Design pro there will inevitably be a conflict between the developer and the User Design Pro.  The User Design Pro should win.  The truth is that Ux Pro’s make the developer’s life harder.  Doing cool things with the GUI takes more development effort and one should expect the developers to push back.

So, what about these efforts to hide the ETRM system?  Well, unless the in-house development efforts really put their mind to Ux, there is a better than average chance that they will end up with a poor re-creation of what they had in the first place.

 

Regulatory | Trick Bites Back!

One of our gripes with trading systems is that sometimes they just can’t properly book certain trade types.  Yes, there really are trading systems out there that can’t book Futures.  Yes, there really are systems out there that can’t book spread trades, options and an assortment of exchange products upon which traders have already pulled the trigger.
What do we do if our trading system can’t trade futures?  No problem, we just “trick” the system and book it as a swap. You know, the old “work around.”  Sometimes this turns out OK.  With a little push here and a rub there the P&L

Enjoying work arounds?

all turns out fine.  Fine that is, until someone needs to run a report specific to futures.

Like a Dodd Frank report?  Why yes!

To begin with, if you are in the know, then you know that not only is system tricking done…it’s done a lot.   Every trading company has some work around here or there.   So, remember those futures we couldn’t book as futures so we booked them as swaps?  Looks like Dodd Frank requires us to report our futures as …well …futures.  So now we are going to have to go through every one and figure out which swaps are actually futures and compile them into a report.

This got us thinking that clients will need all trades reported to the CFTC exactly as executed on the exchange.  But as we dug deeper we realized that there is not chance it would be so simple.

Turns out it looks like CFTC can’t book spread trades (as spread trades) either. So that trick we did on spread trades, booking them as swap legs.  Yep, the CFTC wants them that way too.  They don’t want the aggregated spread, just the underlying legs.  Those stellar ETRM systems that have gone the distance and actually book spreads as spreads?  You’re out of luck.  We have to decouple these into their respective swap legs.

Our only suggestion is that if you are holding out on how to do regulatory reporting, it’s a good time to get the ball rolling because there are going to be a lot of twists and turns in this plot.

Dumb Things We Saw Today | Ref Field Constraint

Why the constraint?

We work with A LOT of different systems and run into all kinds of crazy stuff. Feel free to email us your Dumb Things We Saw Today.   Here is another gem:

We were working with a vendor energy trading system and inputting an exchange Order ID into an Order ID Ref field.  Kudos to the vendor for having an Order ID Ref field at all.  But there is a constraint on the field that the OID has to be unique.  If you’ve worked with the exchanges then you know that exchanges only guarantee these numbers are unique for a single trade date.

Opinion | No Strategy is Not a Strategy

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.

Regulatory | The Case of the Missing Execution Time

Execution time please

Still a ways from final Dodd-Frank Rules.  But we can definitely see how they are shaping up.   One issue that is certain for all companies engaged in trading: Execution Time.   Here’s the issue: We were working with a client using one of the larger ETRM systems.  Trades are brought in through a “Quick Fix” custom set of code from ICE and NYMEX and entered into the ETRM system.  Pretty straightforward.   What we are certain of, based on current Dodd-Frank Rules is that Execution Time, or the time that a transaction was actually executed, is going to be a key parameter in Dodd-Frank reporting.  I’d put it at 99% certainty. So here is the problem.  The client’s Quick Fix connection somehow dumped execution time.  The people who originally developed the solution did not think it was an important criteria and did not code it into the ETRM loading solution.   Second, the target ETRM system did not really have any place to put  Execution Time.   Sure, you can load it into a User Defined Field.  But where we really wanted it was in the Primary Position Table where we could report off of it.   The only thing the ETRM offered was trade input time.  But for Regulatory Reporting this is…as they say….not Kosher. It is worth taking a look at how your exchange solution might be able to feed through Execution Time to your ETRM system or wherever you plan on doing regulatory reporting.

News | BroadPeak Releases Fills Aggregator

BroadPeak Partners today released the first version of its Exchange Fills Aggregation component for K3.

“It’s one of the most irritating problems for trading management.   A trader might put out an order for 100 Lots and get 6 fills.   So what was once a simple trade has now become 6 trades in the ETRM system,” said Gordon Allott, BroadPeak’s President.   “We developed a component for our rules engine that re-aggregates fills before booking into the ETRM system.  As always we are focused on referential integrity so traders have access to both the original fills and the end aggregated trades.”

The development of the Fills Aggregator allows traders to more easily view trades as they posted them as opposed to how they are executed on the market.  Likewise it eliminates the ETRM system from additional calculation overhead, shortening the end of day process.  Aggregation is now a standard component in the K3 F1 Suite.

To view a demo of the Fills Aggregator please email Vivek Pathak.

News | K3 Integrates Seamlessly With Zema

BroadPeak Partners announces K3 can now be used to seamlessly manage price movements from ZEMA, a leading enterprise market data warehouse for energy and commodities.  Trading firms relying on ZEMA for market prices can now leverage K3 to manage the distribution of ZEMA data throughout their enterprise.  This gives firms a single point of control for all downstream interfaces, instant connections to internal applications, and real-time insight into any data transmission failures.

“ZEMA is one of the fastest growing price and market data repositories.  K3’s interface makes it very easy to get this pricing and analytical power to downstream applications where it can be leveraged,” said Vivek Pathak, BroadPeak’s COO.

K3 gives the business instant insight into data that has flowed and alerts them when corrective action is required.  It further gives them a simple interface to function as air traffic controller over the network of data being sent from ZEMA to many downstream systems.  Lastly, it significantly accelerates any ZEMA implementation as interfaces with K3 Server take 30% of the effort of building a single point-to-point interface.

Looking to harness your market data infrastructure or accelerate your ZEMA implementation?  Contact us and we can help.

info@broadpeakpartners.com

+1.646.430.5745

 

 

Page 10 of 11« First...7891011
(877) 738-0470