THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Printer-friendly

E-mail to friend

Interview with Barbara von Halle & Larry Goldberg

The Decision Model - New Book

Published: August 1, 2009

Robert Seiner interviews Barbara von Halle and Larry Goldberg about their new book, The Decision Model: A Business Logic Framework Linking Business and Technology.

Robert Seiner (RSS): This morning I am sitting down with Barbara von Halle, long time friend and associate, a former and soon-to-be-again columnist for TDAN.com. Barb is co-author (with Larry Goldberg) of an upcoming book that has the potential to turn the data management industry on its ear. We will talk about the book in a moment. Larry Goldberg also provided answers to some of my questions.

Many TDAN.com readers are probably familiar with Barbara’s contributions to the field of data management, even before TDAN.com existed. Can you share with the readers of TDAN.com your history of data-oriented publications that they may be familiar with?

Barbara von Halle (BVH): Aside from a few early articles, my first major publication was The Handbook of Relational Database Design published by Addison-Wesley in 1989 and co-authored with Candace Fleming (now CIO of Columbia University). The book is beyond its 20th printing, which means it still serves as a step-by-step approach for logical data modeling and relational database design.

The publication TDAN.com readers may remember most was my column in Database Programming and Design magazine that ran for approximately 5 years. The column covered database design advice from experts and loyal readers. Today, TDAN.com has emerged as a premier publication for data management professionals. I am very excited about the prospect of being a columnist again for TDAN.com.

A third data-oriented contribution was published as several editions by Auerbach called The Handbook of Data Management. This was an anthology of experiences from various contributors in establishing corporate data management organizations. I am pleased that Auerbach is now the publisher of the new book that Bob mentioned in his opening statement.

For this new book, I have teamed with Larry Goldberg. Larry’s career spans decades and continents. He has started and sold several software companies including one that delivered business rule management software. For the past few years, Larry and I have been partners in Knowledge Partners International.

RSS: I just want to share with the readers a brief background of how our paths originally crossed. Years ago, you joined a consulting group out of New Jersey called Spectrum Technology Group. As I was entering the data management industry, I constantly saw people’s names from Spectrum listed as authors and speakers associated with the most prestigious of data management publications and events. I have to tell you that is why I pursued Spectrum when I left the corporate world for this wonderful world of consulting.

Spectrum was soon acquired by CIBER, and I spent six great years working through the Spectrum to CIBER transition before heading out on my own. When you left Spectrum, you started Knowledge Partners, Inc. (KPI) and spent several years focusing on a business rules approach to data and process management. What is the status of KPI today and have you found that the business rules approach is as relevant today as it was back then?

BVH: Bob, it is no surprise to your readers that KPI started as a data architecture company and employed a group of high quality consultants in that field. But prior to starting KPI, I had become very interested in the field of artificial intelligence and knowledge engineering. I found the theory and technology fascinating, but was interested in extending the concepts to rules that drive everyday business transactions. In other words, I wanted to apply the discipline to rules that were not as complicated as those found in artificial intelligence systems.

So, KPI began to define a business rules approach (described in von Halle, Business Rules Applied, John Wiley & Sons, 2001) that applied to the management of business rules behind every day business transactions.

As for the relevance of the business rules approach, I believe the business rules approach is even more compelling today than back then.

To appreciate the true magnitude and impact of this, readers need only consider the global economic panic of 2008. What rules were in place behind specific kinds of transactional decisions in particular industries? What regulation rules were lacking? Who was paying attention to these rules? What tools and techniques did they have for doing so effectively? What do we do now to better manage critical rules that drive businesses and sometimes entire nations? And how do we do it?
 
Larry Goldberg (LG): As Barb said, the relevance of the business rules approach today cannot be understated.

We say, in the preface to our book:

It is our conviction that the decision model propels the business rules approach into its next generation, a more mature practice for both business leaders and IT professionals.

BVH: As for the status of KPI, now known as Knowledge Partners International, we are the originator of the decision model. Our mission is to promote its relevance, usage, and advancement. We work with industry notables, individuals, clients, consulting companies, and software vendors wishing to leverage decision modeling capabilities in their projects and cultures for measureable business benefit. The new book is simply the beginning of a conversation about the decision model. We offer online and classroom training, and consulting assistance.

