Business Rules Come First

Computerworld - Recently, colleagues and I were talking to the chief software developer at a large client organization about progress on a major re-engineering effort there. Our concern was whether the project team members could meet a deadline some nine months out for delivering a large-scale prototype. We'd just spent several intensive months developing a comprehensive business model, and they still had several months of system design left to complete.

This chief developer is very sharp—not one to commit to any answer lightly. For the longest while, he said nothing, lost in thought. Finally, eyeing the detailed business diagrams plastered on the walls all around, he said, "If we had already started coding, I would say we had no chance at all. But since we haven't started coding yet, I'd say the chances are pretty good."

I had to run that by several times in my mind before I caught his meaning. "If we had already started coding, I would say we had no chance at all."

I knew he thought that the application coding itself was going to be pretty tough. It would involve using a rules engine, a worldwide distribution network, graphical user interfaces and some significant middleware.

He was saying that if they had to resolve all the business issues while coding, they would never pull it off in time—or probably ever. However, since the project team was tackling the tough business issues upfront (including specifying the business rules), he thought they had a pretty good chance of completing the code by the target date.

In large measure, the business rule approach is simply about asking the right questions of the right people. There is only one way to honestly meet a deadline—and that's to solve the business problem first.

Business-Driven IT

In the early days of building business systems, the business side could essentially sit back and just let them happen. The advantages of automating were so compelling that you could do virtually no wrong. Now, for all practical purposes, business and IT operate inseparably. When undertaking projects, the logical step then would be to put together seamless business/IT project teams and have them follow a business-oriented approach to developing requirements. Yet many companies are nowhere close to doing that today.

The answer is relatively straightforward. The business needs an organized approach that enables business professionals to drive the development of requirements. This approach must provide a road map that shows how to ask the right kinds of questions about the right things at the right times. What's needed is a business-driven approach.