Implementation-independent design of business logic, integrated with business processes and information

BiZZdesign has a long tradition in model-based design and improvement of organizational processes. Building on this tradition, we have extended our portfolio with a method and tool for implementation-independent design and analysis of business logic, which seamlessly integrates with business process and information design.<h2 class="p1">Why yet another modeling domain?</h2>A problem that many organizations are facing is that the rules originating from legislation or business policies eventually end up in many different places in the organization, with many opportunities for misinterpretation along the way. The resulting business logic is hidden in business processes or hard-coded in software, which makes it very inflexible and hard to manage. Although most of the current business rules approaches promise to offer a solution to this problem, by “separating the know from the flow”, this promise is often not fulfilled, due to a number of reasons:<ol><li>There is still a lot of confusion as to what a business rule actually is, and what different types of business rules exits.</li> <li>Business rules are often specified in a very detailed way, in one of the proprietary languages of a rule engine. As a result, they usually have a technical 'technical’ flavor, which makes it difficult for business stakeholders to verify them, and they are tied to a specific implementation platform.</li> <li>Business rule specifications, and the tools that support them, are often poorly integrated with the existing process and information models and tools.</li></ol>When modeling your business logic, business processes and information as separate, coequal domains, loosely coupled through a limited set of linking elements, the resulting designs become much more flexible and manageable. By first specifying them in an implementation-independent way, it becomes easier to verify whether a design actually meets the requirements of the business. And once there is agreement on the correctness of the design, different implementations can be derived from it.<h2>Towards an integrated design</h2>As illustrated in the picture below, your business processes, information and business logic can be developed in separate design ‘flows’, in an arbitrary order; but ultimately, these flows will have to come together, to form an integrated design of your organization:<img alt="The integration of Decisions, Processes and Information" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130517_Implementation-independent-design/Integrated-decision-modelinglegenda.jpg" style="width: 607px; height: 550px;" title="Integrate Decisions, Processes and Information"/>For the implementation-independent design of business processes, we use our proprietary modeling language Amber or the BPMN 2.0 standard. For information modeling, a wide variety of formalisms is available, e.g., Entity Relationship diagrams or UML class diagrams. To complete the trio, we have adopted The Decision Model, as described in the book “The Decision Model: A Business Logic Framework Linking Business and Technology” by Barbara von Halle and Larry Goldberg, as our language of choice for designing the business logic. This approach turned out to be perfectly suited for our purpose. It matches a simple graphical notation to model the decision structure with an intuitive tabular specification of the business logic and a rigorous set of integrity principles. Moreover, it can be combined with business process models and information models in a natural way.<h2>The Decision Modeler</h2>On June 11th, we will launch <a href="http://www.bizzdesign.com/tools/the-decision-modeler/">The Decision Modeler</a>, our software tool a tool for implementation-independent modeling and analysis of business logic based on The Decision Model. Because the tool is part of the BiZZdesign design suite, decision models can be linked to other models in this suite, including business process and information models, but also enterprise architecture models and requirements models in the ArchiMate language.The figure below summarizes how the different elements of a decision model in The Decision Modeler are related to each other, and to element from process and information models.<img alt="" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130517_Implementation-independent-design/The-Decision-Modeler-relations.png" style="width: 600px; height: 468px;" title=""/>In my next blog in this series, I will give a more in-depth description of the concepts and functionality of The Decision Modeler, and apply the approach described here to a real-life example. In the meantime, if you have any questions or suggestions, please send me an e-mail on <a href="mailto:h.jonkers@bizzdesign.com" target="_blank">h.jonkers@bizzdesign.com</a>, or add a comment below.