RSS: Barbara, your previous books have been about practical real-world experiences for how to leverage current analysis techniques (like logical data modeling) and technology (like relational database management systems). But this new book about the decision model is distinctive in a very important way. In fact, it is a new innovative theory that cannot be found elsewhere. Can you explain that distinction?

BVH: I am more excited about this book than anything else I have achieved in my career. This book introduces the decision model as a groundbreaking original new technique, never before revealed in a published book, but already utilized in practice with great success.

The book invites the reader to manage, not just data and not just individual business rules, but whole business decisions. These are expressed as normalized decision models, elevated to the status of a valuable asset, and directly tied to business performance.

RSS: What made you think we needed a new model? We already have process models, use case models, logical data models, dimensional models, canonical models, fact models, object models and so forth. Do we really need yet another model to learn and to manage?

BVH: Larry and I had been practicing the traditional business rules approach without such a model. Like other practitioners, we created process models and use cases, capturing business rules as a new, separate artifact. Standards groups have focused on how best to express these rules. This has been the current state of the practice until now.

While this has been somewhat successful, it is not overly so. Business rule projects typically do not gain the management visibility they deserve. And there is a lack of uniformity among business rule practitioners. Does this sound vaguely familiar? Can we draw a similarity between the evolution of business rule management and that of data management? It turns out that the similarity is startling. Let me explain.

In the 1960s, early data management professionals separated data from other aspects of systems. They created lists of individual data elements, storing them in homegrown or commercial data dictionaries or catalogs. Time was spent agonizing over business-friendly naming conventions and meaningful definitions.

Today, in an ironically similar fashion, business rule analysts separate business rules from other aspects of systems, too. They create lists of individual business rules, storing them in homegrown databases or commercial modeling or rule capture tools. Time is spent agonizing over business-friendly grammar or format and providing, for the underlying fact types (data elements) business-friendly naming conventions and definitions.

In the 1960s and ‘70s, data management professionals realized that lists of data elements become unmanageable. So emerged database design approaches featuring structural models for the data elements. These models were proprietary to the DBMSs of the day (IMS, IDMS, etc.).

Today, business rule professionals struggle with unmanageable lists of individual business rules. These eventually end up in business rule management systems (BRMSs) design deliverables proprietary to the BRMSs of today.

In the 1970s, it wasn’t long before there was a recognized need for a universal technology-independent representation of data. This need gave birth to logical data modeling in the form of IDEF1X, Chen Entity-Relationship Model, and others. But, a most impactful innovation was Ted Codd’s relational model. It was different because it provided a scientific foundation for organizing data, based on principles and concepts we now know as primary keys, foreign keys, normalization, referential integrity, entity integrity and atomicity. When this happened, DBMS technology became relational-based and data truly emerged as a recognizable asset.

LG: As Barbara and I contemplated the evolution of data management, we suddenly discovered that the most fundamental ingredient was missing in the business rules approach. There is no universal technology-independent representation of business rules and business logic. Specifically, there is no innovative model for business rules like the relational model is for data. This was an amazing realization that was staring us in the face.

Without such a model, any way of organizing business rules is acceptable because there is no mechanism, such as normalization principles, to measure the value of the organization. Without such a model, how were we to organize business rules in a predictable repeatable manner? How could we send out two analysts who would come back with the same business rule representation? Without such a model, how successful can the business rules approach really be? How successful would data management be today without a universal underlying model for data?

So, we asked ourselves, what would it look like? Who would build it? And how would it help the business itself?

BVH: At the highest level, the decision model, like the relational model, is easy to understand and to interpret by anyone who knows its principles. At its deepest level, the decision model is based on rigor that we believe will serve it well into the future. It is defined fully by three sets of principles: structural, declarative, and integrity principles.

RSS: So, how is the decision model like the relational model?

LG: At first glance, there are three immediate similarities that come to mind.

1. Business rules, like data, exist in their own right, independent of how they are processed and where processed.
   
   
2. Business rules, like data, have their own inherent structure, which is not the same as the structure of data, fact types, or process.
   
   
3. Just as the relational model prescribes a structure for data based only on properties of data, the decision model prescribes a structure for business rules and logic based only on properties of business logic.
   

