The return of the fat client

November 3, 2017

Last night I got a demo of a brilliantly innovative IR derivatives system from the founder team. It prompted some thoughts on the cyclical nature of the software industry, and the return of the fat client. Back in the 90s, when Microsoft still ruled the world, client server computing and the fat client were the dominant model for application development. Often the server tier was simply a DB,  and all app logic happened in a Windows app built in MFC C++ or VB. The rise of Java and the browser threatened that model, and met with a forceful response from Microsoft. That’s a well-worn story, and I won’t repeat it here. Java never delivered on its promise of zero deploy desktop OS agnostic apps; anyone remember Marimba? Instead the browser began its long march toward becoming the dominant desktop client. After the dot com bust it took time for web 2.0 to emerge. For a while there was a debate about Silverlight vs Flex vs Ajax. Thankfully Ajax – the only one not aligned with a major vendor – won out, despite myriad incompatibilities between browsers and unsatisfactory server push mechanisms. Websockets and HTML5 resolved those issues, setting the scene for thin client zero deploy nirvana. Or so it seemed.

Concurrently with these technical developments on the desktop we’ve seen the rise of SaaS. The advance of the browser as client enabled ISVs, starting with SalesForce, to bypass corporate IT departments and server rooms, and deliver apps direct to users, often with UI quality approaching consumer products, and very low entry prices. Now there’s no end of CRM, budgeting and financial management, project management and industry specific vertical solutions delivered direct from cloud hosting to user desktops. Each browser delivered SaaS may be cheap and compelling, but they exclude the possibility of integration and data sharing across apps. Unless the business users buying those SaaS apps gets their IT department involved again to build integrations across the SaaS REST APIs. But that ain’t gonna happen, because the users bought into the SaaS apps to free themselves from the dysfunctional IT depts in the first place, and because of that the IT depts hate the SaaS apps in the same way they hate Excel.

So how does the integration problem get solved? On the desktop of course! We’re now seeing the re-emergence of 90s style app to app interop on the desktop. This time the enabler is not Microsoft’s OLE (Object Linking and Embedding), but proprietary extensions to the HTML5 container. OpenFin’s Chromium based HTML5 container supports drag and drop between apps, and also provides a pubsub bus. DDE anybody? This trend is writ large with the startup’s IRD options pricing solution, which addresses the financial sector’s rates options trading niche in a fiendishly clever manner. Anyone who’s ever stepped on a trading floor knows about the ubiquity of the Bloomberg terminal. Bloomberg’s terminal comes with desktop interop; their Excel addin enables live ticking market data in spreadsheets. APIs do the same for desktop apps, but license terms mean that data can only be used by apps running on the same desktop. That precludes publishing Bloomberg market data to the server side pricing systems typical in the bigger hedge funds and banks. So this startup’s master stroke is to deliver IRD options pricing in a browser client, as an SaaS, and driven by Bloomberg market data. The analytics – the number crunching special source – are coded in JavaScript and run in the browser. Truly a browser based fat client offering a unique solution enabled by desktop integration.

We’re going to see more and more of this kind of SaaS delivered HTML5 fat client adding value with smart desktop integrations. Proprietary extensions like those in OpenFin, or the startup’s Bloomberg integration, will multiply. Proprietary extensions will inevitably clash, and the benefits of zero touch deployment to a standardised HTML5 browser client will be dissipated. It’s all yet another instance of the endlessly repeating cycle in our industry: standards consolidate, and competition differentiates. Standards are introduced to ameliorate the pain of incompatibility, then vendors differentiate with proprietary extensions until the level of incompatibility becomes too painful and the cycle repeats. Intelligent market participants should think hard about where we are in the cycle, and how to get ahead of it. But not too far ahead of course!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s