Tuesday, October 04, 2011

Don't Get Bullied


In dealing with multiple groups that have sometimes conflicting agendas, and almost always conflicting value systems, confusion can reign. After one such recent encounter, I wrote an opinion piece to help a beleaguered business analyst fend off some bullying by some techie types. Here's a sanitized version of that email:

Generally speaking, I notice people tend to either speak too high level or too detailed. It usually a function of the point they are trying to make that coincides with their particular opinion. ;-)

Getting an accurate answer without excruciating detail can often be achieved through a discussion about groups of attribute behaviors (which can be called a class). Regardless of many attributes or few, attributes can usually be grouped into a manageable number of groups by their behavior. These groups (or classes of behavior) are much easier to manage because they are specific, distinct, and typically much fewer in number. Any attribute under discussion can then be placed in a group, which means we don't have to know about every specific attribute up front, or even be correct about which attribute is in which group. By talking about these groups (or classes of behavior) we can all stop confusing each other with overly specific or overly general examples.

So what defines these groups (or classes of behavior)? The location and process by which an attribute is created or maintained is usually a good starting point. For example, some attributes (say product SKU) will come from ERP and cannot be edited outside of the ERP regardless of how it is consumed downstream. All attributes that come from and are maintained only within ERP share the same behavior and are therefore part of the same class (they are in the same group). For simplicity, we can consider these primary or core attributes.

If we further consider that some attributes will need to be created and maintained only by a downstream consuming system, we see that these attributes share a class. We can consider these isolated attributes. Perhaps some group of attributes are created in the ERP but can be edited or over-ridden in a downstream consuming system. These attributes also share a class. We can consider these to be extended attributes.

While this small number of classes (primary, isolated, extension) already cover our current needs, should we have additional behavior combinations (say sourced in ERP, and only over-ridden but not edited) we can certainly introduce additional classes. In practice, usually only a very small number of behaviors is required.

By disconnecting the discussion from specific attributes to the groups of attributes, it is possible to manage the risk that whichever way the schema evolves, the technology to support the different necessary behaviors will be supported. For example, knowing that we must support both isolated attributes and extended attributes ensures the schema will be able to express the difference and our replication and management processes must respect that behavior. Our solution will suffice, regardless of which (or how many) attributes ultimately end up classified in this way. More importantly, we can stop getting off-topic with discussion about specific attributes.

What prompted the email was watching a vicious cycle repeat wherein the business asked for a capability that was complex, the technologists offered a simpler solution for specific cases, the business came up with yet another different complex example which prompted the technologist to revise the solution, etc. Both parties grew frustrated. The business didn't think they were being heard and worried about what they thought of as unknown gaps in the future solution. The technologist were struggling to create a high-level solution approach while constantly responding to low-level assumptions of how their solution should be implemented. Getting both sides to stop pushing an agenda is difficult but can be easier if you introduce terminology that is new to both parties. When they both have to take time to translate their opinions into a common vernacular it becomes clear which points are significant and who might just be causing trouble.

The primary-isolated-extended pattern above is a very real pattern that I use in my every-day to help make sense of extremely complex enterprise-wide data flows. It really works. From the most advanced techie types, to the simplest business types, it is a tool that they can all understand. So now when they are bludgeoning each other in meetings, at least they are all using the same patterns to do it.