Sometimes I miss the 1990s. Building websites was so easy. Half the stuff was just brochure-ware: you'd use a website design program, FTP up the web pages, and you were done.
If we ever needed to build an actual interactive application, a designer would simply create something in Dreamweaver. They give you the HTML, you'd get the userID from a cookie, and you'd write a program to spit out that HTML. You might have to build up some SQL to get some table data, but the whole process was drop-dead simple.
Then suddenly front-ends got very complex and our database designs started to change under our feet, and the whole system got hard to maintain. We abstracted out the database with object relational mappers (ORMs) -- classes that would load the code from the database given a simple ID or query -- and our designers began giving us mockups that were PDFs and GIFs. On the front end, we separated the design from the content with cascading style sheets and content management systems.
But ORMs had a problem -- performance. Not only did they execute far too much SQL to load a single dataset for a table (think: one SQL statement per object -- or more) but when we got into multiple users at the same time, the whole system fell apart.
Enter web services
More than that, there are people building and selling applications on top of open APIs. ScoutPal is an independent company that has wrapped Amazon's APIs into a web page. For a small monthly fee, you can use your iPhone to scan a barcode, and Scoutpal tells you what the product is selling for on Amazon used, and how often it has sold lately. This could turn a morning at the library's used book sale into an entrepreneurial exercise. Or you could take none of the risk, and use Cash4books; these folks use an iPhone app and give you a straight-up price, and then they try to sell it. Of course, I expect they connect to several APIs, like eBay and Amazon, on the backend, to figure out if the book will sell, and for how much, before making you an offer.
It's not just Amazon. In the past 12 months I've met with teams at Zappos, Intuit (think Quickbooks Pro and Turbotax), and Royal Caribbean. Every one is creating an external, services-based API. Third parties that hit those APIs get to create entire businesses and provide a living for themselves, while funneling traffic and sales to the parent company.
Meanwhile, services have another advantage: They can be consumed by anything. When I was at Socialtext, we took our entire micro-blogging product, Socialtext Signals, and re-wrote it as a desktop application that called services that already existed. The original application took months to build, while the desktop app was a working model in less than a week, deployed in under a month.
What does this mean to me?
As the web continues to evolve, it also continues to be diverse. There is no law against building a SQL-based site or in running a simple content management system. Bigger organizations, though, will find they can tackle complexity by wrapping applications in services -- and pick up customers and partners by making those services external.
There's an opportunity there. Is your team taking it? What, how far, and what's next? I would love to hear about it.
— Matt Heusser is principal consultant of Excelon Development.