Introduction to Rules

Can products be flexible? This is one of the most fundamental questions in R&D. Any kind of R&D, in fact. Can the bridge across the river be flexible? Actually, if it isn’t flexible, it wouldn’t be a practical bridge. As the environment in which the bridge is constructed changes (and it does), architects and engineers who built the bridge needed to account for a variety of changes that would be taking place and affecting the structure. And this is an example of a seemingly static structure. So, between a bridge - which we all want to be stable and static, but flexible enough to survive the changes in the environment - and, let’s say, a building, the expectations of flexibility go up as we want to be able to move the not-weight-bearing walls and rearrange the configuration of rooms if we want to, and so on.

One could even make the argument that as the number of moving parts in the product increases, so does the expectation of flexibility. And when it comes to software, we want it to be the ultimate form of flexibility, for it is abstract by definition.

So why is it so difficult to build software products that would be this flexible? It’s not particularly a straightforward question, and might require some deeper investigation. It might be a good idea to start this deep dive by taking a quick survey of the transformations that occurred within the software industry in the last 40 or so years. As a side effect of this exercise, listing these evolutionary steps might actually serve as a kind of checklist an organization could use in its evolutionary path. Some of these things are sometimes overlooked.

Building with components

During a remodeling project, a bit of electrical work needed to be done and the electrician was compiling a list of parts he needed in order to complete the wiring work. He wouldn’t think of developing his own electrical switches or outlets. These parts are quite common, standard equipment, built according to specifications and available at the hardware store. We just purchased them and there wasn’t any need for designing any of them. Done.

In software, we actually went through some industry wide growing pains and figured that following this model of building common and standard parts was quite practical. We liked to call standard parts components. When we need a database designed as part of our product’s grand design, we wouldn’t think of building our own database engine, or even a set of some connectivity tools. We’d compile a shopping list of components, investigate what’s on the market and select the ones that would satisfy our specs. Done.

Can this concept be expanded to address the needs of every part that we’d need? Well, maybe and maybe not.

Reusable components

If we can’t find the component that we need, we might have to resort to designing and building our own. But then the decision for us to make is whether the component we need to build is so very unique that it wouldn’t be used again anywhere else (at least within our own organization), or it is something that could be reused in a number of places (again, at first within our own organization and then perhaps elsewhere).

In any case, designing this new component in such a way that would leave our options open, might be a good idea. After all, we might think today that it is so very unique, only to discover a little while later that it really isn’t that so very unique and that it might serve similar needs in other projects and products.

Services

These reusable components – what a great idea. Just like an electrician escaping the need of designing his own components, we escape the agony (crazy thing but some consider it fun) of having to design the database engine and connectivity components. Of course, let’s not forget that we added our own designed components to the vast library of components for the world at large. So we’re on the right track – the world of componentware.

But then another question popped up, almost as a result of the natural progression of things. The question of distribution and the intended use. An electric outlet is distributed by way of being physically placed on a shelf only to be picked up, purchased and carried out of the store. The aspect of physicality in this scenario could as easily be replaced by the fascinating machinery of e-commerce. In either case, however in the end it needs to be physically embedded in the wall, configured there and remain there for all the times that it will be used. So given the current infrastructure that includes all the physical buildings which we find useful, there is just no way around that – it needs to be embedded.

But in the software universe, this constraint is very handily removed. We might choose to embed a database component in our code (and in some cases it might be a really good idea), or we might prefer to have it available to us as a service. In this case we’d have to trade the exclusivity that an embedded component would offer. Instead we get the power of sharing the data with a larger pool of products and users, and a variety of ways of exploiting it. As an added bonus, the service would be maintained by someone else, an independent entity that would care for it and make sure the availability and security are no longer any concern of ours. So, given certain pattern of use, wrapping the component into a service answers one more question – distribution. We don’t have to worry about physically wrapping up the component into some media and physically sending it anywhere - because it’s always available everywhere, as a service.

