I love bookstores, especially Borders and Barnes and Noble. I like the coffee. I like the chairs. I usually like the music, but I often bring my IPod instead. I roam around looking at the tables of new releases, wandering around my old favorites on the shelves. I’ll usually grab 4 or 5 titles and head off to a comfy spot for an afternoon’s read. Very occasionally, I’ll buy one.
I do my serious book buying at Amazon.com. I make my own coffee. My chairs are pretty comfortable too, and I always like the music. I like to buy from Amazon because of the browsing experience. Since Amazon keeps track of what I buy, their collaborative filtering is like having a personal shopper tag along, someone who knows what I like, knows what other people like me like, which gives me serious help picking out books. And it couldn’t be any easier to buy. It is a pain to wait the day or so to get the book, but it’s exciting to open the packages when they come. If I was cooler, I’d just download eBooks I guess. And as soon as I find a device I like as much as a paperback, I will.
The thing I like the most about Amazon though is how tight it is; how unified the experience is. Someone’s doing a bang-up job ensuring that the disparate business units involved in creating the Amazon site stay focused on a common goal, use common standards, and link their content together in a common way, to a common back end. The result is anything but common.
Don’t think their job is easy either. There are a fair number of moving parts involved: a Book Catalog, an Inventory Manager, the Shopping Cart, Shipping and tracking, the Wish Lists, Customer Reviews, and the all important Collaborative Filtering. (Leaving aside the whole magical part that translates that final “Buy” click into a charge on your credit card and a book at your door). Each of those disparate functional units must develop code that connects to the common back-end and reaches out to the user through the common portal that is www.amazon.com. And like every tech organization, everywhere, each of those units has different development schedules, differing priorities and needs, different levels of resource, and different views of the customer. Given all that disparity, it certainly didn’t have to turn out as well as it did.
In fact, the first revision didn’t.
A lot of people don’t know this, but before Amazon.com, there was an earlier entrant into the market -- Umazon.com. Umazon had the idea for an online enterprise too. The Umazon people were very smart and very hard working. Certainly not a team to scoff at. They all had successful day jobs running a huge IT enterprise on a gigantic scale. But for lack of some strategic planning, the Umazon project didn't get as far as it might have.
Its a shame, cause they got off to a great start. The team in charge of the back end got some databases and began developing the necessary record structures, trying their best to involve all the other parts of the team. They also spent a little while picking some portal software to ensure that their technical foundation would be strong. In the meantime, all the other groups set off to get their parts of the project off the ground.
The Book Catalog team was anxious to get into the marketplace quickly, so they decided to buy some software from a third-party; it got them up and running pretty fast. They had a prototype in no time and people inside the company were pretty excited. Its integration to the back-end wasn’t very tight, because the vendor didn’t support the right connections, but people figured that could be settled once the record structure got completely ironed out.
Around the same time, the collaborative filtering guys got their stuff running on their own database, and built a cool ColdFusion based front end to it. It looked quite a bit different from the Book Catalog, but the Collaboratives really liked the ColdFusion toolset. They were also interested in getting some additional hooks into the back end, but the database crew had their hands more than full with the first revision of the record structure. So the Collaboratives bought a database of their own and a few weeks later they were in business.
The database guys saw trouble ahead, as several other groups began to push ahead without worrying enough about eventual integration. They tried to enforce some standardization by putting limits on the toolsets they'd support and restricting database access to certain standards, but they weren't always able to make the rules stick. The database guys didn’t have the organizational structure to enforce the rules becasue the other groups didn't report to them.
It's not like the other groups were full of crazy cowboys. It just that they were much closer to the business requirements and the customers, so they felt more pressure to act quickly. They were focused on meeting the needs of their units, and so sometimes the database team's attempts to enforce standards felt like roadblocks. So unless the database team's work made it easier than going off on their own, the tempation to develop something quickly to meet the need was often irresistable.
Shipping got off to a late start on the order tracking stuff, but tried to make up the ground by piggybacking off of what the BookCatalog folks had done. Things were pretty well integrated for a while, until BookCatalog and Shipping’s priorities diverged. BookCatalog got focused on being able to improve browsing by letting shoppers read a few pages out of the book. Shipping needed more information from the inventory control system to make Tracking work. In the end, they split off their own copies and agreed to stay in synch once a day by exchanging a batch file.
Over the course of the next year or so, Umazon.com gradually came on line. Because of the different standards, tools, and delivery dates, Umazon.com’s site ended up a little different from Amazon's. The Umazon homepage was really cool looking, with a great logo (that half the company hated), and a really nice color scheme and fontset (that the other half of the company hated). But the page was little more than links to a set of loosely connected utilities. They didn’t really look the same, or feel the same, and sometimes they required duplicate entry of names and book titles. All that work choosing a technically cool portal, and in the end almost no content used it.
It was more than a little confusing for shoppers. Instead of a site designed to support the book shopping experience (Browse, Suggest, Choose, Buy, Track, Receive), Umazon’s site was a weak confederation of different tools from different areas of the company. There were tabs for BookCatalog, Shipping and Tracking, UmazonSuggests! (the Collaborative guys had wanted the Umazon prefix to go on all the other services, but no one else liked the idea). WishList didn’t even make it into the first release, because they didn’t have the staff (even though it would have been a small add on to the work of the Collaborative team. Nobody knew till it was too late).
Needless to say, users didn’t really get it. It was just too confusing. It’s not that people couldn’t buy books at Umazon – after all the pieces came on line you could do it. But you had to work really hard at it. It was pretty easy to forget a step in the process, or lose track of what you were doing.
Almost no one could figure it out by themselves, which drove Umazon’s support costs through the roof. A lot of the customers just started showing up at the Umazon offices to order books using paper forms. This worked for a while, but once www.Amazon.com hit the net, almost overnight, it was not so much with poor Umazon.
A unified portal is not a luxury. Its a necessity. The unified portal vision drives the interaction of the groups that make it. An uncoordinated group cannot create a unified portal.
Amazondotcomificaton. Its not just a good idea. Its the law.