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.
Subscribe to:
Post Comments (Atom)
11 comments:
Great post. I really don't have much else to add. Keep up the good work.
Excellent insights, Neil. I see this sort of thing all the time on my projects as well. Generally, it's within the first day of the project that I feel like I'm lost in acronym soup and extremely "complex" problems. But it's my belief that all IT projects should be definable by a brief (2-3 sentence max) explanation of how a user's life will be improved when we're done. If you can't do that, you're already sunk.
Going out and talking to users is essential in every type of project, but people in IT need to understand that the users will never be able to tell you exactly what they need. User needs have to be interpreted. There are methods for doing this that go beyond mere guessing (my favorite being Contextual Design), but these processes (and the philosophies that come with them) need to be adopted on the project from the beginning, it gets harder and harder to retrofit as the project goes on.
Anyway, great post.
You mentioned your client choosing to purchase a packaged app, rather than develop an alternative in-house.
I've noticed that it's very common for Enterprise IT departments to prefer packaged apps over in-house developed apps, even in cases (like the one you mention) where it would be clearly cheaper, simpler, and a better fit for the requirements to develop the solution in-house.
I think that examining *why* does a long way toward explaining the poor quality and overcomplexity in most Enterprise IT environments.
The processes in most Enterprise IT environments are heavily driven be risk avoidance. *Not* the avoidance of risk for the Company, but avoidance of risk for the project sponsors and decision makers.
Lets say your the executive sponsor of a project. Let's further assume you choose to approve a project that involves the purchase and implementation of an expensive packaged app from a "reputable" software company like IBM, Oracle, BAAN, Microsoft, etc. If the project fails, you've got a *lot* of other people to blame it on, and a lot of wiggle room to show how the project failure is not your fault. You selected a reputable big vendor, you selected a product that was in the Garner Magic Quadrant (or some such garbage), etc. Clearly noone can hold you accountable right?
But, if you'd decided to develop the application in-house and it had failed... who do you blame? You could blame IT, but if you're an IT executive that won't take you very far. :-)
The sad fact is, most corporate IT projects are planned to maximize the companies benefits... they're planned to benefit the career's of the project decision makers. :-(
Let's says I'm a rental car company. Some of my customers wait in long lines where I can sell them auto insurance they don't need, and even more insurance against returning the tank less than 2/5 full. Others pay extra to join Hertz Gold or Avis First so that they can skip the line entirely and go directly to the lot.
Now, you're telling me that I can invest in additional infrastructure, in order to reduce my customers' incentive to join my preferred service program. Run that by me again?
I've worked in almost every part of a corporation: sales, marketing, IT, R&D, operations, executive, etc.
Long ago (10+ years) I came to the conclusion that IT organizations often are the biggest danger to top-line revenue there is, for pretty much exactly the reason you describe.
I've seen too many cases where the IT manager wants to do something good for the company but is too ignorant about the business or dealing with people to not act like his head is up his rear - something like the IT manager who couldn't talk to users/customers.
As Josh says, it is IT's job to interpret what the requirements are. I'd add to that it's their job to anticipate IT requirements both tactically but also strategically. Sadly most IT managers and line employees don't have the experience, skills or business knowledge to handle that task. Some go to get MBAs and such but often they take away only what reinforces their own worst habits.
In process analysis and design there is a point where you are supposed to ask if the "IS" process and also if the "SHOULD" process does/will fail because those who must execute it don't have the capacity (training, ability, skills, personality, motivation, etc.) to do the job even if everything else is exactly right. That may be the issue and it may be that IT is not ever going be the right people to do this job - in which it and the collateral activities need to be taken away from them as a collective profession.
Certain job areas preselect for certain personalities and skills based on the nature of the job (e.g. marketing or accounting). It may be that IT attracts talent that out of its depth for actually solving business problems with computers and networks.
Neal, Excellent post. I agree with Bob McCormick's comment about some IT decision-makers foremost managing risk of their career.
I work in a large organization also, which is both drowning in accidental complexity and adding to it as well.
There are all kinds of bad things involved:
*decision makers focus on their own risk first
*some people who do things just to show they are awake instead of thoughtfully contributing
*some infrastructure that is driven by a change management group (BA's) more than the users (or IT)
*poor technical folks that talk well but waste a lot of time discussing incredibly elementary details during design
*lack of interaction between developers - tens of thousands of developers and I have to work hard to find out what tools or approaches are working for people within 50 feet of me
I have long been curious what is needed to root out these issues. Is it leadership, culture or is it a 'no silver bullet' problem?
"Nimble IT" is such an interesting phrase. It seems oxymoronic. I have never seen an IT department that I would describe as "nimble".
People in IT departments--at all levels--seem to be motivated largely by the desire to optimize their resumes. It is far more important to gain experience with the trendy tools than to build something the company might actually need.
This is probably a partial explanation for the preference for packages. Installing a commonly-used package adds a nice resume keyword.
Another reason for the package preference is that many IT people are so lost in buzzwords and "processes" that they have forgotten (if they ever knew) how to really design anything.
Would you mind clarifying what you mean here with an example or two?
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.
Thanks.
If I own a company that tracks insurance policies, and I can do it with a simple web application, I can charge less than the insurance company that has to some of the information from the mainframe to a data warehouse, and other information from a crusty old client/server application. The essential complexity is: I must track data for policies. The accidental complexity is all the ridiculous steps required to accomplish this task that don't add any real business value.
For examples, see virtually any large company that tracks information that's been in business more than 2 decades.
Well said Neal.
Would you mind clarifying what you mean here with an example or two?
"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."
I have another example.
When a shipping company builds a lightweight Restful web service to receive orders online, that opens up all sorts of avenues, enabling the company to become the main shipping company for other enterprises that leverage web services. In other words, having the IT infrastructure provided the shipping company a strategic advantage.
When an insurance company has an old monolithic difficult-to-maintain system, then whenever the company seeks new IT applications to support its business, decisions are governed and constrained by the existing IT infrastructure instead of being enhanced by it. This often limits strategic decisions, hampering the company in realizing its business vision.
Post a Comment