There was an SAP project that I worked on once that had a small army of process analysts from a big 4 consultancy all working away creating process maps for implementation in SAP Solution Manager. It was only when the consultancy drones collected all the process maps together into a repository that they noticed a small problem with doing any analysis and searching on the information that they’d collected.
This company used Ariba eTrax as their procurement system, and the procurement system appeared in quite a large number of the process maps. Specifically, it appeared as ‘Ariba eTrax’. At least, it did on some diagrams. On others, it was ‘eTrax procurement system’. In other places, it was ‘{organization} procurement’.
This was a problem for two reasons. First of all, someone coming in from the outside would not have necessarily known that Ariba eTrax and eTrax procurement system is the same thing.
More importantly, in terms of using the tool that they had for automated analysis, having the same item appear multiple times as different items makes reporting highly problematic, if not impossible.
There are a few ways around this. Most repository based tools allow you to ‘reuse’ items from a central store onto the views that you create. So you can require the team to look in the repository first and reuse items. This works to a point. Only… how do they know what to search for? In other words, what will the item that they are looking for be called? A second problem.
So – the main way to address this issue has to be to have a standardized way of naming items. Unfortunately, this seems to be a gaping hole in the existing EA literature. Sure, there seems to be de facto standards in a few areas – processes are named according to the format {Verb}{Noun}, IT infrastructure devices are called by whatever hostname they have (not that there is any standard way of naming hosts).
But what do we call an application interface? What do we call a business function? Even the {Verb}{Noun} has issues – how many of us have seen process tasks called ‘submit form’? Not ideal for distinguishing which form it is that you’re submitting. It’s possible that we don’t care – but what if the form is a confidential form, and we want to model security access? Then we would very much care which form is which.
Normally in my blog posts, I try to offer solutions, on the premise that even if I’m wrong it’s a starting point for exploration. But here it seems like this is an area where we’re starting from zero. Right now I’m having to interpolate some naming standards for a customer based on the hundreds of diagrams that I’ve seen.
Perhaps there are some experts out there in information theory who can offer a different perspective; all I can do at this point is offer some observations on what a good naming practice should offer.
First of all, minimize ambiguity in your nouns. “Submit Form” is no good. “Submit Form P58” is much better.
Next, only use generic naming if an item really is ‘one size fits all’. An ArchiMate infrastructure service called “Database Backup” is only appropriately named if it really does allow you to back up any database (or if the diagram is so high level as to make the use of a generic service appropriate). In such a case, such a service could be a parent of various services “SQL Server Database Backup”, “Oracle Database Backup” and so on. Or, if each version of SQL Server performed backups differently, “SQL Server Database Backup” would have to be a parent of “SQL Server 2008 Database Backup”, “SQL Server 2008 R2 Database Backup”, “SQL Server 2012 Database Backup”.
Adopting good naming conventions is an important part of moving to a shared model; and yet there’s surprisingly little work that’s been done on this.
Any students out there looking for a Master’s or PhD thesis topic?