The key role in requirements development for the 21st century business will be that of business analyst. Does your company have them? Can you define who they are? What they need to know? What they need to be able to do?

A good way to start defining the role of business analyst is as business problem-solver. (Read on to find out why that's not sufficient, however.) To perform the role of business problem solver, business analysts must be generalists. They must be able to grapple with a problem in any of a number of dimensions, whether involving tactics, infrastructure, organization, information systems-or more likely, all of the above.

To be a business problem-solver, a business analyst also must be in touch with the reality of the "as is" business. Think of a business analyst as the person most likely to be able to tell you (or find out) how some aspect of the business really works-and what's wrong with it. To put that a little more strongly, if they can't tell you (or find out), then they are simply not doing their job.

That's just for starters. Then they must be able to visualize and develop "to be" solutions. To do that, they need the skills of a systems analyst or of a business process engineer.

So which is it-systems analyst or business process engineer? The correct answer is both-and neither. By "both," I mean that business analysts should feel comfortable with both the IT side and the business side of developing systems. Indeed, if they are really good, they may not even clearly understand the difference. After all, in the Information Age, is there any difference?!

What I mean by "neither" is this. On the one hand, a business analyst is definitely not a traditional IT systems designer. More times than not, IT designers are really more interested in getting to the code, than in rolling out a complete business solution or doing very much planning. Fortunately, some companies are beyond that-but still fall way short of having true business analysts (even if they use that term). For example, a business coordinator for system change requests is not a true business analyst. Yes, adding a field or two to GUIs in a legacy system is often no trivial matter. However, that rarely amounts to problem-solving where competitive advantage or corporate survival is at stake. That's the kind of problem-solving with which a true business analyst must contend.

On the other hand, I don't mean high-level business process re-engineer either. (By "high-level," I mean the type of business process re-engineer who is more comfortable with value chains and business strategies, than with nuts-and-bolts operations.) A true business analyst is someone who can help put together a full set of requirements-a complete business model covering all aspects of the problem. The test for such a model is that you must be able to transform it (with a lot more work, of course) into a workable system design. The assumption here, by the way, is that at least some of the design is likely to be automated.

This leads me back to the earlier point about why "business problem solver" doesn't entirely capture what true business analysts are about. Certainly, they do "fix" business problems. However, they must be equipped to develop solutions in terms of better infrastructure, not just in terms of direct fixes (even detailed ones) for the immediate problem at hand. "Better infrastructure" in turn implies longer, more complex projects. It also requires a structured approach to business analysis-that is, to development of the comprehensive requirements necessary to create a "to be" world.

Readers of the Newsletter already know what the right answer for "structured approach to business analysis" in the 21st century is-the business rule approach. Let me be a little more specific. We think that means the business analyst must be to involved directly in capturing policies and core business rules, creating fact models (business-oriented data models), developing "to-be" workflows, etc.

The other issue-supporting longer, more complex projects-means a better understanding of basic project management tools (timelines, budgets, resource allocation, etc.). That's the stuff that project managers should bring to the table. Unfortunately, good project managers are also scarce-but that's a story for some other day.

© 1999, Ronald G. Ross.