The SBVR standard was accepted by the OMG more than 5 years ago.  Version 1.2 was released in November 2013.  SBVR has attracted interest and has led to a number of scientific articles and updates in BRCommunity.  However, there has not been a real attempt to popularize it — no 'SBVR for Dummies' or 'SBVR Explained' ...  but now this has changed!  Rob van Haarst has just published his book entitled "SBVR Made Easy."

Rob is a consultant in the Netherlands and a product designer for USoft, a software vendor who has a business rule engine in combination with a declarative (4GL) development environment that includes an SBVR-based language parser for functional specifications.  Besides helping to create new products, he builds custom business systems and is involved in teaching.  But he wrote this book in his evening hours, independently of his employment for USoft.  Rob, why did you do that?

Rob:  Ever since I discovered SBVR, about five years ago, I have been enthusiastic about it.  So it has been disheartening to hear so many people complain about it.  People seem to have one of two problems with it.  Less experienced people find SBVR too difficult.  More experienced people often say that SBVR does not offer anything new.

As for being difficult, certainly the SBVR specification itself is not easy to grasp.  We need all manner of secondary efforts and initiatives — communities, tools, best practices, events, mediators — to make it usable in specific settings.  I wrote this book because I wanted to contribute to that.

A book that explains and motivates SBVR in a logical order is definitely much more readable than the SBVR specification itself, which (by necessity) is rather formal.  You say that yourself in your introduction of the book.  If critics say that "SBVR offers nothing new," can't we use existing material to learn about SBVR's theory?

Rob:  It's mostly correct that SBVR offers nothing new!  This can't be surprising because SBVR is based on formal logic, linguistics, and conceptual modeling.  Yes, these disciplines have spent centuries formulating the conceptual metamodel that underlies SBVR and there are books about it.  Also, the case for business rules as a cornerstone concept for business modeling had already been articulated admirably by Ronald Ross before SBVR appeared.  But SBVR's value is in bringing these disciplines together in a consistent way and in standardizing the result.  So we also needed a book that explains and summarizes this added value.

Do you believe your target audience is already familiar with the disciplines that underlie SBVR, or can someone read your book without any background in formal logic, linguistics, and conceptual modeling?

Rob:  I have written this book for a broad audience.  It does not require any prerequisite knowledge.  However, it does not spend much time explaining what other techniques there are, what general workshop techniques you can apply when you start working on specifications with a group of people, or who to talk to when you want to elicit business knowledge.  It is aimed at people who already have those skills but want SBVR to help them professionalize their specifications. 

The book covers all conceptual aspects of the SBVR standard in depth except for the part on formal logic.  It focuses on using the SBVR concepts to describe knowledge or create specifications.  Therefore I believe it may be used by people with different titles (e.g., business analysts, IT architects, process designers, quality assurance officers), each of whom may emphasize different aspects of SBVR (e.g., vocabulary, rules, models, language usage).  You are yourself an SBVR practitioner.  Did you learn anything new in the course of writing this book?

Rob:  Absolutely.  The writing forced me to clarify aspects that I had never really come to terms with, both at the level of actually understanding them myself and at the more practical level of knowing how best to summarize, present, or teach them.  For example, I always instinctively liked the combination in SBVR of business terminology and business rules, but the book has really allowed me to articulate why this is such a powerful idea.

Also, I have always found the distinction between rules and requirements hard to explain.  For years, my strategy was to gloss over the distinction whenever it didn't seem to matter.  This book forced me to get the explanation right and that is ultimately more helpful.

We both live in the Netherlands, a small country in Europe.  Why do you think there are so many rule-related initiatives from the Netherlands?

Rob:  Yes, it's true that we have relatively many tool vendors, consultants, and researchers who are active in the business rules arena.  It may need some anthropological research!  I don't have the answer, but I do know that some very influential thinkers about modeling are Dutch and that their material is being passed on to new generations and a new workforce at colleges and universities around the country.

