A name is important. The right name is important. In this post, I reflect on the choice of names in the Microsoft BI stack. From time to time, a bad name arises. Not a big issue, as together we tend to replace those spontaneously.
Picture this: you are wandering through an office, and you see a developer lost in her thoughts. She is just looking through the monitor, as if there were something behind that black screen. Her fingers are slowly and gently tapping the keyboard. She is not really typing; nothing appears on the screen. She does not want to turn her thoughts into reality. Not now. Not yet. This moment where time stands still will last for a few more seconds. What you are witnessing is one of the most sacred moments in the day-to-day life of a developer: she is about to choose a name for a new variable.
For a variable name, this scene can last for a few seconds, maybe minutes. If that were the name of a new project… Well, then spending a whole day deciding on the name might just be the right amount of time. A project name requires the proper time investment – hours at least. Projects, technologies… their names are important.
Why is a name so important? Developers create new entities and concepts every day. As such, they need to name them. A great name evokes a concept clearly and concisely. A great name is a pleasure to use, either spoken or in writing. C’mon, either you get it or I cannot explain it to you: you feel that a name has magic inside!
As the creators of new technologies, developers know that they are responsible for this important choice. The burden of this responsibility is scary, to say the least. Developers understand this very well so they often choose beautiful, powerful, evocative names.
Once chosen, a name is unlikely to be changed.
Well, this latter sentence is not entirely true. A name can be changed. There are several examples of A.K.A., usually when the initial name for whatever reason was not powerful enough. What happens is that the community ends up changing the name just by using a different one. The old and poorly-chosen name is doomed to be forgotten and replaced by the better and widely-accepted name that the community has come up with. You my reader hold such power! You can start the process of changing the name of anything you want, just by starting to use a different name for it. If enough people follow your lead and use your new name of choice, that entity will be remembered with its new name. Now that you are aware, use this power wisely!
Why all these considerations? Because I witnessed the birth of unfortunate names in the past and I am concerned that history may be repeating itself. Let me give you a first example: VertiPaq. You probably know what VertiPaq is: the in-memory database that runs inside Power BI. VertiPaq is a powerful name. I totally love it. Maybe some of my readers do not know the origins of the VertiPaq name. Let me reminisce briefly.
Originally, the developers named the new engine VertiPaq. I am pretty sure that they worked hard to choose an evocative name. They made a responsible decision, gave a name to the engine, and started using it. I would bet they had a good feeling every time they used this new name.
Later, when Power Pivot for Excel went to market, it was time to provide an official name for the VertiPaq technology. VertiPaq – despite being cool – did not seem to convey a message. The people in charge of choosing the official name wanted to describe the technology more precisely. They chose “xVelocity in-memory analytics engine” as the official name for VertiPaq. To this day I remember the time it took me to adjust my slides and my books in order to replace “VertiPaq” with “xVelocity in-memory analytics engine”.
At the time, few people were speaking about these technologies. Marco and I were part of this first wave. After a few months of complex discussions we made a deliberate decision. We would revert to the original – and much more powerful – engine name: we started calling it VertiPaq again in our books, articles, sessions… everywhere. This meant another round of search and replace! It took some time, but everybody responded to “VertiPaq” much better than to “xVelocity in-memory analytics engine”. We succeeded: VertiPaq remains, xVelocity disappeared.
Another name was born around that time: BISM, BI Semantic Model. I was present at the meeting where the name was chosen. At the time it felt important to pick a name that would include both Tabular and Multidimensional. BISM was intended to represent an AS model, either Tabular or Multidimensional. You see what just happened? I felt the need to explain the name, because I took for granted that none of my readers even know what BISM means. The name was useless and not cool at all, and as such it died a silent death.
Why did I just put you through this very long digression? First, to tell you a story which might be interesting in and of itself. Second, because history is repeating itself: new BI artifacts are hitting the market. The official names are so much weaker than the original names, that we at SQLBI are thinking about reverting back to the unofficial names.
Two of these new names in particular are the reason for this post:
- DirectQuery for Power BI datasets and Azure Analysis Services is the official name for the new composite models, that is the capability to extend an AS model with local tables. We strongly prefer “Composite models”. Yes, the name “Composite models” is already being used to define a model that stores some data in VertiPaq and has a DirectQuery connection to a relational database. Using Composite models for the new feature might lead to some confusion. The thing is: does it really matter? I bet we will end up talking about new and old composite models, and the concept will mostly be clear depending on the context. I talk about this feature a lot with multiple people, and everybody understands and likes “Composite models”.
- DirectQuery source group. This is the official name for data sources in DirectQuery models that connect to multiple relational sources. When talking about the feature with the development team, we used to call them Data Islands, in contrast with the VertiPaq store which we called the VertiPaq continent. Data Island and VertiPaq Continent are evocative, powerful, clear. I mean… I feel good using those names! DirectQuery source group, at least to me does not bring anything to mind. It is nothing but a boring technical term.
Hence, this blog post is my official position against those official names. I am going to continue using the names chosen by the developers, or by the community. Don’t get me wrong: if the community accepts the official names or if they choose a different one, I will silently and happily roll with it. As of now the choice is still to be made, and my position is very clear: I would love to work on a new composite model with several data islands and a VertiPaq continent!