One of the most common artifacts that comes under the purview of the enterprise architecture department is the application catalog – the formal list of what software the organization owns and manages. Collecting the information can be a challenge in itself, but establishing and maintaining such a catalog turns out to face another issue.
At its core, a catalog of entities establishes a common business vocabulary – a common set of terms that enables communication. In this way, when a deployment diagram refers to the procurement system and a spreadsheet of annual support costs refers to the procurement system, and an SOA landscape map refers to the procurement system, we ensure that people are talking about the same thing.
Except when they aren’t. In one organization that I worked at, it turned out different groups called the same software package six variations of the same name. Granted, they were internally consistent, but the difference in terminology made shared communication a whole order of magnitude more difficult.
Now, ideally, you can address this by naming conventions – although the art of naming items is a very loose field – but by its nature modeling, and architecture is dealing with an existing organization – the old ‘maintaining a 747 in flight’ situation. Sure, a program with strong executive sponsorship can simply impose a new catalog and naming convention by fiat from above – but this spends political capital that could be better used elsewhere. People don’t like learning new names for things and they especially don’t like requirements imposed from outside.
A better approach is to provide a way to enable people to find applications using the terms that they are familiar with – even when these terms aren’t the official name of the application. In other words, an important point when establishing your application catalog is to provide a mechanism to record aliases for applications – and allow people to locate these applications using these aliases. The ‘official’ name should be what you use in artifacts, but wherever possible, artifacts that reference the application should also list the aliases for that application in some way – in this way those using the aliases can gradually become comfortable with the official nomenclature.
Now let’s talk about how the aliases should be set up. One way to configure it would be to provide, say, 5 attributes to record them – ‘alias 1’, ‘alias 2’ and so on. But this approach has some problems with it. First of all, it’s inflexible – it imposes an arbitrary constraint on how many aliases you can record for an application. Second, your tool might not allow searching across multiple attributes for a name – or it might require custom reporting to do so.
So the preferred way to configure this would be to record aliases as a single text attribute and then list the aliases as a comma-separated list within that attribute. Those searching for an application can then search for the alias value by searching the text of the attribute value – something that I’ve seen most tool options provide.
It might seem that supporting aliases in this fashion is either inelegant or too accommodating - but it’s actually an elegant way to minimize the culture shock and maximize the value of the application catalog to a diverse group of stakeholders.
Do you think this system would work in your organizations? Or perhaps you already have a system that works for you - comment below, I'd love to hear from you.