Take care of small things and the big things will take care of themselves

In this post our Business Rules trainer Victoria Ichizli-Bartels will discuss why paying attention to details is important while defining business rules.

In the previous articles of the Bitesize series on Business Rules, especially in the one on why you need to be in control of your busines rules we pointed out how important it is to have a good overview of one’s project’s or company’s business rules and how the various types interact.

However, as any complex and multidimensional discipline, Business Rules in general and S1000D Business Rules in particular have a couple of paradoxes as one of their main features.

The one I would like to address today is the following. On the one hand, it is important to keep an eye on the big picture and not lose sight of the whole implementation map for S1000D in your project or organization. On the other hand however, if you don’t take good care of details, even the best overview won’t help you. In both cases, losing sight of the big picture and not taking care of details, you — or at least your project and S1000D implementation — are doomed.

This seemingly hopeless situation has a very simple solution.

American poet Emily Dickinson (1830 – 1886) famously said, “If you take care of the small things, the big things take care of themselves. You can gain more control over your life by paying closer attention to the little things.” Yes, Emily Dickinson was most certainly right and this is still relevant in respect to S1000D and Business Rules today.

Let’s consider an often occurring scenario. Defining elements and attributes might seem such a detailed and “nerdy” task. But when if you look closer at the content of many of the attributes and elements defined by the S1000D you will notice how vital and how “big” they actually are for your project and organization.

Let’s take model identification code for example. One could say, “Ah, we’ll just define one. We might add some external ones for the products of our partners used in the system, but for our product systems we’ll use one. It’s easier that way.” Somebody else might say, “We better define a model identification code for each configuration of the product. The more the better. Otherwise we might need to redefine the structure again and again.”

This tendency to decide fast on something and later see whether it makes sense or not might cause considerable delay and costs. In both, seemingly very opposing examples, the result could result in considerable rework and considerable maintenance costs.

Of course one could argue that with today’s techniques of Integrated Logistics (Product) Support the coding of data modules is not that critical as long as the corresponding information was maintained correctly inside a LSA (Logistic Support Analysis) Database.

But is it really so? You still need a concrete target to send information to and your authors will still need to adjust and link the corresponding data modules so that your technical publication is rendered correctly.

So what is the solution with the model identification code and all the other of hundreds of business rules decision points inside S1000D?

Yes, the solution is to take good care of each one of them. If you give a diligent consideration of the structure of your product — that would mean that you are taking a closer look at your product by considering your product’s breakdown and SNS (Standard Numbering System) structures — you will identify which part of your product in focus will be reused in other configurations and projects, and therefore deserves a separate model identification code and which variations in configuration can be coded using other means like system difference code, model item category code and/or other.

In addition, taking good care of one of the Business Rules Decisions — of course always with the end-user in mind — will lead into necessity to take good care of the next one, and the next one, and the next one. Don’t give in to temptation to disregard something. Make every decision, even a decision to ignore certain parts of the specification and decision points related to them, deliberately and consciously.

Let’s add here some more to the paradox of this all. And this would mean to add a statement starting with the word but.

Yes, do make the best decision you can, but be willing to be flexible in your decisions. Be willing to revisit and consider them again as you make new recognitions by moving from one decision point to another.

Then remember not to dwell on one decision point for too long. Yes, consider it from all angles you can think of and then move further.

Most important of all, don’t judge yourself, or anyone involved in your project, for having made an earlier taken decision, if you consider to rework it. Judgement and complaints are waste of time, because in each moment there is new context. And in each new context, your project is different. You are different as well.

So take a good care of small things and watch how big things take care of themselves.

View all bitesize business rules

Looking to learn more about business rules in the world of S1000D?

Book your place on our S1000D Business Rules training course delivered by Victoria Ichizli-Bartels.

This course is for anyone who needs an understanding of the principles of S1000D prior to implementing the standard.  It covers the technical and business aspects of Business Rules and how to implement it and its implications for technical publications. Find out more.

About Victoria Ichizli-Bartels

Victoria has been working with S1000D since 2004, first for German Defence, then for a major S1000D software vendor and today as part of her own business. In the S1000D community, Victoria serves as the Business Rules Working Group (BRWG) chair since 2005.

To book your place call +44 (0)20 8722 8400 or email moc.n1614509404okem@1614509404greb.1614509404ennas1614509404us1614509404