Category: Software

What the IT at Google Bank would look like

As I was watching the Google I/O keynote presentation, I thought about how all the development tools provided by Google (Google Gears, GData, OpenSocial, etc.) could be put to work to create a Google-powered Bank, and what the IT architecture of this Google Bank would look like.

Here is how I think it could look like:

All user interaction devices, whether it is a teller workstation, mobile phone, ATM machine, kiosk would provide access to the bank via any of the standard Web browsers (Opera, IE, Firefox, Safari).

If access to device-specific functionality is required, it would be done by Google Gears (say for instance, that I want to access the ATM’s cash dispensing functionality, or I want to access the mobile phone’s built-in GPS or accelerometer). Ideally, these devices would be running a single application that would adapt according to the services discovered on the device on on the service cloud. But realistically, they would be running variant of a single GWT Java code base that GWT would compile in JavaScript for browser-based deployment.

Contacting customer support would be done via Google Talk click-to-call buttons. Interactive Voice Response systems would be powered by 1-800-GOOG-411 voice technology.

All these user facing app would leverage a cloud of shared GData services based on Atom Publishing Protocol. These services would be used to retrieve and update any data and transaction: update accounts, customer profiles, schedule payments, withdraw money, consult account balances, etc.

These services would be available to any developer who registered for an API key to create new 3rd party applications, with online documents, code examples, tutorials, videos, etc. There would be a related developer challenge that would award prizes ranging from $25K to $100K to motivate developers to create 3rd party applications. Google Bank would monitor usage and success via the API key, and acquire the apps that can contribute the most to their bottom line or user growth. OAuth would be used to allow 3rd party apps to accesss customer data without the user having to give away their Google login/password.

OpenSocial would be leveraged by Google Bank to provide an easy framework for friends to share bills, family member to send money to one another via any device, and to loan money to friends/families or friends of friends. Google Bank would use this data to provide preferential loan rates or optimize transaction fees.

Google Bank analytics would analyze my transaction patterns, build nice spending usage pie charts for me, and suggest relevant ways to save or make more money via competitive offers aggregated in Google Shopping. Bank marketing managers would use Google Bank analytics to analyze usage patterns, create marketing campaigns and target specific demographics and customer types in Google Adsense.

And last but not least, users would be able to search all their personal data using a simple one input field user interface.

Did I miss anything?

The problem with banking innovation and how to fix it.

Allen Weinberg has a great report on the first day at Payments 2008 that confirms some of the thoughts I’ve had in the past few weeks: that non-banks are becoming the primary source of banking innovation, threatening to relegate banks to mere accountants.

Allen cites the difficulty for banks to hire innovative employees because their lack of coolness, and I partly agree, but I think that is a bit too imprecise. It’s a bit like saying “We failed b/c we are were not lucky”. I think smart innovative employees go to companies that have an innovative management environment and culture, and there are very practical ways to create such an environment and culture, if the top management wants to.

To me such a culture starts by embracing the facts that:

  • Committee planning does not work for innovation because most innovations fail and slight differences between similar projects can be huge key factors of success, and as a result it is impossible to predict from which team innovation will come from.
  • People with innovative ideas (ex. new online service, new investment theory) as well as execution capabilities (ex. coding, sales skills) are a company’s greatest human asset and should be given opportunities before they leave and join a company that does.

Such an innovation culture consists then in implementing a management policy where such people can submit their plans, get a green light to allocate part of their time (whatever their direct manager says) and get a bootstrap budget as necessary. Then, just like a good option portfolio manager, define progress/success metrics, and allocate more resources to those with the most traction. And finally, reward success. All of this is something Google seems to be doing very well.

Banks are now at a most critical time and their ability to innovate in sustainable business models will be key to their survival. Nouriel Roubini noted this morning that banks’ unsustainable “originate & distribute” business model of the last few years is crumbling with the broken “securitization food chain”.

Banks are social intermediaries, and as a result, social services that focus on social lending or social saving pose a major threat to them, but could also turn out to be a major opportunity if they manage to re-intermediate these relationships and combine it with their unique competitive advantage: creating money from thin air.

Think for instance about the idea of a “college car” savings account solely dedicated to buying a car and that grand-parents could contribute too knowing where the money would end. Think of the negotiating power the bank could have by aggregating all the buying power behind these savings account and exchanging secured rebate from car manufacturers with secured future sales. This is what SmartyPig does, but environment/culture aside, it seems to me much easier to do it from the inside of a bank than from the outside. John Gaskell, SmartyPig co-founder was quick to comment that they have a patent pending on this process, so banks may actually not have this option.

Think also how a bank could leverage the fact that 50% of your student loan on a peer-to-peer lending site comes from your mum and dad, and grand-parents, and how little risk it would be for a bank to lend the remaining 50%, especially if the bank gets preferred re-payment rights.

Banks have some of this social data, in a way that is most likely much more authentic than a Facebook (think about all the documents you need to provide to open a checking or brokerage account compare to what you need to provide to open a Facebook account). It is just a matter for them to put in place the right environment and culture in place to attract people.

If they cannot change their culture, their next best bet might be to do what Apple or Facebook do: expose some of this information via easy-to-use APIs in a way that is more secure than their startup competitors. Then, allocate a VC fund to fund startups using this API (which is equivalent to buy an option to invest more/buy out the most promising ventures later).

