Have you ever experienced having architecture design desicions being made by well-meaning, knowledgable business users who nevertheless have no experience with technical architecture? That can be quite frustrating. Yes, I think it is valuable to get other important viewpoints, especially from the host of seasoned business users. It is a fine balance between taking good advice and the feeling of being overruled by someone less qualified.
To better understand how data flow and how important it is we should definitively seeks advice at the business peers. Although data management is getting a wider audience as it is getting more aknowledged, we do not face extinction as data structure providers. We simply must learn to broaden our terminology and understand the models that the business users are viewing. We can no longer simply rely on understanding the business by just drawing the information model. This model is the very thing that key players from different entities in the business is challenging and in that process are putting forward the models they are familiar with and that they strongly feel is the most appropriate model to solve the data issues at hand. For business users common models are process diagrams and organisation structures.
It can be useful to take a step back and ask questions of what the data should accomplish. Be persistent in finding out what is truly needed of the data without laying down the structures. It is difficult to challenge another person's model of how the business or world works. Isn't that the why we ourselves feel invaded: "How DARE they to even suggest how - I - should construct this data flow or entity?!". Business users and data architects do have different background and more often that not, don’t think alike. How can we bridge this gap? Encountering business people trying to explain why something is not working in the data architecture can be quite frustrating because of their lack of knowing the fundamentals. Their understanding are formed by their models, next to a lack of knowledge of the mechanisms of how a data architecture. Keep in mind, though, that we also lack the knowledge of the workings of their business to the detail that they know? Do we not also create models of how we think the processes in the business are working? Do you not think they might be just as off the target? It is not only the understanding of the business and its details, but also the models that are being used to describe these, that needs to be conveyed. By understanding how business users think we can perhaps both appreciate the details of the business better and be able to explain our terminology using their models. That’s communication.
It is quite interesting to witness the case, which I have many times, when a business users or a data architect is trying to explain their models in a very simple and a too basic way. We should both understand that although we do not know the details that does not imply we need to be explained the very basics of a very understandable process. That widens the gap as nobody wants to appear ignorant. By appreciating other people’s world views and models we can easier get to the point of the matter and understanding each other.
By trying to understand the models of the business users, we will increase our own knowledge of how the business work. Hopefully, that will in turn make them listen to what you have suggested. A dialogue is just that: an exchange of argument and viewpoints to arrive at a bigger understanding. That is when we grow and produce greater results.