Related Links

Web Seminars

The systems development life cycle has been around for as long as computerized applications have been built and is all too familiar to most practitioners. Although it can be articulated in a number of ways, it basically consists of defining the requirements of an application, then analyzing the business problem domain, then designing an application, then building it, then testing and debugging it, and then running the application in production. There are a number of variations on this theme, such as a final obsolescence phase or iterative building, testing and debugging steps. A major problem, however, is that the systems development life cycle looks very hit-and-miss if you compare it to other engineering activities such as building bridges or aircraft. Bridge builders and aircraft designers certainly look at requirements and do design work, but they create detailed specifications that are used to build things in a way that never seems to happen in software development. In fact, the way in which we do software development never rises to the level of true "engineering" despite new methodologies that seem to come along every couple of years. These methodologies often promise that they will supplant the traditional systems development life cycle, but always seem to end up just being variations on it. There are legitimate grounds to ask if the business rules approach is just another variation to dealing with business logic, or if it really does not fit with the systems development life cycle. We may have to wait a while to get the definitive answer, but there is evidence that the business rules approach does not fit the systems development life cycle.

Hand-Crafted Code

The programmers of today may work in a high-tech arena, but the way in which they do their work often seems to resemble the practices of medieval craftsmen. There is surprisingly little automation and not many good productivity aids. Everything seems to require attention and work by humans, and all work products have a "one-off" feel about them. There is some division of labor, but making sure that a team of programmers works together effectively takes a lot of management effort. The result of these efforts is hand-crafted program source code, some of which can be of very high quality, but much of which falls by the wayside. As a friend of mine is apt to point out, scrap software, unlike scrap metal, has zero value, which is a pity because there is an awful lot of it. It is my belief that the systems development life cycle is inevitable if business logic is going to be implemented by labor-intensive programming activities carried out by human beings.

The business rules approach may still be in its early stages, but it holds out a promise of doing things differently. Not only may we be able to capture and record the logic underlying a particular business domain, but we may be able to create executable objects directly from what we have recorded about the definitions of business rules. This could cut out the need for artisan programmers weaving source code in their cubicles, just as the medieval cloth makers were replaced by the automated looms of the early Industrial Revolution. However, even if we were already at this point - which plainly we are not - we would face another set of difficulties. Our management practices are based on the systems development life cycle, and they too will have to change if we ever move away from hand-crafted code. In fact, difficulties are already arising in this area as the business rules movement continues to make headway.

The Bureaucracy of Change

A good example of a clash between management practices and the business rules approach is what happens in production environments. In my work I have participated in the development of business rules engine components that, among other things, let businesses quickly react to changing circumstances. One kind of change has been the need to quickly calculate new financial metrics. For instance, a real estate investment partnership may need to calculate a new expense ratio using data that is already present in the database of an existing application, say the annual amount spent on paying insurance for a building divided by the total annual rent received for that building. This implies defining the rule for the calculation and having a new database column in which the result of the calculation will be held. The rules engine software should do both these things, but creating new database columns in production databases is traditionally viewed as something that DBAs do (usually late at night or on weekends, when the production system is down). Why? The answer is because you can't just have people slap things into a production system because they could wreck it. This is usually true when programmers are hand-crafting code. Programmers often do inadequate testing and having DBAs and other gatekeepers to the production environment raises the probability that what gets into production really works.

Such a bureaucracy may be needed as part of the traditional systems development life cycle, but it is at odds with business rules. If we have invested in rules engine functionality that enables the fast implementation of new business metrics, why not let the rules engine create new columns? Perhaps not in all circumstances, but at least it could be done for calculated columns that are not reused in other calculations. The truth is that the management practices that have been built on the systems development life cycle are going to be inadequate if we move away from hand-crafted program source code. In fact these management practices are likely to inhibit the adoption of the business rules approach. How these strains are going to be worked out in practice is not easy to foresee at the moment because they are part of a more complex set of issues that include areas such as testing and support. Nevertheless, it is very unlikely that the systems development life cycle will remain the same as business rules become more mainstream.

Malcolm Chisholm, Ph.D. has over 25 years of experience in enterprise information management and data management and has worked in a wide range of sectors. He specializes in setting up and developing enterprise information management units, master data management, and business rules. His experience includes the financial, manufacturing, government, and pharmaceutical industries. He is the author of How to Build a Business Rules Engine and Managing Reference Data in Enterprise Databases and Definition in Information Management. He writes numerous articles and is a frequent presenter on these topics at industry events. Chisholm runs the websites http://www.bizrulesengine.com, http://www.refdataportal.com and http://www.data-definition.com. Chisholm is the winner of the 2011 DAMA International Achievement Award.