Let's start with the following given: Businesses do not exist to manage hardware/software environments but, rather, hardware/software environments exist to support the business. This should be self-evident, but in the midst of such a fast-paced technological revolution, sometimes we lose sight of it. As a result, we often find the tail seeming to wag the dog.

Clear-headed people on both the business side and the IT side know it shouldn't be that way. The "IT" projects the company decides to undertake should always in fact be 'of the business, for the business, and by the business.' But saying it is one thing — figuring out how to accomplish it is another.

Fortunately, a business rule methodology offers the well-organized roadmap you need to put the business back in the driver's seat. In Part 2, I'll outline the particular ways in which it structures the requirements development process to accomplish this. First, however, we should examine the relevant mindset issues. These are equally, if not more, important.

• There should only be one kind of project. In days past, IT had its projects and the business had its projects, and these projects were seldom if ever woven together. Clearly this outmoded approach will not work in the 21st century. These days, virtually every business project involves some automation — and most IT projects have direct impact on the business. What we must come to therefore is a single kind of project with a unified approach to follow.

• The business side has the knowledge to solve business problems. Clearly IT can help with that, but to a large measure, IT's role should be largely focused on 'systemizing' and implementing the solution.

• One implication is the following. What the system turns around and shows the business side during actual operation should look much like the requirements that the business side put in up-front. I don't mean that in a figurative sense — I mean it in a literal sense. Business knowledge in; business knowledge out. What that means, of course, is business rules.

• Achieving this requires that the business questions should be asked first, before addressing the system and implementation issues. Although this seems like an obvious point, it often doesn't happen that way in practice.

• Capturing business knowledge up-front will mean new participatory roles for the business-side. We will need deeper, more focused involvement on their part. We will also require commitment of the most valuable commodity of all — their time.

• In return, the business side has the right to expect the most conservative use of their time possible and ready-made structures (thinking tools) to help them organize their business knowledge in the optimal ways.

• What this really means is an approach that emphasizes being able to ask the right questions, at the right times, and laying out the right forms (or deliverables) the answers should take.

• Finally, we must appreciate that the business questions are usually highly complex in their own right. As with any complex problem, this means the questions and answers need to be carefully factored — that is, not jumbled together as rambling statements but specifically addressing one particular aspect of the problem at a time.

In the second and concluding part of this discussion, I will discuss how we have addressed these 'mindset' issues in our business rule methodology, Proteus^TM.

# # #