We rather glossed over the issues of modeling in the September 24 Webinar on Rule Discovery, but they really are fundamental to the process of developing a business rule application. I’m going to spend some time going into a little bit of depth to the kind of models that you need on the business side, and why I think the UML versions of these models are the best and easiest to work with.
Since the people who tend to do the modeling are usually the IT-based Business Analysts, this post is more or less focused on them. But the best way to do this modeling is almost always using Agile techniques, where the IT gal and the Business guy sit side by side and figure it out!
First of all there are three kinds of models associated with the early requirements/discovery phases of rule based systems. These are the structural models, the functional models and the process models. They answer three different important questions. Structural models describe what the world looks like to the business, Functional models explain which decisions need to be made, and Process models explain how the decisions need to be put together to achieve the business policy. Let’s look at these models one at a time, in that order. Today I’ll look at Structural models.
Structural models are critical. No one can write rules without a way of speaking about those policies. The structural models provide the language that the business will use to talk about the models. That doesn’t just mean the vocabulary, although vocabulary is a part of it. It means the grammar, too. Oscar (my co-blogger) would take it even further, and call the model one representation of an ontology. That is, it’s a system of talking about what exists in your business domain. Ontology seems a little metaphysical to me, so I’ll stick to language, even if it’s not as complete.
A UML model lets you talk about the business in terms of the objects, both physical and conceptual of a business. For example, in the mortgage example we used in the Webinar, we have objects like a House, and a Borrower, physical things, and conceptual things like a contract, or an inspection (an inspection report might be physical!). And you can talk about the relationships between those objects (a borrower is buying a house) in order to create your rules.
The way the UML Class diagram goes together, you can use real world words to define the objects, and their attributes, and you can use real world words to define the relationships. Plus the relationships are easy for business people to understand and to relate to. My experience is that it only takes a few minutes to get the basics of a UML class diagram through to someone who is not familiar.
There are other ways to model structure, but they are all data-centered. And if you want to do them, you're probably a technical person, and your business folks are getting ready to scream. The problem with data-centered is, unless you are using a seriously object-oriented database, it doesn’t reflect the real world. That’s a hurdle for the business folks to cover. (Cue the scream, now, business folks!) And it is probably represented as an entity-relationship diagram (which is pretty obscure in many ways.) Another hurdle.
Worse yet, your data model might just be a dump of those legacy relational tables with all the key information and no relationships. Those things are hard for DBAs to get through, much less the people making your business decisions.
Plus data models are, well modeling data, not modeling the world. For business folks, you need to model the world. Their world! This seems obvious, but it’s really, really important. They need to really get it, if they are going to take over the responsibility for the rules – and they are, aren’t they? That is the great advantage of the BRMS paradigm!
OK, so your data will still be in a database, and you’ll need to map between the models. But using a class or object model for your structural description will make the whole process of getting the rules to reflect the business much easier. And as an added bonus, if you are using JRules, your model will translate seamlessly to the BOM (and in many implementations, the XOM, too!) So your architect won't get all huffy on you!