These realizations led us to uncover the fundamental properties of business rules, devoid of other considerations. As a result, the decision model emerged having a rigorous structure for business rules based on concepts similar to atomicity, primary identifiers, functional dependencies, normalization, and integrity among its structures. From here, we developed a diagramming technique that can be applied to any set of business rules and, for each set, results in one and only one representation. Chapter 9 of the book is a detailed analysis of the relational and the decision model – similarities and, most importantly, differences. There are three chapters that go into details on the decision model principles.

BVH: There are three important points to remember about the decision model.

First, while some of its concepts are similar to concepts in the relational model, these concepts are necessarily different. In other words, each of these concepts applies to the properties of business rules, not to the properties of data, and this difference is critical. It means that the decision model behaves differently as defined by its principles.

LG: The second point to remember is simple. The decision model is its own model! Business rules and logic are no longer buried in or attached to process models, data models, object models, use cases, requirements or fact models. They have their own model because they have their own existence and their own reasons for existing. Making changes in business rules through decision models becomes possible without searching for them within, or related to data, object, or fact models and without seeking them buried in processes or use cases. The decision model stands out, stands alone, but connects to other models as needed. In other words, a decision model can be connected to many process models, use cases, data models, etc. In this way, it becomes a reusable asset.

We believe this is an extremely powerful discovery. If history repeats itself, it could be a magnificent beginning of the advancement of methodologies, tools, and automation options.

The third point to remember is that business people easily appreciate the value of decision models to the business itself. In other words, the decision model elevates business rules and logic to the status of a tangible and manageable business asset. Even more, an entire decision model can be tied to business performance metrics. In this way, the decision model emerges as a means for tuning the business’s operations and reaching business objectives. A decision model is successful if it leads the business to desired targets, otherwise the decision model needs to be tuned. The value of each decision model to the business can actually be measured or estimated, as we point out in Chapter 3 of the book. And so, it is a tangible and active business lever for use by business leaders, not simply a design artifact. So, the decision model is not really meant for data validation or constraint rules, but for rules leading to business judgments.

BVH: This means that some decision models are more important to a business than are others. So, decision models can be prioritized and assessed as true business investments. This makes it relatively easy to justify building them. If a decision model is not going to save money, minimize risk, align with compliance or increase revenue and profit, it may not be worth creating and managing.

Practice has proven that business leaders find entire decision models to be more tangible and relevant than individual business rules. This gives rise to the emerging discipline of enterprise/business decision management (EDM, BDM). In other words, business leaders want and need to manage business decisions, not individual business rules in a vacuum.

Also, of interest to the business-minded audiences, some business decisions are made in simple contexts (meaning that all of the fact types or fact values are known). Yet, some are made in complex or chaotic contexts (meaning that only some fact types are known while some must be determined). The crisis of 9/11 is an example of the latter. Chapter 3 of the book covers this in great detail, providing insights on how to use a decision model in various contexts.

RSS: I find this fascinating. So, you have used past experience in data management and its struggles to deliver a similar future in business rules?

BVH: Yes, absolutely, although the future is not business rules, but in the larger picture of business decision management. And with it comes some of the same pain and resistance as we faced in data management, but with similar if not greater value and future. TDAN.com readers who have waged political battles for the sake of data quality still have scars, I am sure. But, the rewards have been realized and data has become an asset worth protecting and worth business investment.

RSS: It sounds like the decision model would be of interest to TDAN.com readers because these readers already understand the value and methods for creating logical data models. So, who is the target audience for the book?

LG: The book is intended mostly for analysts (including data management professionals), business architects, and business people.

Analysts of all kinds already have relevant skills such as being business sensitive, detail oriented, analytical, and have the desire to simplify and clarify meaning. The book leads analysts through the justification, creation, and rigorous details of a decision model project.

For business (non-technical) people, the book explains in its first three chapters how to interpret and contribute to decision models; business architects can learn from the book how to use the decision model in developing business plans and the systems to implement those plans in a directly measurable fashion.

The last section consists of contributions from other people who are experienced with or exposed to decision models. Some represent specific practices (e.g., SOA, BPMN) and their relationship to the decision model. Others represent people who have experience in creating decision models on successful projects.

There is something in the book for anyone involved in a project that is concerned with managing effectively business decisions and business rules. These include SOA projects, BPM projects, or even simple requirements gathering (and test case development) for other kinds of projects.

RSS: Do you predict that some TDAN.com readers may become decision modelers and if so, why?

