Do we really need ArchiMate? UML vs BPMN vs ArchiMate

UML and BPMN are two well known modelling languages that when used in combination in software solution delivery project, they can cover a very wide spectrum ranging from cross-organizational business processes to classes that can be used to generate executable code.
The question I am facing now is the necessity of utilizing the ArchiMate modelling language.
While I realize that some elements in ArchiMate do not have direct equivalents in BPMN or UML, but do they actually create enough value to justify introduction of another modelling language?
Some googling shows that the language is used with a vast level of divergence by system architects which questions the clarity and usefulness of the language. After all, for a modelling language to be more effective than natural language, it is expected to provide a consistent and normative way of describing the idea or the physical reality.
Almost every ArchiMate diagram that I've seen, although not being wrong, has been a surprise and difficult to verify and understand.
The current guidelines in ArchiMate about defining the system in three layers are too vague to actually produce good quality design artifacts by system architects.

I have provided an example in a later post

The MES Solutions designed for the food, beverage and the pharmaceutical industries need to cover few extra requirements to be used along with eBRS systems. These requirements are mainly driven by regulatory requirements about how process data should be stored and protected to be able to be used as part of batch records.

The US FDA’s CFR 21 Part 11 has become the baseline requirement for MES system used in these industry even outside the US.

http://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=11

An important section of this regulation is the requirement for linking records and signatures :

Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify an electronic record by ordinary means  

MES Systems generally use Encryption Algorithms for Digital Signatures to satisfy this requirement. This means anyone who does not have the ‘Private’ key, will not be able to forge the signature and it is assumed that having access to the Primary Key is not considered ‘ordinary’.

While not explicitly said, using Database level security is not usually considered enough protection against ordinary tempering of the signature and that is mostly because of the preventable but prevalent loose security in DB level in industries.

Engineers frequently ask for and successfully acquire higher access rights that they needed for commissioning, maintenance and debugging systems. By having the access rights to add/update/delete records,  a user can easily clone signature data if they are not digitally signed. 

Recently I was in an MES bootcamp and in interesting debate started among representatives from two companies working in two different domains.
The debate started around relative complexity of Production tracking solutions and Inventory tracking solutions.
To understand the problem it is important to have some basic understanding of the meaning of these two terms in the context that people were using it:
Production tracking is recording the information about activities performed in a plant to make a product or deliver a service. for example the number of tonnes passed through a washing machine can be a production figure.
On the other hand, Inventory tracking is trying to provide information about quantity and quality of materials in a plant or more precisely in storage locations. going back to the washing machine example, the amount of material before and after the washing machine work-cell would be an inventory information.

by my example it sounds like the inventory tracking is a more advanced and challenging task, especially because we know that we can 'infer' the production tonnes if we know the inventories over time.

This is like trying to compare Derivatives and Integrals in calculus. It is probably a useless argument anyway. We know in some industries like food or high-tech, the production process is very complex while little or of little value inventory is maintained.
In contrast, going to bulk material processes, usually the production processes are very simple, but the value of the inventory is of more interest.

This may sound a simple and easy resolution, but in reality things are never that easy!
In projects that I have worked in, although theoretically these two sets of data could be inferred from each other, but as a matter of fact they tend to live independently and most of the time in an inconsistent manner.
It is a good practice to think why this happens and how we can marry these two data sets. Is it even possible and wise?

Material Model for Grain

Recently I had a very heated argument with a customer representative about how a material grade should be modelled in ISA 95 model. To make question clear let's have a look at ISA 95 standard for material class and definition. It's basically a class diagram in UML for classes without method or property.

As you should've expected. there is nothing domain specific there and that is open to interpretation. And this is how it should be. But ISA 95 standard gives an example that models Aluminium as a Material Class and A Grade Aluminium as Material Definition. This example is provided out of any solution context.

We were discussing how different grain grades such as APH2-Wheat or FEED-Wheat should be modelled. To my colleague it was obvious that they should be modelled as different material definitions to adhere to ISA 95 standard.  These are few arguments supporting this model
1. We can model commodities like 'Wheat' as material classes,
2. The example from ISA 95 shows this is probably how standard is meant to be used
3. The ISA 95 does not have any other pre-defined structure close to grade concept

So why I even doubted that? Maybe because I'm also a software engineer and I might be able to read some implicit info out a UML diagram. While it's not very complicated, but understanding OO concepts is crucial to understand the above diagram and any ISA 95 model.
In my opinion (Which I will defend next) , 'Grain' is a material class and 'Wheat' is a material definition. What is the 'Grade'? It's simply a quality target or quality criteria. The 'Grade' concept should not and can not be forged into above object model. And it's not even required for ISA 95 compliance. Extensibility is the beauty of Object Oriented design.

What are my reasons for thinking like that?

1. In contrast to something like aluminium, grain can be mixed with minimum effort. let's say A-Grade and C-Grade wheat get mixed and form B-Grade which is still Wheat. modelling grades as materials according to above UML chart means objects of type A-Grade and C-Grade are replaced with an object of type B-Grade. Knowing that no business entity has been deleted or created and instead they are just sitting next to each other makes such a model un-necessarily irrelevant to physical reality. E.g. if you put enough of A-Grade then type of result object can change or even become undetermined. This does not match Object Oriented principals where type of objects are defined and can not change.
If you model grade as quality criteria, then two objects of type 'Wheat' one fulfilling quality criteria of 'A-Grade' and the other one fulfilling quality criteria of 'C-Grade' form a set that now fulfils quality criteria of 'B-Grade'. I see this model closer to reality. I know if I put too much of A-Grade then resulting set will tend to satisfy 'A-Grade' and my model supports that.

2 Overlapping Grades
We know wheat can be categorized to two different grades. For example APH2 wheat can also be assumed to be Feed Wheat. Same material falls into different grades depending on specification and standard used. different countries on different years have different specifications.
looing closely at above chart shows every lot can only have one material associated to it. This means either we will have to ignore this real-life fact or our model will not comply with ISA 95 standard!
But if we have grades as separate objects, every lot can get associated with multiple grades and we won't need to break ISA 95 model

I probably could list few more reasons, but after all it's a reality of an engineer's life that sometimes designs are imposed to him. I wish we had more education on ISA 95 before actually starting to design the solution