the web application as a commodity
technology December 29th. 2007, 4:32pmI'm remembering a conversation I had a with a few of my co-workers during my last few days in the bank. We began discussing my plans for the future, but at some point, the conversation changed to internet banking applications and why in God's name every bank feels the need to build and maintain its own solution from the ground up. A couple of different theories were tossed about -- highly specific requirements, the need to differentiate with unique functions -- but in the end, it seemed like no one could think of a good reason, or at least not one that would justify the enormous financial costs and manpower requirements for developing and supporting such a beast. Most banks offer the same set of functions, so there's very little differentiation at that level, and the requirements for most direct channel financial systems are driven by the same forces in most cases: savings through customer self-service, security requirements, regulatory restrictions, etc. Hmmm, maybe banks just really like spending money?
I've been thinking about that conversation quite a bit over the holidays, and it seems to me that the big takeaway has less to do with some inherent truth about financial services providers but rather about businesses in general. On one hand, business stakeholders want to believe that the ideas they're proposing during the conceptualization phase are something new under the sun, something that really blows the competition away. In many cases, IT departments reinforce or support these ideas, either by not being outward-looking enoug or having a serious case of not-built-here syndrome. Or maybe just by not caring enough to bring it up. In the end, the result is often the same regardless of which forces are at work: more coding, more testing, more support, and more cost just to have another been-there-done-that site.
As DHH likes to remind us, "Your application is not a unique snowflake." You're not Amazon or Google or eBay, and chances are that you are not working on a problem that hasn't already been solved, at least partially, by someone else. (Unless of course you are Amazon or Google or eBay, in which case thanks for reading my blog and please come again.) We're already well past the point where having access to a wide range of standardized, high quality, and in many cases, free infrastructure software is interesting to us, and so the next step would seem to be doing the same with more complex systems. Blogs have already largely succeeded in turning web publishing into a commodity, and only a complete newbie would consider designing and developing a content management system from scratch as his Plan A with some of the great open source packages available today. But what about other types of systems that are still developed as custom software far too often: e-shops, auctions, e-newsletter publishing, adult websites, and so on? Why haven't we stopped building these over and over? Do you really think that you've figured out some new wrinkle for the online shopping cart that hasn't been tried already?
The online banking example remains, in my mind, one of the best as it's practically a "perfect storm" of conditions under which this kind of standardization would produce maximum benefits. There are a large number of unique implementations which, with the exception of underlying infrastructure, share basically nothing and deliver almost all of the same functions and have many or most of the same non-functional requirements - i.e. high level of security, regulatory requirements, etc. And applications like this are expensive - to develop, to test, and to maintain.
In the coming weeks, I'm going to be giving some additional time and thought to this concept and trying to come up with a few more posts on topics related to this one. It's probably a little ambitious to think that one could solve any of these problems once and for all, but the productivity savings for even a few instances of a specific type of application could be tremendous.