BVH: I do. Decision modelers, like data modelers, are people with a propensity for passion and rigor. Also, the principles for the decision model are similar to (yet, different from) those of the relational model. Data modelers will learn the decision model quickly.

Some readers will continue to apply rigor to data. Other readers will want to apply rigor to the business logic that drives the business because the business logic uses the data to make important high-quality business decisions. Also, decision models tend to be more agile than data models because business logic, by design, is destined to change whenever change is necessary. So, data modelers who are interested in enterprise agility are likely to become decision modelers.

A person who is both a decision modeler and data modeler is a valuable resource on any project.

RSS: Does the decision model invalidate business rule approaches or standards that are current or emerging?

LG: Absolutely not, and quite the contrary. It is important to note that the decision model does not replace current practices, but enhances them by filling a gap. Business rules can be captured according to any business rules approach and following emerging or current business rule standards. These captured rules can then be cast into normalized decision models as a pre-cursor to analyzing their quality and as input to automation design. So, the decision model simply improves the practices of today by adding rigor to the good work that is already underway. In fact, we have users who have successfully developed business rules catalogs using classical methods and are using the decision model as a means to group and analyze their existing rules.

BVH: So, where project teams have started to capture business rules or business rule statements and built fact models or data or object models, the decision model is simply the next step. The decision model is the transition from logical to physical design of business rules or business logic. Also, it is the platform through which business non-technical people can assess the quality of those rules and logic prior to turning them over for implementation. With a simple list of business rules such assessment is virtually impossible.

RSS: The book also discusses how the decision models relate to other related trends. The book explains that the influence of the decision model on business process management and modeling is very significant. Can you explain this?

BVH: I suspect that many TDAN.com readers have been involved on projects that create business process models of one kind or another. For projects other than the simplest process, it is common for such a model (or models) to be large, complex, and serve as wallpaper around an entire conference room. Such models quickly become unmanageable and often are abandoned.

The good news is that Larry and I have found that this complexity is usually an indication of mixing “process” and “ business logic or rules” within the same model. Chapter 4 of the book points out a significant difference between the two – process is procedural (step-by-step) but business logic and rules are really declarative (as data is!). Sadly, today, both are modeled in a procedural model because there was no other model for doing so.

By understanding the difference between procedural process and declarative logic, an amazing transformation happens:

• Business process models become simpler by the removal of declarative business logic structures (just like process models became simpler by removal of declarative data structures).
  
  
• More of the business process models become generic and reusable because the differences in business logic are not in them.
  
  
• Changes can be made in the business process model independently of changes in the business rules and logic and vice versa.
  
  
• Decision models serve as a foundation for decision services in SOA.
  

RSS: Does the decision model require a data model?

BVH: TDAN.com readers certainly understand, more than anyone, how important it is to get agreement on names and definitions of data elements (terms, facts). This is equally important for decision models. So, existing glossaries, data models, object models or fact models accelerate the delivery of decision models. Any lists of business rules, whether culled from people or documents or code, are also a starting point for casting them into a normalized decision model structure.

There are some differences between a data model and the fact types used in a decision model. One difference is scope. The scope of a decision model is one business decision, not an entire enterprise. This means that a decision model has a specific beginning and end. Another difference is that a decision model references persistent fact types but it produces non-persistent fact types as conclusions to decisions. These non-persistent fact types need to be named and defined for the decision model but often are not included in data models.

Another important difference is that, in practice, there is no need to have a data model (or object model or fact model) prior to starting a decision model. Often, we start with a decision model for which we then develop a data, object, or fact model. Most often, the process is iterative. The decision model drives the data, object, or fact model and vice versa. Of course, in the end, there should be a data, object, or fact model behind every decision model depending on how the decision model is to be deployed in the enterprise.

There is another topic that may be of interest to data management professionals. You are accustomed to creating various levels of data models, sometimes representing Zachman rows 1, 2, and 3. The same is true for decision models. We create a form of a decision model for scoping, for business audiences, and for designers. We often create decision models that are only the structure of the business logic without the business rule or logic details. Readers can appreciate that, even with just a structural decision model, we can deliver automation prototypes, thereby playing a critical role in iterative, agile development. We do not need to know the entire details of the decision model and its referenced fact types (pieces of information) before delivering some form of automation. And one more point, some quality assessment of the logic can be completed even without the details, just like a data modeler can tell that a relational data structure is not normalized without yet knowing all of its rows.

