I was guilty of thinking inside the box.  The old, stale, PC box.

Thankfully Steve Jobs doesn’t suffer from such confinement.  He’s come up with a device which will, in typical Apple-product style, find uses far beyond what our old machinery was capable of.  In his classic book “Zen and the Art of Motorcyle Maintenance,”  Robert Pirsig says that the ancient Greeks, “saw the future as something that came upon them from behind their backs, with the past receding away before their eyes.” If we could turn around now and stare directly into the future, I think we’d see iPads galore in the hands of Wall Streeters, many of whom are extremely busy but need a way to track metrics of all kinds throughout the day.  Applications at present are filled to the brim with alerting capabilities such as email, IM, SMS, and chimes, and these are the best we can do given the current infrastructure; Apple has just handed the users of these apps a whole new way to stay connected.

The iPad offers both wireless and 3G connectivity.  Trading systems are generally locked down tightly, but why couldn’t secure wireless access points be added which would admit an iPad-carrying risk manager to the network?  No longer must (s)he rely on the buzz of a BlackBerry to find out that daily trading limits have been violated.  Now there’s a beautiful 10 inch pad right on the conference table which displays those limits and the proximity to them in real time.

Likewise the trader.  There are so many custom “pads” out there on trading floors already — why not something that’s available off the shelf and that’s far more capable than today’s devices?

Retail trading is another area where the iPad could find a ready-made market.  Many brokerages have written custom iPhone apps or have websites which are designed for easy access from a mobile platform (Fidelity, Schwab, TD Ameritrade, Interactive Brokers all come to mind).  The iPad offers the possibility of a rich touchscreen-based GUI which could enhance the experience for active traders enormously.

I’ve touched on but a few of the possibilites. (This is, after all, just a reply to an article and not an article itself.)  I’ve no doubt that Lab49 will be out at the cutting edge of iPad development as it is with many other disruptive technologies.

Let the fun begin!

Luke met with the good folks at Advanced Trading at SIFMA the other week, the result of which was this article “SIFMA: Cost Cutting, A Double-Edged Sword?” that outlined his observation on the maturity of the purchasing decisions investment banks make (or don’t make!) in hiring consultants: 

Level 1: Lowest dollar cost – is it really the cheapest option if it takes twice as long ?

Level 2: Total Cost of Project – factor time to completion, debugging, compliance, etc

Level 3: Risk-adjusted cost perspective – probability of success for the investment

Level 4: Innovation – the need to bring new ideas to the table

Needless to say, there is indeed a tight correlation between these levels and the timeliness/quality of the final product….

]]> http://newyorkscot.wordpress.com/2009/07/01/innovation-vs-cost-containment/feed 0 http://blog.lab49.com/archives/2671 http://blog.lab49.com/archives/2671#comments Thu, 20 Nov 2008 16:54:10 +0000 Daniel Chait http://blog.lab49.com/archives/2671 Our Surface showed up this week and we had fun unpacking it and setting it up yesterday. 

Now, on to the real fun – developing apps for it!

Well it turns out I was right.  Google Maps now includes New York area public transit options in its directions.  The NYTimes has the details.

Here’s an example of directions from Lab49′s offices to UBS in Stamford, CT (link) :

I chose this route because it includes multiple modes of transport – walking, the NYC subway system, and the Metro-North train.  Google did all that automagically, all I did was enter in the two addresses and click for directions.  Try it yourself!

Building sophisticated educational tools out of cheap parts, Johnny Lee demos his cool Wii Remote hacks, which turn the $40 video game controller into a digital whiteboard, a touchscreen and a head-mounted 3-D viewer.

to read more about Johnny Lee, visit his website

In light of the Société Générale debacle, I expect to see more of these in development. Apama strikes me as a near-ideal match for this kind of application.

Go back and try to remember when was the last time you woke up one day with a brilliant idea: you were going to build “wheel 2.0”! While innovation is our driving force, try to remember if before you started to work on your new wheel, you stopped and asked yourself one simple question: “Why?”

[Note: “Why try to fix something that is not broken?”]

The Classic IIS Affect

Let’s start with a classic example. On a recent project that I’ve been working on, we had to develop a trading module that books and save trades into a database. Given this short description, one would expect that we would use one of the commercial databases platforms, such as Oracle, Microsoft SQL Server or Sybase , which are already supported by hundreds (if not thousands) of software components to help developers to easily work with those databases. Moreover, there are plenty of Add-ons components that were built on top of those databases (by companies who built their entire businesses around it) to support additional functionalities such as versioning, multi-tier transactions and others.

However, we weren’t that fortunate this time…

Instead, we had to work with an in-house proprietary database that was developed for a specific purpose (which is questionable too) and later on was expanded to support other applications’ requirements. This is exactly the point where ineffective innovation comes into place.

Let me give you a short background:

This database was an idea of couple of people who decided to build their own “signature” database without considering alternatives, long-term effects, future cost and others. As long as this database was used at a small scale, where maybe a handful of developers were using it, it was easy to work with and to make appropriate adjustments to accommodate additional requirements by the developers.

Up to this point, its all seems fair. The “innovators” were happy with their own “signature” database and the developers were happy with their own “its-exactly-what-I-need” database. However, this was the tipping point of this innovation and it should have remained within the boundaries of this small team.

UNFORTUNATELY, given their relative success, those guys decided to expand the use of this propriety database and share it with more teams across different groups (and some, like my team, had no choice but to take it by default). That was the point where this small “good-looking” snowball started to roll down the “efficiency” hill.

Here are only few of the problems that we all started to encounter:

• No documentation – There was no place where you could read how to use this database.
• Limited and inconsistent API across multiple languages – Java developers had threefold more functionalities and worked in a completely different mode than .NET developers.
• There was almost no support at all – some of the developers that built the database or the API layers left or moved to another projects.
• All the “innovators” were already working in a different department on a completely different product.

The result: Long and extremely expensive project.

Wait! There is more.

Due to the dependency of many teams on this database, this inefficient innovation will only grow and will increase the cost of future projects significantly.

[Note: of course, none of the “innovators” realized what they did; they were all working on other projects already].

This classic example is only one out of many that I’ve encounter over the years. I’m sure that each one of us has similar skeleton hidden in his own “D” drive (you are more than welcome to share those with us).

Reinventing the wheel – is it a good thing?

Don’t get me wrong. Without people who woke up one day with an innovative spirit to make a change, we would not be living in such a rich “gadgety” / service-oriented environment that we live in today. Simple services we use today are the fruits of those innovators who took nothing for granted and had the ambition to improve the existing. Take Google, which revolutionized the online search, or FaceBook, an even more recent example, for reinventing social networking, as the two huge successes stories.

However, this problem is not with those types of innovators. The problem is with those “innovators” (with all do respect, I have added the double quote) that some “wheel” didn’t fit exactly to their project needs, so they decided to build a new one. While being easy on the trigger, they often lack the skill of evaluating what would be the REAL consequence of designing, building and maintaining a “wheel 2.0” or what could have been changed in their project in order to accommodate “wheel 1.0”.

In my next post, I will analyze the reasons that often starts the Inefficient Innovation Syndrome and what can we [try to] do to avoid it. Whether it’s our own idea or a process that is running within your organization, a small change can lead to great consequences…