Skip the navigation

Business Rules Come First

Don't start an IT project until the company has written a clear set of rules about the way it does business.

By Ronald G. Ross
September 1, 2003 12:00 PM ET

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.








Principles of the Business Rule Approach

All too often, the business side still produces fuzzy, ill-focused "requirements," and the IT side continues doing "requirements" only a notch or two above programming. How can this gap between business professionals and IT professionals in developing requirements be eliminated?


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.



Our Commenting Policies
Internet of Things: Get the latest!
Internet of Things

Our new bimonthly Internet of Things newsletter helps you keep pace with the rapidly evolving technologies, trends and developments related to the IoT. Subscribe now and stay up to date!