How to link Business Rules with Business Objects

As I look into linking the business layer with other perspectives in enterprise architecture, the following question came to me: “How do I link business rules with business processes, business objects and even with data objects?”

Inspired by this article from Antonio Plais on business rules,  I have looked in depth into ArchiMate Enterprise Architecture Modeling Language (ArchiMate 3.0 specification). I illustrate what I have learned by relating elements from three different layers from Enterprise Architecture, namely, Business Layer, Motivation Layer and Application Layer. The following diagram shows an overall view of element types in these layers using Sparx Systems’ Enterprise Architect:


Business Layer

Let’s start by defining the business processes and the related business objects. The relationship from a Business Process to a Business Object are:

  • access: a type of dependency relationship that indicates that a process acts upon (e.g. read, update, delete) an object.
  • association: an unspecified relationship between any two elements.

The following diagram shows the Business Layer with the Business Process ‘Create Recipe’ that creates the ‘Recipe’ business object using the access relationship.


Motivation Layer

The Motivation layer in ArchiMate represents the reasons that guide the solution. Adding motivational concepts from this layer, I use a Requirement element to represent business requirements.

The possible relationships from a business process, business object or data object to a requirement are:

  • realisation: a structural relationship that indicates that one element plays a critical role in the operation of another element.
  • influence: a type of dependency relationship that indicates that a element affects the other element (e.g. positively, negatively).
  • association: an unspecified relationship between any two elements.

On the other hand, the relationship possible from a requirement to a business process, business object or data object is association.

From these options, I selected realisation due to its stronger meaning to demonstrate that one element realises the other, in this case, a business process realises a requirement. The others relationships were not selected because association is generic and influence is the weakest type of dependency. The ArchiMate specification mentions: “For weaker types of contribution to the realization of an element, the influence relationship should be used” (section 5.1.4. Realisation relationship). In addition, the influence was created to link motivational elements, specific to Archimate, which are not in UML. Thus, the realisation seems the best suit for this case.

The following diagram shows the business process ‘Create Recipe’ and the business object ‘Recipe’ realising the requirement ‘Possibility to update portions’.


According to ArchiMate, a business rule is a specialisation of a requirement. There is no specific element to represent business rules in ArchiMate. But, we could use the same element as from requirement. However, in a context where there are already business rules, a businessRule element can be used to make an specialisation of the requirement element.


Application Layer

Going to the application layer, the relationship between data object (application layer) and business object  (business layer) is realisation.

Considering a business rule as a specialisation of a requirement, the relationship of a data object to the business rule is a realisation, following the same reasoning for relationships towards requirements.

The data object ‘Recipe’ realises the business object ‘Recipe’ and the business rule ‘Update portion of ingredients’. The user can increase, decrease portions and reset to original portion.



Git: How to know if your directory is already under version control?

There are of course several options to find out if a directory is under version control, depending on what you need, such as do it manually in command line or in your program in python, etc. For that, just Google it and you’ll find solutions, such as this one on stackOverflow.

Now, I just want to determine if my directory is under control.

First option: Go to the command line, move to your directory and type:

$ git status

The result is shows that there are no changes, thus, nothing to commit.
Note that I used

$ git status -u no

From the Git documentation, you see that -u no is not to show untracked files. I had tried before without it and it showed a long list of untracked files that did not allow me to see anything else. Since my goal here is just to see if it is under version control, that message is enough to know that it is.

Just before, you see that I tried with another folder, which is not under version control, and the error message confirms that it is not a git repository.

Second option: Using SourceTree:

1) Open to SourceTree
2) Click on “Create/New”
3) Click on “Add Working Copy”

4) See on the list of “Unstaged files” that files are:
– Clean
– Modified
– Missing
– Not tracked
For the modified: On the right, you can see what was changed in the content.

On the top left: you can see how many files were:
– Added
– Modified
– Not tracked

5) When you click on the master branch, you see that a commit was done and see all the files that were committed at the bottom and their content on the right.

Now that you are sure your directory is already under version control, you can drag and drop the files to the list of “Staged files” on top, which will be included in the next commit.

For more references, check out the Coursera Course on Data Scientist Toolbox available on github (create new repo, fork and clone a repository, git workflow, basic Git Commands) as well as this quick Git guide from the Data School and more on the data scientist’s toolbox site.

Changing R library path

I’ve been using R to do data analysis for process improvement for some time now. I’ve learned so much in the past year that I want to write many posts in a specific order, but they end up being kept in my mind. That’s no good. This year, I’ve decided to start posting every little new thing I learn in no particular order and no particular importance. Even if it’s simple, if I’ve just learned it, I’ll share it.

So, here is my most recent problem:

I use R Studio in a corporate machine in which I’m not the admin. There, the packages were installed in a temporary folder that is cleaned from time to time. I didn’t pay attention to that until the packages were deleted and I was blocked on re-installing them. I had to repair the application from time to time. And today,  I got a new warning stating that the library was not writable.

> install.packages("lubridate")
Installing package into ‘C:/Users/Public/R/libraries_i386’
(as ‘lib’ is unspecified)
Warning in install.packages :
  'lib = "C:/Users/Public/R/libraries_i386"' is not writable

I thought the best would be just to install the packages in a local folder that I have control over. So, I’ve added a new library to my library path.

> .libPaths( c( .libPaths(), "H:/My Documents/data analysis/R") )  
> .libPaths() 
[1] "C:/Users/Public/R/libraries_i386" 
"Q:/RSTUD301.001/R-3.2.2/library" "H:/My Documents/data analysis/R"

Alternatively, if you just add a new path:

.libPaths("H:/My Documents/data analysis/R")

The .libPaths function adds the new one as the first path to be used:

[1] "H:/My Documents/data analysis/R" "Q:/RSTUD301.001/R-3.3.1/library"

Now, every time I install a package, I select my local folder and the packages will not be deleted.

Source in StackOverflow.

I don’t like boxes, do you?!

The CIO stands up suddenly and looks to the horizon through the walls of glass, leaving behind his business analyst.
– I don’t like boxes! Do you?!
The consultants feel threatened by that statement after so much work gathering information and drawing many business process diagrams.
– What? Boxes? Ok, looking at a business process that shows the flow of activities among participants, you only see boxes and arrows. That’s fine!
The CIO insists on his statement, but this time challenging the analyst.
– I mean, isn’t it too simplistic? Are they useful at all to us?
And the analyst replies with an irony sauce.
– I see, you prefer to have your procedures textually. No one needs to learn what that diamond shape in the middle of all those boxes mean. I just have to write “If this happens, then do that. Otherwise, do something else”. Everyone will understand and they will follow the procedure properly. Good! But how did you get to the procedure? How do you know if it is efficient? I’m not saying that processes solve it all, there is monitoring of activities and everything else that comes with it. But what if using “boxes” could help you realise gaps, bottlenecks, links,…? You’ve just added a single line of text in your procedure: “participant x validates doc y”. It’s saved, published and now everyone can follow the updated procedure. But, wait, by adding this single activity in the process, you can visually see the need for additional communication with external participants. This extra communication represents a bottleneck in a process already filled with time constraints….For one, that’s something you did not see by adding a simple line in a long document. Think about it! Let’s at least use the “boxes” for making sound decisions on changes. You could throw them away later, if you’d like. But in your place, I would actually recycle them 😉

The analyst just saved months of hard work on clarifying business to everyone.