Then we go right back to the business of striving to be flexible. We’ve discovered that it’s a good thing to be building not just components, but reusable components. Then we’ve discovered that wrapping these components up into services is a really nice addition to the list of choices that we’d have. But how does it address this issue of flexibility? Well, directly it doesn’t but indirectly it does.

If we didn’t have the benefit of using components and services we’d be moving around some large amounts of code every time we’d need to reconfigure something in our products. With components and services we only have to reconfigure references to these parts, not the parts themselves. A lot less to worry about, which is a good thing.

Object Oriented Technologies

And what else is part of this flexibility business? Our natural inclination to build things that resemble ourselves and our environment, and software is in no way an exception.

Welcome to the Object-Oriented Design (OOD).

By categorizing and classifying what we know and what we experience, we can build virtual models full of objects that carry the same properties as the real objects and that behave in similar ways as the real objects do. While the detailed discussion of the OOD and related technologies is a vast subject which has been explored in volumes of publications and deserves a set of devoted articles, I will only cover OOD as it relates to the issues of flexibility.

The ability of classes (which are used to create objects in OOD) to morph is what makes the OOD models so flexible. It is the biggest contribution that objects make to our efforts of building flexible software products. A perfect technology that we’re so happy to exploit because we can change our virtual models to keep them in sync with the ever changing environment in which these models operate. As the rules of engagement which the real world objects must obey change, we can adjust the object rules within our models accordingly and stay harmonious. We can introduce new behavioral patterns into our existing models, without breaking the existing patterns and without breaking the models.

Rules

Oh, these rules of engagement which we just mentioned, the ones that we need to program into the objects – well, that’s exactly it, they need to be programmed. So if we have a class called Promotion which our model uses to run a special that would affect objects of class Buick, then there might be a rule in Promotion stating that if Buick has been in the inventory for more than 6 months then the price is discounted by 10%.

Now, every time our model encounters an object of type Buick, this Promotion rule will adjust the price if the rule conditions are satisfied. Nice, right? Yes it is. But we’re back to the programming problem stated earlier – we wrote the code for this rule which means we need to maintain it. The two variables here are duration (6 months) and the percentage (10%). We programmed these values into the Promotion rule and released the product. When a month later the sales department makes a request to change both of these values, the programmer responsible for this rule would need to make necessary changes, run the product through a QA cycle and make another release. And this is the cycle that, obviously, could repeat 2 weeks later or even the same week. So the programmer isn’t doing some design/development type work that might result in adding value to the business by building new products, but is spending his valuable programming time adjusting these rules.

Now, we have come a long way by introducing the objects and OOD into our products. Even though it reduced the amount of code that we need to be modifying when changes are required and it reduced the risk of breaking the system when localized modifications are applied, the programmer is still the one tasked with making these modifications. But maybe we can change that.

Welcome to the Rules.

That rule that we just analyzed – maybe we could take it to the edge of our model and just a little bit beyond, like maybe we could expose the rule to the sales department and let them make the modification, then test it (kind of a presto QA cycle) and if they like the result, just let the system use the new rule (in the world of rules this is called “rule execution” – yes it does sound a bit terrible but it is quite harmless). Well, just in case something is wrong, and they need to revert to the previous – and obviously very safe – conditions, we wouldn’t want to let them change our original rule. We’d protect our rule, tell them they could create their version of our original rule, and then indicate to our model that their version should be executed instead of ours. And yes there is a “training” step. It would involve the programmer explaining the concepts of rules and what could be done with them, and teaching the sales department how to use the tools and so on.

But it’s definitely worth the effort because as a result of this “rules” transformation, we have achieved this state: the programmer is basically free to carry out his ever so important design/development type tasks that add value to the business, the sales department is ecstatic, they now have obtained control over the process of changing the rules without being dependent on the programmer (they like to call it “self-service”), and we can move on to focusing on the next big challenge.

How flexible can products be?

That is the subject for our next discussion