metaphors – In Search Of

One of the most difficult aspects of gathering and documenting software requirements is to get all of your stakeholders and project team participants to agree on terminology, especially words commonly used in the business domain. Common usage is never very precise, and often business problems arise from ambiguities in common usage. In developing a conceptual model of the business domain, it is necessary to define key metaphors very precisely, to remove these ambiguities, and allow software to implement logic that is correct.

There are two key types of metaphor ambiguities: semantic diversity and multiple identity.

Semantic Diversity – when a key metaphor has different properties in different contexts. This presents itself as a word that means different things in different aspects of the domain.

Multiple identity – when multiple metaphors actually share the same meaning or identity. This presents as different words that are used in different aspects of the domain to mean the exact same thing.

There is one other pattern that we see, which is called contextual revelation. Contextual revelation is when a metaphor presents different attributes in different aspects of the domain. In this case, it is the same metaphor, but different information is relevant to different parts of the business process. This often presents itself as if we have different metaphors, that have a mandatory one to one relationship with each other.

In some business domains, certain aspects appear optional, in that not all aspects are in play for every situation. In this case, the contextual revelation pattern may present as the metaphor having behavioral variants. In this case, one way of disambiguation is to derive the Behavior Taxonomy. Simply put, this can be accomplished by determining the simple list of behavioral variants that are needed to support the business process, and mapping the driver attribute(s) used in determining which behavior is selected.

This week I was asked to review job descriptions for analyst roles within our IT function. The roles were “Analyst, Business Systems”, and “Senior Analyst, Business Systems”.

The person who asked me was looking for my opinion because I am strongly opinionated, blunt, and have experiencing hiring and leading business analysts and requirements engineers. She wanted to understand the difference between an analyst and a senior analyst.

Other than the expression of leadership within a project or team context that I would expect of any senior contributor, my answer had to do with metaphors.

Metaphors are the solid business abstractions that software is designed around. Metaphors are the unambiguously defined concepts that ground the business process. Metaphors are the litmus test to see if requirements are cohesive and complete. If your metaphors suck, so do your requirements.

Back in the ’90s when I was learning object oriented application design (OOAD) we were taught that each application or major feature had a “central object” that was the focus of it’s existence. Microsoft word has a “document”. Every e-mail client has a post or a message. This central object is the metaphor around which the application is designed, we just didn’t call them metaphors back then.

When designing an application all of your actions are performed on metaphors, all of your business rules contemplate metaphors, and your data model expresses your knowledge of your metaphors. Your metaphors are the essence of your understanding and modeling of the REAL BUSINESS stuff that your users and customers have to deal with in the REAL WORLD as part of their job. The more your metaphors align with reality, and the more you can eliminate ambiguity among and between metaphors in your requirements, the easier it will be for software designers, architects, and developers to model and fashion a system around them.

That’s my story and I am sticking to it. The senior analyst gets this, and carefully and thoughtfully identifies, defines, and clarifies essential metaphors within business requirements, and knows the the requirements aren’t complete until all of the metaphors defined hold together with the business rules and actions required.

Metaphors work most effectively when you can get your user community to communicate (to you, and to each other) in terms of metaphors that you helped define. When you have defined useful metaphors that clarify the business process, your users will adopt your terminology because it helps them understand what is important. Then in that context your software (being true to those metaphors) will be intuitive.

An analyst can capture and document the business process. The senior analyst (one with mastery) can change the conversation casting metaphors that help the business community define its value proposition and supporting processes more effectively.

Posts Tagged with metaphors

Semantic Clarity

Metaphors in Requirements