Business Rules and Information Systems: Aligning It with Business Goals

• Venue: Business Rules and Information Systems: Aligning It with Business Goals
• Year: 2002

From the Book:Why this book It seems that every week there's some new story about a software project or system that's failed in some way. Quite often, the failures are so big that they make it to the national press. Most of the information given is anecdotal and circumstantial, but even a non-technical observer might suspect that there's something seriously wrong with the way we develop software systems. My own view is that the core of the problem lies in the casual way we treat 'the requirements': the statements that tell us what an information system is supposed to do. These are typically only captured in a rudimentary way, are poorly structured, and are only linked to the software by ideas in the heads of analysts and developers that aren't open to examination or verification. If we could return 'the requirements' to a more prominent role in the process, and use them to drive the subsequent development stages, we have the potential for a drastic reduction in the number of errors. Adding automation to this can further reduce the opportunity for error and, as a bonus, also give big reductions in time and cost. We haven't been able to do this in the past because there's been no clear strategy that we could adopt to drive things forward. The idea of business rules, rooted in a business model, might provide part of the answer. But practical information on the topic is unexpectedly sparse, even though most of the basic ideas have been around for some time. Hopefully, this book will go some way towards plugging the gap. The goals of this book I wrote the book to pull together a load of separate strands, and to show how they fit togetherto provide a coherent foundation for building information systems. In truth, there's very little in the book that's completely new, and maybe that's a good thing. What we need is not so much new technology, as a renewed focus on what's really important. The intention is not to convince you to use rules. You're already using them. In fact, if you're in a large organization you probably have thousands of them. They guide the way your organization works, they make sure you comply with legal and other regulations, they are a source of competitive advantage or a barrier to success. But in most organizations they lead a shadowy existence. They may be enforced by your information systems, so that you're always directed towards the goals the business has adopted. But then again, they may not. What you need to do is to get an adequate level of control over your environment. There's no way that I can know about your specific circumstances, but maybe the material in this book will help you to come up with some actions that put you in a better position be a leader in your industry, instead of just surviving. Although there's probably enough information here for you to develop your own complete set of tools and processes for building rule-centered systems, it's not really what I would recommend. Generally speaking you should prefer a properly supported commercial product to a home-brewed tool - if one exists. But all products have their little foibles, and before you fall into the arms of a particular vendor you need to understand what you're gaining and what you're giving up. The information in this book should help you to ask the right questions before you make a commitment. You can also use the material in this book to help you to define any local 'glue' that may be required to make your tool set stick together properly. There's no information here about particular commercial products or vendors. This is a comparatively new area for tool support, and, like all immature technology areas, it's undergoing rapid change. Any descriptions of current tools would be out of date in a few months, or even weeks. The best sources of information are the Web pages of the suppliers, where you'll usually find product descriptions, white papers and other supporting materials. Just search for terms like "business rule", weed out the sites that are on topic from the list returned, and build up your own set of favorites. You should also check out the Addison-Wesley web site at www.aw.com/cseng, where you'll find more information relating to this book. Who should read this book This book is aimed primarily at professionals working in the field of Information Technology. If you have any involvement in the definition, creation or management of an information system then you should be able to gain something of value from this book. Analysts, responsible for capturing requirements and for specifying information systems, can find out more about producing logically complete definitions of the needs of the business. This includes understanding business models and their various constituents, how to locate business rules, and how to express them in a form that maintains their true value. Designers and developers, with responsibility for the implementation and testing of systems, can find practical examples of how business logic (expressed in the form of rules) can be conserved and taken forward into operational software. This also provides for two-way traceability between the worlds of specification and implementation. Managers and strategists are obliged to take a higher-level view of the whole process. What they will find here are practical steps to help them to manage the intellectual property represented in a system, along with ideas for improving the development process in order to deliver information systems faster, cheaper, and, above all, to a level of quality that can far exceed current ad-hoc methods. How to use this book Please don't treat this book as a set of edicts about what you should or should not do. It's meant to be a source of ideas that you can meld into your own approach to the needs of information systems in the 21st century. The thing that resonates with me most strongly after engagements in a large number of different IT environments is that they are different! Of course, there are similarities from place to place, but no one really wants to be just the same as everyone else their market sector. In fact, you can't really afford to be a 'me too' player because that means about the best you can expect is to survive, not to be a winner. Using IT effectively requires you to balance out two different things: Sum you need to be realistic about what technology can provide, but be prepared to take up new capabilities as they arise Sum you have to look for ways in which you can differentiate your operations from the competition, by doing it faster, cheaper, or to a level of quality that they can't match. The material in this book is aimed at providing you with the information you need to make crucial decisions in this area. I can't tell you how to run your business, but I can provide pointers to ideas that you may be able to use to use to lead your industry in the application of information technology. The content falls into four main parts. Part I sets the scene by suggesting how we could begin to approach information systems in a different way. Chapter 1 paints a picture of an alternative future that uses structured descriptions of our business to drive system development. Chapter 2 fills in some of the background on what we mean by structuring and managing knowledge about a business. This introduces business models and the role they can play in meeting the demands of new business directions, such as e-commerce. Although business rules have a particularly important part to play here, they are probably the least well documented of all the business model elements. Part II therefore delves into rules in greater depth, and provides some fairly detailed information that should help you to set up a sound framework for delivering logical business descriptions. Chapter 3 explains how to define business rules in a systematic way. Chapter 4 discusses how to identify business rules and pull them into a managed environment. Chapter 5 shows how the business logic that underlies the rules can be validated, providing assurance that the intentions of the business have been captured accurately so that later stages can proceed with confidence In, Part III we take a look at the other end of the process and consider realistic mechanisms for the implementation of information systems, and business rules in particular. Chapter 6 reviews the kinds of technical architectures that dominate in most organizations, and shows where rules can fit into the kinds of structure that are likely to be available. Chapter 7 goes into more detail on the various ways that business rules can be realized using readily available technology. Chapter 8 discusses ways of managing rules and models and the part they play in information system development. Finally, Part IV rounds things out by summarizing the state of play at the present time. Chapter 9 shows how business rules build on long-standing ideas about structuring descriptions of interactions between people and between people and machines, and points to some directions that this may take in the future. Chapter 10 gives a summary of the main characteristics of business rules, and the value that they can provide. There's also a fairly sizable Appendix summarizing the key elements of logic that need to be understood by anyone working with business rules. If you're entirely comfortable with the ideas of formal logic then you can skip this, but you may want to dip into it if you feel the need for a refresher. Most of all, I would be happy if this book encourages you to think about information system in a different way. Let's focus on producing a logically complete description of what we want, and let the machines take care of the details. Acknowledgements The core ideas in this book were forged in the heat of an extended Unisys R&D project called Columbus. Somewhat ahead of its time, this was a rare attempt to explore the trade-offs between technical versus commercial and abstract versus pragmatic, to find a more systematic way of building information systems. Many colleagues at Unisys made valuable contributions, and much of the consensus that emerged from that hard-won experience is reflected in the pages that follow. In particular, Peter Barnsley, Joe Barrett, John Duplock and Kelly Potter showed me how even the toughest problems can be overcome by the right blend of experience, technical know-how and a sense of fun (and croissants). While the book was taking shape, several of the ideas were further sharpened through discussion with partners in the SITE project at Brunel University. Sergio de Cesare, Mark Lycett, Valerie Martin and Ray Paul all provided valuable insights that helped me to clarify some fuzzy areas and gave me a better understanding of the research context. Dot Malson at Unisys and Peter Gordon at Addison-Wesley nursed the book through its development, and generally kept the project on the rails throughout its extended gestation period. Their advice and encouragement made a daunting task seem realistic. Two other influences deserve acknowledgement. The first is Ron Ross, who for many years has provided thought leadership for the business rules community. His seminars on this subject are a model of clarity, and I highly recommend them to anyone interested in this field. The second is the late Bob Muller, who gently spurred many of his colleagues at SPL, SDL and elsewhere, to be more creative than they ever believed they could be. Last, but certainly not least, thanks to Gwen, Eleanor and Robert for putting up with all the stress and the strain that goes with writing—at least, the way I do it!