The influence of Sjir Nijssen has been, and continues to be, decisive.  He is the founder of object-role modeling, which is one of the disciplines that underlie SBVR.

Jan Dietz' work on enterprise ontology in Delft is a more recent alternative to the object-oriented canon.  Object orientation has brilliantly solved key problems of software code management, but it does not map comfortably to natural business language, and it can limit functional modeling if you allow it to be your sole conceptual framework.

Nijssen's and Dietz' model-driven approaches are 'rule-related', as you say.  But the most recent versions of these initiatives encompass both rule orientation and process orientation:  let's not forget that you really need both!

Agreed!  Actually, we also have some other sophisticated Dutch research in that area:  Petri-nets and Archimate.  The Dutch are also well known for their very direct way of communicating.  In the preface that I wrote I emphasized this and even called your style "blunt and arrogant."  How did you feel when you read that?

Rob:  When I think about the years of selfless effort that the members of OMG's specification committee put into SBVR, yes, there is some arrogance in building a whole book on the sole idea of summarizing and criticizing this work.  Some may feel it is an easy win, or a case of taking advantage of the anonymous efforts of others.

Blunt is about manner; I don't agree that the book is blunt.  However, culture may play some part.  Native English or French writers have a whole tradition behind them of being courteous and diplomatic in written language.  For a Dutchman it's harder to tap into this tradition, but also that was not my aim:  I have tried to write in practical, international English, which may easily come across as direct.

The book is definitely more practical than the SBVR standard due to the way it is organized and its use of examples and anecdotes in each chapter.  Can you give some examples of the practical tips and insights that your readers may get from this book?

Rob:  Many organizations focus on describing process flow as a means of expressing business operation.  They may learn that process flow is just one aspect of business knowledge.  They may not be aware that OMG created a sibling of BPMN for natural-language statements, namely, SBVR.

I also see that many professionals invest in better business vocabulary, definitions, and rules but have a hard time producing this material.  They are uncertain about language form and often write ambiguously without realizing it.  This book gives them a practical framework to cope with these difficulties.

Then there is the issue of managing large numbers of definitions and rules.  Almost all the organizations I know still use traditional business documents or spreadsheets, which are superficially user-friendly but ultimately inflexible.  My book explains in detail why this is so and looks at better ways to present and structure business logic.

Finally, the book emphasizes that a focus on deliverables detracts seriously from understanding the business itself.  It also leads to specifications that are unnecessarily technical.  Of course, book writers don't feel the constraints of budgets and project planning, so it is easy for them to advocate a more fundamental approach.  But it is also my personal conviction and on that I am not alone.  I have tried an approach here that parallels Bruce Silver's "BPMN Method and Style" for BPMN.  In his work, "non-executable BPMN" is clearly explained and given much weight.  I have similarly tried to show the importance of "non-executable SBVR."

So I would like my audience to avoid the old trap of wanting specifications that translate straight into software requirements for a specific project, or even into the working software itself.  I hope my audience understands, after reading this book, that SBVR is an extremely powerful method to formalize knowledge, forming a solid base for contracts, end user documentation, work instructions, process design, and product development.

Last but not least:  how did you publish the book, and how does one order it?

Rob:  This is my first publication so I asked a friend who is a publisher to help me.  Together we decided to self-publish the book through Amazon.  The benefit is that everyone can order the book easily and that it is shipped all over the world.  They were also able to do a full-color print for a reasonable price so that the reader benefits from the coloring typical of SBVR-style text formatting.^[1]

Thank you very much for this interview, and I would like to encourage BRCommunity readers to write a book review at Amazon.com.

Silvie Spreeuwenberg

References

[1]  Rob van Haarst, SBVR Made Easy, ConceptualHeaven, 2013. Available from Amazon at http://www.amazon.com/dp/9090279334/ and also through Amazon's European sites, for example, at amazon.co.uk.

# # #