[ Pobierz całość w formacie PDF ]
.A business rule classification scheme that works for abusiness audience includes terms, facts, mandatory constraints, guidelines,computations, inferences, and action enablers.The system may need to know alldatabase activities such that, should any business event initiate any of those datachanges, the corresponding (and hence, shared) rule will fire automatically.You now understand what business rules are and how they govern business events.The next chapter, therefore, provides an overview for how to incorporate business ruleconcepts and automation techniques into your current systems development approach.53 Chapter 3: Introduction to Business RuleMethodologyThis chapter provides an understanding of the complete business rule methodologydetailed in the remainder of the book.If you are a project manager or methodologist,you will find this chapter useful in understanding the differences behind a businessrules approach compared to other common approaches.If you are a practitioner, suchas an analyst or designer or programmer, this chapter serves as an introduction to thepractices that are covered in the remainder of the book.What Is a Business Rule Methodology?A business rule methodology is a set of phases, steps, techniques, and guidelines fordelivering a business rules systems.As Chapter 1 stated, a business rules system is anautomated system that separates the rules of the business logically, perhaps physically,from other aspects of the system and shares them across data stores, user interfaces,and applications.While there are many reasons to build a business rules system, the two primaryreasons are to significantly shorten development time and to deliver a system that isdesigned for change.To achieve these differences, you need a systems developmentmethodology that divides the problem domain into at least three separate but integrallyrelated aspects: data, process, and rules.Essentially, this book leads you through thetasks of separating these aspects from each other, optimizing each in its own right,integrating them back together for a holistic solution, and supporting the solution withenabling technology.Building a business rules system requires a business rule methodology because rulesdon t surface on their own, don t disconnect themselves from other system artifacts,don t optimize themselves, and don t maintain themselves over time.Therefore, abusiness rules approach, when compared to other systems development approaches,places more emphasis and importance and discipline on the formalizing of the rules ofthe business and, hence, the delivery of those rules within corresponding changeablesystem logic.It turns out that rules, more than objects and even data, are where the new excitementis.That s because rules represent the underpinnings of the organization s culture anddecision-making power.Rules utilize information so as to make decisions, create newknowledge, and take intelligent action.What can be more important and exciting thanthat?In fact, you will discover that the rules emerge as the most important system aspectfrom a business person s perspective.That s because businesses today want and needto change and rules are an important way through which the business changes.You, asan IT professional, either enable the business to change or stifle it by the way youdeliver rules within your systems.You either bury the rules hopelessly in program codewhere they remain resistant to change.Or you deliberately liberate them for scrutinyand easy change.The goal of a business rule methodology, then, is to start by separating these threeaspects of a system: rules, data, and process considerations.Obviously, most of thisbook is dedicated to the steps and techniques for separating and managing rules.That s because, as important as rules are to the business, they represent the aspectmost often neglected or without formalism in other methodologies.A unique benefit to abusiness rules approach is that it has tentacles in both business and systemsdevelopment communities.For the business community, a business rules approach is a54 methodology by which business leaders utilize rules as instruments of proactive andcreative organizational change.You will see glimpses of this in Chapter 4, Scoping forSuccess. In Chapter 4, when you scope a proposed business rules system, you givecareful attention, not only to the business motivation for the system, but to the importantrole played by the rules in guiding the business toward its objectives.It is beyond thescope of this book to provide a methodology for incorporating a business rulesapproach into a business process reengineering (BPR) methodology.However,Chapter 4 provides the starting point by which you can introduce business rules intoyour existing BPR approach.The remainder of this chapter presents an overview of the tracks and phases in buildinga business rules system.A quick overview of the tracks first provides a basis forunderstanding the discussions about the phases.Note that each phase consists ofsteps, guidelines, and deliverables for each track.If you are a seasoned systems developer, you may conclude that your systemsdevelopment approach already addresses all of the items discussed in this chapter.The difference is that a business rules approach recognizes all five types of rules fromChapter 2 in four important ways.The first recognition that is part of the entiremethodology is that rules are an asset, worthy of being captured formally.The secondrealization is that rules are to be managed with care throughout their lifetime.The third,and perhaps most important, recognition is that rules are meant to change on a regularbasis so as to hit business objectives more effectively or aim for new ones.The fourthrealization is that rules must be readily accessible to everyone who needs to knowthem, behave by them, and change with them.Benefits of Using a Business Rule MethodologyIdeally, a system built according to a business rule methodology should, by design,exhibit the following desirable characteristics:Is developed faster than nonbusiness rules systemsIs based on a very stable data model where the data is shared acrossapplication and organizational boundariesIs based on rules that are shared across application and organizationalboundaries (no more unnecessary application silos)Is developed around the essential core process flow (based on ruledependencies), allowing for freedom of choice in other types of processflowAllows for various technology architectures and designs for ruleautomation (that may change over time, even if the rules themselves don tchange)Includes traceability from business objectives to requirements toautomated rulesMinimizes the inclusion of rules as part of nonrule deliverablesExhibits the new economy of system changes, such that changes in rulesare easy to make.In case you missed the last and most important point, rule changes are easy
[ Pobierz całość w formacie PDF ]