Four Things Wrong with the Way We Develop Information Systems

OLDIES ARCHIVES ...

FOUR THINGS WRONG WITH THE WAY WE DEVELOP INFORMATION SYSTEMS

By Ronald G. Ross, January 1999

Is your company as successful as it would like to be in developing information systems? Probably not. Have you identified the reasons? Here are four factors topping my list.

Single-purpose systems that undermine your ability to change. How often have you run into the following situation? A manager likes a spreadsheet and tells you, "That's exactly what I want for my new client-server system." Maybe building new systems that way once or twice is O.K. But build new systems that way dozens or hundreds of times, and you'll produce a tangle not even Einstein could unravel. The problem is that single-purpose systems are neither scalable nor adaptable-they simply are not built for growth and change. The result is rapid loss in the company's ability to direct its own destiny. How can you avoid this? All you need is a good roadmap-in IT we call that "architecture."
Projects that run into belated show stoppers, or that lurch from one gridlock to the next. It's simple enough to think ahead. Yet many projects don't take the time. "Always time to fix it, but never time to plan it" still seems the norm. Do we know how to do better? Yes-and actually it's rather simple. It requires two things. First, you need a top-down, honest-to-God business model. Second, you need a series of continuing checks and balances on your requirements development process. If your approach lacks these two things, I'd say try something different.
Technology-driven solutions. In the old Wild-West days of building information systems (only a decade or two ago), the business side essentially could sit back and let it happen. The advantages of automating were so compelling that you virtually could do no wrong. (Like many things about the old West, that is probably a myth, but no matter-it makes a good story.) Now we are in the Information Age, however, and for practical purposes, business and IT operate inseparably. You would think that in undertaking new work, companies would put together seamless business/IT projects. But many companies are nowhere close to doing that. Worse, they actually do very little to induce, structure or reward creative business thinking in their IT projects. Neither business side nor IT side really is challenged to close the gap-the business side still gets away with fuzzy, ill-focused "requirements," and the IT side continues doing "requirements" barely a notch above code. Is there a solution? Yes-a business-driven requirements approach. The good news is that both sides already have the requisite knowledge-all they need is the right structure to express the right things at the right times. Here's more good news-that's exactly what the business rule approach offers.
AWOL business knowledge. I find many companies seemingly are unaware of one of the biggest risks they face-their own internal brain drain. Much of the company's self-knowledge has disappeared already-downsized, outsourced, re-engineered, or early-retired away. Who's left who has any real idea of how critical areas of the business actually work? Often there are only one or two key people (sometimes on the IT side, sometimes on the business side) who can tell you the criteria for making low-level, day-to-day business deci-sions. If your company is in that situation, better do something quick-those key people may have one foot out the door already. What you need is an initiative to harvest and to manage your com-pany's core business rules. If you end up losing that knowledge, all you'll have left is the source code-straight out of the old Wild West. Come Y2K+1, that's not where you want your company to be!