RSS: What do you mean by a business decision and how is it related to a decision model?

LG: The business decision is the all-important glue that ties a decision model to the business itself. We define a business decision as “a conclusion that a business arrives at through business logic and which the business is interested in managing.” If a business decision is not worth managing, a corresponding decision model ought not to be created.

When a decision model is created for a particular decision model, it ends with the conclusion for that business decision. It starts with inputs that can be obtained from user input or database fields. In between, business logic executes (in groups of third normal form logic statements) by which conclusions emerge from conditions and the final result emerges.

So, a business decision can be a decision that is made within the course of a manual process, automated process, or a strategic process (such as for mergers and acquisitions).

RSS: Can you give some real world examples of business decisions that would have a decision model?

BVH: Once you understand what a business decision is, you find them everywhere. This is similar to what happens once you understand what an entity is – you find them everywhere. We have fictitious examples of business decisions in the book that are based on real-world projects. But some examples include:

• Determine a Claim’s Payment Eligibility
  
  
• Determine an Insurance Policy’s Renewal Method
  
  
• Calculate a Vendor’s Performance Index
  

Possible conclusions from the first one may be “eligible for payment,” “denied for payment,” or “requires research.” The decision model would include instances of all three conclusions along with related normalized “decision tables” leading to each instance.

As readers might surmise some decision models are large and complex, others are simple and small, and the rest everything in between. Some decision models may be similar among companies in the same industry, even standard, and some may be extremely proprietary.

RSS: So, the decision model has a graphical representation and corresponding metadata, like a data model. Your book describes what it looks like. Are there tools for creating decision models?

BVH: Today, the most common tools used in practice to create graphical decision models are Visio and Excel. Some clients enhance process modeling tools (that can be extended) to include support for decision models. We are hoping to see decision modeling tools emerge in the marketplace in the next few years.

RSS: This is great stuff. Can you summarize why this book should be of interest to TDAN.com readers?

BVH: TDAN readers, as fellow data professionals, are people who seek simple solutions to complex problems, intriguing and innovative minds. The decision model offers to TDAN readers an avenue for expanding existing skill sets and moving closer to what drives the business in its intended directions. We believe TDAN.com readers will find the decision model to be the beginning of a new future for modeling tools and for innovative automation software. We have received amazing endorsements based on the book manuscript and on success stories.

This book is just the beginning. We look forward to readers who start creating decision models. We invite readers to evolve its definition and to share experiences through our up-coming regular column in TDAN.com.

RSS: Tell the readers of TDAN.com how they can get a copy of the book?

BVH: The title of the book is The Decision Model: A Business Logic Framework Linking Business and Technology published by Auerbach. There is a link for ordering it at www.TheDecisionModel.com.

RSS: As I mentioned earlier in the interview, you will be starting a new featured column on the pages of TDAN.com. Can you describe your upcoming column on “decision modeling” that begins in the next TDAN.com issue?

BVH: Naturally, the first column will be a brief primer on what a decision model looks like. We will follow this with real-world case studies and possibly cover selected chapters (chosen by TDAN.com readers) in depth. Most importantly, we invite readers to share their questions, answers, and good and bad experiences through the column.

RSS: Thank you very much for taking the time to sit down with me and chat about your new book and decision models. I hope that the readers will run out to the store (do people still do that?) and get themselves a copy or two or ten for themselves and their colleagues. Do you have any last words of wisdom to share with the TDAN.com readers?

BVH: This interview and our new book are just the beginning of the conversation about the decision model. I believe it has a great future. In addition, many of you already know that my allegiance and respect for data management professionals is supreme. I admire all of the readers for their skills, analytical minds, and unrelenting perseverance in making things right in the data world. I look forward to some of those same minds repeating that success with decision models.

RSS: Thanks again and I am looking forward to publishing you new featured column and I hope that we can find other ways to work together in the near future.


  

The Decision Model: A Business Logic Framework
Linking Business and Technology
By Barbara von Halle & Larry Goldberg
Special Offer to Subscribers of TDAN.com for
CRC Press - Auerbach Publications
Take 20% Off when you order online (and take advantage of free standard shipping):
www.crcpress.com
Use Promo Discount Code 642AH to apply discount.