29 Sep




“Meow” means “woof” in cat.” 
~ George Carlin

This article is a precious part of the hybris Project Patterns series.

How often have you found yourself speaking the same language with others, using same terms, yet, still talking about different concepts?

An initial phase of a project can be a mystifying experience when trying to reach common ground of understanding while using specific business terminology.

Apparently, giving common terms a different semantic, may lead to more questions, rather then to answers.

Comprehension is vital in all phases of the project lifecycle.


Entering a new project in a little known business domain, you might find it challenging to grasp the business lingua, at first, and blend into the discussions.

Likewise, the Business Client also find themselves in a less comfortable zone of this new software – called hybris – and struggle to comprehend new terms, concepts and ways of working.


Define a project Glossary

Related patterns

Workshop, hybris Functional Consultant, PIM Awareness, Requirements Gathering, Domain Methodology, Data Models, System Actor Inventory, Page Inventory


Consider the following terms, commonly used in e-commerce projects:

  • What is "content "?   Product information, CMS editorial texts or User data? Or, all of those?
  • What is "product "?   a Sellable item? a Service? a Concept? a Virtual entity? an SKU?
  • What is "PIM "?   Product Information Management? Partner Inventory Module? Or, else?
  • What is "Customer "'?   a User? a Company? Internal business unit?
  • What is “campaign”?   A promotion? A bunch of discounts? Or a well-planned marketing tactic to target Consumers?
  • What is “internationalization"?  Adaptation to various languages and locales? Or, perhaps, a complete strategy of launching a multilingual, multicultural, omni-channel corporate solution?

I remember a project where, at the start, we were discussing the notion of a “Product Catalog”.

While we – the Implementing party – were referring to a ‘concept’ in hybris, which defines logical organization of products, the Client was signifying an overall business program – called “Product Catalog” – which involved one of the Global Corporate organizations and its overarching strategy!


To avoid comments like “… That is all Greek to me …”, make sure that you make certain efforts in building up a common understanding of terms and practices, used in the project.

It is imperative for a Consultant to understand the business jargon. Likewise, a Consultant should be able to guide the Client into the terminology used within the hybris environment, because the software comes with its own definition of concepts.

Finding a balance is not easy, since it requires taking the Client out of their comfort zone and introducing new terms and workflows, yet still keeping the day-to-day business language.

Using the Client’s vocabulary allows them to understand the new platform and adopt the solution with ease. Yet, preserving the hybris terminology gives people a quick head start into already established best practices, a common market vocabulary and a language used by the hybris’ user interfaces.

Building that shared understanding starts with a common dictionary.

The solution to this challenge is simple: create a Project Glossary, right at the beginning of the project.

This allows both parties – Business and Consulting – to map their mental worlds to a shared vocabulary of the new solution. 

In the course of the project, we plan dedicated Glossary Workshops, which enable all teams to align their working language.

Activities like Persona- and Page discovery, Requirements management and Legacy system analysis contribute largely to the Glossary, by defining terms used in all phases of the project.

Hybris also offers a Glossary of Terms in their online documentation. We reuse hybris terms utilized in the project, and also enrich the list with terms stemming from the business specifics.


Besides, other benefits of having a Project Glossary are also:

  • To define a simple clear Language for the Requirements gathering process
  • To name core concepts of the System Architecture
  • To title names of Pages, Actors and Systems
  • To designate code artifacts
  • To label development iterations and releases, such as “Sprint: “Brand Content” ” or “Release X: “Personalization & Mobility” ”
  • To establish unified language for the various Users Guides and Trainings
  • To enable new-coming project members comprehend the core concepts of the project

Today, for every project we run, we create a Project Glossary as a recognizable delivery artifact.

The Glossary serves as a firm foundation for our communication, requirements language, workshop grammar, user guides and training. We base our daily lingua on it.

Remember: the Glossary defines the letters of your Project Alphabet. Learn the letters and you would be able to comprehend. Then, teach the letters to others and you will be capable of interacting and delivering with ease.


  Continue reading:


 How did you like this post? Do let us know ...  



Total votes: 0