Saturday, September 10, 2005

What might have been…


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.

3 comments:

Joanne,  September 11, 2005 at 11:54 AM  

Here are some comments on amazonification from a business process perspective:

As a first effort toward amazonification, is moving the ASU Interactive applications to MyASU a quick fix? The Interactive aps need to be easy to locate and use in MyASU.

An important longer-term goal of amazonification is the integration of tuition and other university charges currently billed through separate systems and offices into a unified web bill. Some options include billing through a single system, e.g. SAAR, pulling data from separate systems and presenting it as a unifed bill on the web(either written by ASU or through a vendor), or maybe move to a shopping cart.

Related to making Continuity an enterprise system and possibly building a web front end and a SIS interface, evaluate whether SIS can be further modified to meet some of the after-21st-day and flexible scheduling requirements.

Derwin September 12, 2005 at 6:13 AM  

Some comments on the comparison between Amazon.com and ASUazon.edu.

First: History. Amazon was founded in 1994. ASU in 1885. One was post Web, one was pre-computer. This matters. Amazon was internet book buying by the web from day one.
ASU had horse drawn carriages, flight was 20 years away and the modern digital computer was 61 years away. It is easy to innovate in a vacuum, you have no choice. And Amazon has done some impressive innovation. ASU has done some impressive redefinitions throughout its history. And we are going through a process of redefinition today. But with heritage and history comes baggage. Conversion is more difficult that creation. And more importantly, mind-set is more difficult to change than technology. The mind is comfortable with the familiar, a computer can simply be rebooted into a different environment, with different software, and implement new and different architectures.

Second is scope. Amazon invented a whole new experience for the buyer. I’d like to take a peek behind Amazon’s technology curtain. Do they have integration across the board? HR, Accounts, and all the little things that make a company run. Customer Relations Management (CRM) predates Amazon’s founding. It’s not like they didn’t know the questions before they designed their solution. What are ASU’s redefinition targets? Students? Faculty and Employees? Courtesy affiliates and external community? All of the above? For ASUazon, are we just talking SIS? Are we talking Student Relations Management (Does this even exist as a term … yet)? Or are we talking about total system integration? Do we have a single unified Portal … including HR, and internal business processes?

Third is structure. I’ll bet that there is an enterprise architecture group at Amazon (I know they have a VP of IT Infrastructure). Is there one at ASU? And I’d also bet that every developer here on campus would love to have an ASU Object Dictionary on their desk, particularly if there was a simple process to extend and enhance the object model. I bet Amazon has unified tools. We don’t. Do we continue to integrate disparate technologies, or do we all choose a single development environment? Bye bye ColdFusion, Microsoft.Net, ASP, WebObjects, cgi … hello Java, JSP, J2EE, xml, xslt, and uPortal?

And finally, there is budget. Amazon did not expect to turn a profit in the first 4 to five years. They had money, and they used it. ASU seems to be on a tight budget. So to get to ASUazon, what do we get to spend in time, money, and risk? How long are we willing to “not turn a profit”? Is ASU willing to innovate? Just give out the call, I know there are many developers willing and able to create.

Cat,  September 13, 2005 at 5:10 AM  

So... who are we? And who do we want to be when we grow up?

A recent brand marketing workshop recently identified these sample brand attributes for ASU:

• Leader
• Entrepreneurial
• Thought leader
• Risk taker
• Bench marker
• Groundbreaker
• Swift
• Flagship
• Leading the charge
• Change agent
• Cutting edge
• Edgy

Is this who we are? Really? What are we doing to live these attributes, to fulfill our vision of the “New American University?” Who’s going to believe these attributes about ASU unless we start applying them to everything we do?

Do you believe?