The Microsoft Dynamics AX glossary: What’s in? What’s out?

  • Article

In our work of aligning, and in some cases, realigning concepts and their terms across the Microsoft Dynamics AX product, we considered which concepts we should publish in our glossary. Throughout our development cycle, we evaluated feedback we received from partners, customers, translators, and internal stakeholders, and we specifically focused on the feedback we received about what type of information people would seek in a glossary. We then used this information as a basis to establish guidelines for what types of term entries we would include and exclude in the glossary.

In an earlier blog entry (Defining concepts in Microsoft Dynamics AX 2012: Accuracy, precision, and domain tailoring), I offer insight into our practice for defining concepts, and I offer a few simple measures for defining the concept from some aspect of the real-world and with respect to a domain, such as accounting or manufacturing.

In this blog entry I offer insight into our practice for establishing patterns for the types of term entries we offer in the glossary and the types of term entries we do not. And I discuss our objectives and thinking behind our decisions.

Terminology objective

The objective of our terminology work is straightforward—we want to ensure that the concepts and terms that we introduce in Microsoft Dynamics AX are accurate and precise with respect to their domains and that they remain resilient release over release.

Publication objective

We publish term entries in our glossary that represent real-world organization resource management domain concepts or software application concepts that are realized in the product. While our glossary contains over 600 term entries, it does not contain term entries for 100% of the concepts that are realized in the product.

Because we did not have the resources to document all of the concepts that are realized in the product for this release, we reached out to stakeholders to help inform what types of term entries that they would find most useful. We initially reviewed feedback we received from partners, customers, translators, and internal stakeholders, and then we collected feedback on our terminology objectives and term entries by conducting audience-based written surveys and walkthroughs. (See my earlier blog entry, When is good enough good enough?)

Observations and patterns

The feedback that we received from stakeholders informed some immediate observations that we applied, and then as we continued to refine our practice, we were able to further refine the scope of our glossary deliverable. Feedback that we received from partners, customers, translators, and internal stakeholders was classified in two categories – entry types to include and entry types to exclude.

Entry types to include

  • Terms and descriptions that map to their standard domain usage.
  • Entries that describe “what” the concept is, not “how” it is realized in the product.
  • Few or no synonyms. If synonyms are necessary, we should distinguish how they differ.
  • Terms and descriptions that map to users’ industries and areas of work; for example, an accountant in the public sector.
  • Terms and descriptions for Microsoft-specific concepts and for terms and definitions that differ from the standard industry usage.
  • Names and descriptions of roles that are also roles in a domain; for example, manager, employee.
  • Security terms and their descriptions that are also domain terms; for example, duty, privilege, permission.

Entry types to exclude

  • Names and descriptions of user interface controls or elements; for example, we should exclude entries for directory view, list page, FastTab, action pane, and so on.
  • Names and descriptions of forms and reports.
  • Names and descriptions of user interface labels, particularly ones that are poorly phrased. These should be rephrased instead.
  • Names and descriptions of parameters or behaviors.
  • Names and descriptions of deprecated concepts.

These categorizations informed the patterns that we documented in our terminology guidelines. And these categorizations informed the types of term entries we would publish and for the types of term entries that we would not publish.

For your consideration

Now that the Microsoft Dynamics AX glossary is published, I pose this question for your consideration: Did we make the right decision with respect to the types of term entries we included in our glossary?