To open source or not? or to do both? Open source as market segmentation tool.

Several years ago, I found myself confronted with the decision of whether to open source or not the software of a company I co-founded. While I could find considerable literature on the strategic benefits of open-source freeware as an enabler modern version of the razor and blade strategy (giveaway the client or development tool or razor, sell the server or the runtime or the blades), our software was not lending itself very well to such a separation.

My question was rather: if we have to choose between open sourcing blades and razors or nothing, what model would maximize our revenues, given our target market?

By elaborating on the simple notion of “why giveaway something you can charge for”, I developed the chart below to help me discuss the decision with my colleagues. The idea is to not view open source as an all or nothing strategy, but rather as a marketing technique to segment your market and maximize revenue, except that in the open source case, the revenue is mostly intangible.

Diagram of different segment of customers depending on their budget size and perceived value of the software

According to traditional marketing segmentation strategies, customers with large budgets and who have a high perceived value of our software should be charged for it fully and get all the features and rights; and customers with small budgets and who have a lower perceived value of our software should be charged less for a slimmed-down version of the software.

What’s new here is the category of users who don’t have large budgets themselves (the boss of their boss may have as it is the case of developers) but who see a lot of value in the software. These guys may not be able to sign a check, but they are able to bring more eyeballs to fix bugs, post feature requirements that are common to all users whether they have a checkbook or not, or simply spread the word about your software at the fraction of the cost and in a much better way than any PR firm. That’s not direct revenue, but certainly contribute to higher margins by reducing the costs of goods sold.

In most cases, the distribution of target customers (as it was the case for us) is such that a single model (commercial or open source) will dominate:

Diagrams representing 3 common cases of the distribution of customers according to their budget size and perceived value of the software offered

But if the distribution of customer types is such that a single model does not dominate, this model can actually be implemented using dual licensing, where one category of customers is segmented from another and charged differently, by offering both a commercial license and an open-source, usually GPL-like license. What’s even better is that customers are let to choose which category they belong to (actually their lawyers tell them).

Designing a successful Web API

Designing the most widely adopted Web API for a particular functional domain does not merely take to offer the best and most specialized functionality at the best price, as reading Adam Smith would suggest.

It takes two additional things:

  1. reducing the cognitive load on the developer using the Web API, and
  2. reducing his risks of using the Web API.

Reducing the cognitive load includes:

  • Making it easy to find on search engines
  • Not requiring registration for an API key to get access to a version of the API that is not production grade (for instance,  a version that is much slower than the production version)
  • Providing multiple representations (XML, XHTML, JSON, plain text, binary, etc.) for messages and multiple language bindings for the most popular languages in the target developer community
  • Good documentation, including a step-by-step tutorial
  • Examples with source code
  • On-line test tools that allow developers to test the functionality prior to coding
  • Building upon what target developers already know. Depending on the target developer community, this may mean starting with a REST/WOA API or a SOAP/SOA API.
  • Building upon what API users have already learnt so far about the API: learning one functionality should make the next one easier to learn. This includes using precise semantics and re-using them consistently, defining and sticking to naming and message structure conventions.
  • A variety of one-to-many medias (wiki, archived mailing lists, chat channels, etc.) for user-generated support and documentation.

Reducing the risks involves:

  • Being very clear upfront about what the API does and does not and how it compares with others (to reduce the perceived risk that the developer will spend time on something only to discover down the road that it does not address his requirements).
  • Ensuring the highest quality, up-time, availability and performance for the production version, and providing evidence of your commitment to these goals by using long betas (1-2 years) for new versions.
  • Ensuring backward-compatibility: code written for the 1.0 should still work when the 3.0 version of the API is out. This means that your application should support 1.0 to 3.0 concurrently until no one uses 1.0 any more, and that versions should be explicit in URLs (ex. http://mycompany.com/webapi/1.0/…).
  • Providing evidence that the Web API will be around for some time, because it is backed by a sound business model that can sustain its growth, maintenance and developments.

Notes on Jeff Nolan’s Software VC Outlook for 2008

Jeff NolanBryan Stolle of Mohr Davidow Ventures wrote this piece on investment opportunities in software for this year. Here are my takeaways:

  • An innovative business model (ex. SaaS) is not enough. Focusing on solving an urgent, valued, critical business problem first and using/combining known models that fits well the solution requirements is the key of any successful venture. For instance, some companies like SaaS ease-of-setup but they don’t like having their data in the cloud. Their need can be answered by combining SaaS model with the appliance model. I think this should be particularly seducing to the ultra-conservative financial services industry.
  • Actual operations globalization and decentralization of improvements (“IT consumerism”) is a driving force behind new software investments. I wonder if that goes with corporate culture finally moving from a Stalinian management style to actually applying survival-of-the-fittest strategies to management, operations and innovation issues: instead of a management by committee where a handful of people that are not users are tasked with choosing a software product for the whole company, actual users can pick products from the Web for free, start to use them, integrate them with internal products, add new functions, have other easily build upon. In the end, the picked product(s) is the one that is most used and driving most user satisfaction and efficiency.