What do you do if your stakeholders in Data Architecture are not understanding your communication?

It’s about managing change. If you access change only as technological progress will often stall because stakeholders that needs to approve budget will not understand why they need to invest. Especially if budget owner priorities are driven by business. You need to create a clear business case that will elaborate not only technical change but the business impact each scenario (do something / do nothing) will have. It’s about connecting with needs and understanding of your audience. Because let’s face it budges in IT are always limited and you need to justify why investment is necessary. Owners of budget often has many conflicting priorities so to get change through and budget requires to make sure they understand benefits and risks.

Tell them what you are going to tell them, tell them, tell them what you just told them - all in concise messages with simple architecture blueprints.

As a data architect, you navigate between technical and non-technical stakeholder. While process owners focus on functional outcomes and data security, development teams require detailed technical specifications. It's your responsibility to bridge these two worlds and ensure mutual understanding. This can be achieved through effective documentation and communication. It's important to tailor your approach based on each audience's domain understanding. Simplify domain information for the development team while providing concise technical details to process owners. Every interaction should be clear, concise, and goal-oriented, ensuring everyone comprehends defined targets and collaborates effectively to achieve them.

The more complex the solution is, the simpler the summary blueprint needs to be. Focus on the top 1-3 points you are trying to make, not all 1001.

Simple diagrams are essential - 7-plus/minus concepts on the initial visual aids. After 40 years of computer aided design, many consumers still get quickly overwhelmed by the real complexity of the solution. So keep it simple and focus on the topic 1-3 points you are trying to make.

Seeking feedback is crucial in data architecture to ensure effective communication and alignment with stakeholders. It's essential to engage in a two-way dialogue, verifying comprehension and addressing any concerns. For instance, soliciting opinions on data architecture solutions and how they meet stakeholder goals fosters collaboration and ensures that potential challenges are addressed proactively. If a business doesn't trust their data, then it's a waste of resources and time.

Earning confidence and trust is very important. Discovery phase playes a very vital role here. Effective documentation to show the understanding about existing systems and problem statement openes up many channels to come up with new idea's and architecture. This may go into multiple iterations but that is again an important phase to come up with best suitable solution where client can give their suggestions and mutually the requirements can be closed with a very strong documentation of best suitable solution.

Engaging in cross-questioning and healthy discussions is crucial for achieving goal-oriented objectives. However, there are instances where stakeholders may not agree with proposed architecture due to various reasons. Users may resist change, fail to see the potential impact, or lack a comprehensive understanding. The most effective approach to address resistance is through coaching. By immersing yourself in their environment, understanding their challenges, and actively participating in hands-on sessions, you can build trust and confidence. Speaking their language and empathizing with their perspective fosters mutual understanding and paves the way for adoption and change acceptance, ultimately reducing resistance.

Engage stakeholders throughout the process, keeping them updated with demos and ready to provide input and feedback. This collaborative approach enhances product quality and fosters customer satisfaction.