Organizations are populated with solutions entitled DW, EDW, BIC, ODS, EIW, IW, CIF, or BW. Why must every organization have a data warehousing or analytics solution identified by monikers from a very limited pool of choices? Why must every deployment of a database that is expected to function as an operational data store be called ODS? For internal solutions it seems that plain and dreary naming approaches are de rigueur. Two and three letter acronyms have long been a part of corporate-speak; but when it comes to IT systems, these TLAs have become exceedingly narrow and soul-less. Some naming schemes take a generic business function or term and prefix the letter "E" or "I" to make it a solution name. While it is true these acronyms and single-lettered prefixes are to-the-point, will we really forget what these systems do unless they are named in such an explicit fashion? And sadly, as lifecycles progress and these systems are replaced, most often a simple number or perhaps a year is added to the name. When re-branding seems necessary, then bland names are shuffled, migrating from iTimesheet to eTimesheet or EDW to EIW.
There was a time when organizations chose Classical identities for names. There once was a landscape of handles like Mentor, and Midas, and Socrates. Are the changes away from such names a result of fear, attempting to avoid unintended offenses that might lead to legal battles in our overly litigious society? Certainly it is not suggested that anyone attempt to offend people. What would be offensive about a set of conformed dimensions and facts labeled "Hollywood" for the land of star (schema)s. Likewise, what would offend by tagging a reporting and analytics user interface as the Stop'n'Shop? Maybe litigation isn't the only reason; it could be that those in charge of naming are afraid of choosing a name others might make fun of, so they attempt to dodge suffering embarrassment by association? If so, get over the embarrassment, because even these bland names are at times used in a derogatory fashion, e.g., EDW can expand easily into Everything Don't Work. If extension beyond Greeks and Romans were allowed, an expansive world of names exists. It might be very entertaining to work on an application named for the Hittite king Suppiluliuma.
Plug-and-play as a concept and a design approach is extremely useful. However plug-and-play is not expected to apply to virtually every aspect of every thing. Naming should be an area open for creative expression and a little freedom. What if everyone named their son George, or to keep with the style employed in IT applications, everyone named their son Sonny? When it comes to solution names, plugging in a very limited set of possible names across every organization creates a featureless and homogenized backdrop. If current application naming schemes were employed to designate a variation of a rose, we'd likely be saddled with PTP for Pink-petaled Thorny Plant instead of being graced with the American Beauty. Names can be looked at as a trivial feature that is unimportant. Whether a system is called XYZ or Xanadu, it functions the same. The name does not make the solution inherently better or worse. But even so, names are heard and said over and over and play across our work lives in a ceaseless torrent. And whether one chooses to believe or not, fun names can in their own small way help increase our joy at work. We all can do much better than bland; let's spice things up and upset that limited name apple cart just for the fun of it. Call the next data warehouse you build Shangri-La, or Answerville, or the Big Giant Head, or anything; just please don't call the solution EDW.