I travel a lot. Mostly, when I travel and need a car, I get one through one of the major vendor's premiere customer program, meaning that I get to walk right to the car and drive away without much formality. Which is a good thing, because every once in a while, something is amiss and I have to go to the counter. And that entails dealing with rental car IT.
The amount of information you need to rent a car seems pretty small. Even if it's not, it's very well defined. You'd think that they would have the process honed; it is, after all, the primary thrust of their business. But watching the sheer number of keystrokes that the counter attendee must perform to put me in a car is astounding. The same is true when you bring it back. It's like they are typing the great American novel. What could possibly require so typing? They know who I am. They have all my credit card, insurance, and driver's license information (enough that they'll usually just let me get in a car and drive away). This isn't confined to a single rental car company either. I've dealt with a bunch of them and they all have an enormous amount of data entry.
Unlike a lot of problem domains in which I've specifically worked, I don't know for sure what's going on for rental car companies. But here's what I suspect: their IT infrastructure is strangling them. Ironically, many of the companies that embraced IT very early on (i.e., in the mainframe era) are suffering a lot now. Much of the interest in SOA derives from the desire to get out of the deadly embrace of fossilized, astoundingly brittle IT infrastructure.
Closer to home, I've recently been doing some consulting at a large company, helping them define their evolution towards a better tomorrow. I was talking to one of their senior IT staff, and I mentioned that it seems like they don't have a really good idea what their users need software for, and that maybe we should go talk to them. He looked at me like I had a new eye sprouting on my forehead, and said to me "We've tried talking to them -- they don't know what they want, so we have to define it for them. You can't be so naive to think that we can actually talk to the users." At this large enterprise, software is its own ecosystem. The users of the software almost never come up in meetings. Instead, it's a gigantic plumbing exercise. What's ironic is that this particular company is primarily run on information. Yet, they are so far down the rabbit hole of plumbing and complexity, they have managed to create mountains of rubbish. They are in the deadly embrace of accidental complexity, not essential complexity. My coworker and I identified their IT needs for the entire enterprise as small to medium, if this were a green field. But, of course, they have information trapped in mainframes, in several different formats of databases, in packaged applications, and scattered hither and fro, like lots of enterprises.
By way of trying to get them to rethink some of their decisions, we tried (and were marginally successful) in getting them to define some core principles, like simplicity and flexibility. What was funny about that exercise were the looks we got from the no nonsense King of IT: "Of course, we want things to be simple and flexible -- why are you bothering to tell us this?" Yet, in the next sentence, they are talking about spending 3 million dollars on a packaged application to help them with one small part of their business, rather than building it themselves (which we all thought would be cheaper but take longer). That's $3,000,000. But, of course, the packaged application talks directly to their databases, meaning that we can no longer freely make changes to the database without breaking the package, meaning that we can't evolve the database, meaning that we've lost both simplicity and flexibility. Over and over, they complain when we talk about rethinking their priorities, then turn around and make the same decisions that got them where they are now. Frustrating!
At another company I did consulting for years ago, they had a special mainframe application that handled one part of their business. I don't know how much it cost, but it had to be a lot because their vendor came to them one day and said "Look, we really just can't take any more money -- we're bloated and frankly we can't figure out how to spend all you've given us already." Instead of taking this opportunity to rethink how this part of their business works, the found another mainframe application that did the same basic thing, and spent 43 million dollars changing around the life support for this thing. Fundamentally, the problem they were solving wasn't that tough. I know; we were working on a piece of it and got a good feel for the whole thing. They were so drowning in the accidental complexity of the way they had always done it that they couldn't see the actual problem anymore. I walked into a conference room at one point, and saw a diagram that literally covered the entire wall with boxes, lines, and 8-point font describing the enterprise architecture (no, sorry, Enterprise Architecture). When one of the client developers walked in, I said "Wow, it's a good thing you guys dismantling this mess" to which he replied "No, that's the new one we're going towards". Decisions like this mean I have to spend my time in long lines in places like rental car counters.
Going back to first principles is hard, and many companies think it's too late. I've been involved on projects where getting back to a simple solution takes years. But it's worth doing. Otherwise, the company will drown in self-inflicted complexity, when IT becomes a governor on the business rather than a strategic advantage. When that happens, some other company with nimble IT will eat their lunch. Software can be either an asset or a liability.