In the first part of this discussion, I talked about the mindset issues that need to be addressed for projects to become truly business-driven. In this second and concluding part, I discuss how we have addressed these issues in our business rule methodology, Proteus^TM.

Our solution to the mindset issues has been greatly influenced by John Zachman and his Architecture Framework. If you are familiar with that body of work, I can easily position our business rule methodology by saying it addresses rows 1 and 2 of the Framework in the exact 6-aspect (column) manner he prescribes. (Our deliverables, however, are aimed primarily at the business-process level, rather than the enterprise level.)

Knowledge about the Zachman Framework is not actually necessary to use the methodology. If you are not familiar with the Zachman Framework, let me explain our solution to the mindset issues this way. The focus of our approach is on developing a business model for the scope of the project, with direct participation of the business process "owners" and/or operational-level managers and experts.

Since these people constitute the audience for the business model, the approach and techniques must be specifically tailored to their perspective. This means banishing system and technical issues from the business blueprints.

A business blueprint must also be carefully factored, to ensure that the inherent complexity of creating business solutions can be managed. What are these factors and how does the methodology address them? Again, we follow John Zachman's lead on this. He indicates that there are six basic factors. We address them head-on as follows.

• Motivation … the why factor.    We address this factor first, by creating a battle plan for the intended business solution. We call this battle plan a Policy Charter. It outlines the ends (e.g., goals) and means (e.g., tactics) optimal for solving the business problem. This includes core business rules — make-or-break policies needed to operate the business solution successfully.

• Collaboration … the who factor.    We address this factor using business-oriented Workflow Models. These enable participants to create thorough-planned responses to crucial business events, outlining tasks and responsibilities. Workflow Models are especially useful for exploring requirements.

• "Data" Structure … the what factor.   We address this factor by developing the standard business vocabulary of the targeted business area. These definitions are organized into the Concepts Catalog, a glossary of terms. The Concepts Catalog is actually just one part of the larger problem — what shared operational business knowledge will be needed to run the business. That knowledge is organized into a Fact Model.

The other three factors supplement and complement these first three.

• Transformations … the how factor.   We address this factor by carefully documenting each Task in the Workflow Models.

• Staging … the when factor.   We address this factor by examining the regimens needed to organize stages, called business milestones, in the business life of core concepts.

• Connectivity … the where factor.   We address this factor by building a Business Connectivity Map indicating business sites and the communications/transport links between them.

In addressing each of the individual factors in the business blueprint, we consciously and deliberately seek out the relevant elements of business logic -- i.e., the business rules -- and record them. This is another area, rule management, in which the approach is business-driven.

Although the business blueprint is business-oriented, it must nonetheless provide a comprehensive and complete set of requirements that system architects can subsequently use to design the actual system. The business model prescribed by the methodology can be transformed directly into a first-cut system model. What that means for system designers is that most, if not all, of the relevant business questions have already been answered up-front.

Developing a good system design, of course, is often very difficult. This crucial input gives the system designers an important leg-up on the work they must do. It also means that the system designers and then the implementors are far less likely to discover showstoppers on the business side way downstream in the implementation process -- where it becomes increasingly expensive and frustrating on all sides to correct them.

Avoiding business-side showstoppers downstream in the development process is really the bottom line in what it means to be business-driven. We believe that getting a workable business solution that actually solves the business problem in the most effective manner should always remain the most important objective of all.

# # #