How do you communicate data architecture decisions?

Data architecture is really about solving a business problem or addressing a business need. It needs to be explainable in plain language, without technical jargon, so everyone can get onboard with it. Sometimes this will mean you need to have a lot of informal coffee meetings to build the mental maps for people to understand what you are trying to do.

Understanding your audience goes beyond simply knowing their technical proficiency and business acumen. It also involves empathizing with their pain points and addressing their concerns proactively. Example: executives tend to focus on how data architecture decisions impact the bottom line, while compliance officers typically prioritize data security. Make an impact by highlighting benefits of the proposed architecture in efficiency, cost savings, and risk reduction. Additionally, incorporating real-world examples and success stories can help illustrate tangible outcomes of decisions. Effective communication not only informs but also inspires action, thus making data architecture decisions compelling and actionable. That is what you want.

UNDERSTAND THE STAKEHOLDERS. Different stakeholders will have different needs and levels of understanding. I would identify who needs to be involved in the decision-making process and communicate with them accordingly. This could include IT teams, business analysts, executives, and other relevant departments. UNDERSTAND WHAT THE BUSINESS NEEDS AND STRATEGIES ARE. INVOLVE STAKEHOLDERS AND RELEVANT TEAMS EARLY: By involving relevant teams in the decision-making process from the beginning, I would foster a sense of ownership and collaboration. This can also help in identifying potential challenges and solutions early in the process.

Understand your audience to keep them on the same page! It's critical to understand your audience before explaining data architecture decisions. Take a deep dive into the specifics and benefits for tech-savvy people. Keep it straightforward for non-techies and concentrate on how it benefits the company. This ensures that everyone's data plans are effective and that everyone is on the same page.

Effective communication is key in conveying data architecture decisions. I find that breaking down complex technical concepts into simple, relatable terms helps bridge the gap between technical and non-technical stakeholders. Regular informal meetings, like coffee sessions, are invaluable for building a shared understanding and aligning everyone towards the common goal. It's not just about the technology; it's about how it serves the business and addresses its needs. Let's keep the conversation accessible and collaborative!

In the work that I do with clients I find that creating a business data model which is probably higher than a conceptual model which shows the various domains in their business and then in each which entities matter to them in a visual is a very powerful way to help them understand data architecture. It also adds to their understanding of what data sits in each area. Once you have gone a little deeper and worked out what that data is you can then reflect that back to them to show them what is available and what isn't. If they can see this early on they start to get the fundamentals of the data they have in their business and as we go deeper into logical and physical models it's easier for them to understand what that means.

One interesting technique here is the shameless representation of complexity. Typically diagrams are meant to *simplify* but every once in a while - in organizations that have REALLY big data messes (coupling, multi-master-no-winner, rule sprawl/conflict, rule ambiguity, source or target sprawl, etc.) it’s helpful to represent the mess in all its glory. Be it a static diagram expressing structure, a matrix with a 25 line key/explainer text, or a flow diagram that has so many crosses and tie backs it’s basically illegible. Sometimes the best thing you can do - especially to rationalize and motivate change - is show the full complexity for effect!

I couldn't agree more with the emphasis on using visual aids to communicate data architecture decisions. Visual aids play a crucial role in enhancing understanding and retention, especially considering that a significant portion of individuals are visual learners. In my current role in Pre-sales, I have personally witnessed the power of visual aids in conveying complex concepts effectively. For example, presenting a diagram that showcases the customer's ecosystem and seamlessly embedding my solution into an architecture they are familiar with, has proven to be immensely impactful. It not only helps me illustrate the core functionality of my solution but also enables the client to envision how it seamlessly fits into their existing setup.

Utilizing visual aids not only enhances clarity and conciseness but also engages the audience on a deeper level. We're inherently visual learners, and incorporating captivating visual elements can create a lasting impression of data architecture decisions. When crafting visual aids, consider tailoring them to resonate with the specific preferences of your audience. For instance, data engineers might appreciate detailed technical diagrams, whereas executives might benefit from high-level infographics that present overall impact and benefits. Balancing simplicity and complexity allows you to effectively convey intricate data architecture concepts without overwhelming your audience. A well-designed visual aid can transcend language barriers.

USE COMMON LANGUAGE: Tailor the visual aids to your various audiences. You may need more than one type of visual aid to effectively story tell to non-technical vs technical vs management/executive audiences. Avoid jargon and technical language when communicating with non-technical stakeholders. Try to tie the visual aids to the business processes to help ensure understanding of data sources, transformations, and destinations.

From my experience, I start with highlighting the financial implications of the data architecture decisions to make the case for my chosen approach, like: Cost Savings: Explain how the selected architecture can lead to cost savings in terms of infrastructure, maintenance, and data processing. Compare these potential savings with the costs of implementing and maintaining the architecture. Return on Investment (ROI): If the architecture is expected to result in increased revenue or improved operational efficiency, quantify these benefits. Show how the initial investment will lead to long-term gains. And lastly explain Resource Allocation, for instance, highlight how data storage and processing costs will be managed more efficiently.

In my experience, people need to be actively involved to be truly engaged in communication. Bringing people into a conversation early and allowing them to provide input is an effective way to establish clear communication and understanding, this applies to data architecture as much as any other business solution or change. People like to be informed and if they feel like they are actively involved, then communication and sharing of information becomes much easier.

The rational should give reasons to understand the Data Architecture, giving context for the decisions that were made. For that, it should contemplate subjects ranging from business strategic goals to user approaches, focusing on costs optimization, improving of data quality and consistency, compliance promotion, efficient decision making, security and privacy and accessibility. The rational should communicate these points to all stakeholders so they can understand what was decided and what is the value of the proposed Data Architecture.

Architectural decisions have specific template like below : Architectural Decision Reference : Ex ADx where x could be a number. AD Description : Solution Option 1: Solution Option 2: Solution Option 3: For each option define below : Pros Cons Rationale Using above parameters in template you can well define the decisions.

An ecommerce company had a centralized data warehouse, but it was difficult for business teams to access and use the data. The data was often siloed and outdated, making it difficult to get a complete view of the business. The architecture was evolved and the company implemented a data mesh architecture. Each business domain like sales, marketing, customer service became responsible for its own data. The rationale behind distributing data ownership is to enhance data quality and usability, ensuring that each team is responsible for maintaining the integrity and security of their specific data domain.

Tie the architecture to how it is addressing the business issues/strategies you have been tasked with addressing. For example, address regulatory/legal requirements, driving revenue, improving efficiencies, addressing security/privacy, etc. Tie visual aids/diagrams and documentation to the business processes to help ensure understanding of data sources, transformations, and destinations.

A summary / description about the architectural decision is always very useful we could include the context which could be business , technical , security , data etc etc.

Key contexts that have been helpful to me when representing data: - business capabilities matrix to data entities - functions or departments who create/update vs functions or departments who consume/need the data entity - data entities or subject areas that are needed by strategic goals or objectives: tracing data to outcome

Usually, data architecture decisions are influenced by regulations, so it's crucial to provide context for compliance: So to explain further give Regulatory Landscape to explain the relevant regulations, standards, and compliance requirements that impact the data architecture decision. This could include data protection regulations like GDPR or industry-specific standards. Then explain mitigating Risks by describing how the chosen architecture aligns with these regulations and helps mitigate potential risks. And finally outline the measures in place to ensure data governance and security, highlighting encryption methods, access controls, and auditing mechanisms that support compliance.

Feedback and Feedforward are important pillars of communication! Data Architecture is perceived as complex by non-data professionals. So when communicating Data Architecture, make sure consumer understanding. Ask for opinion, feedback, suggestions. Keep discussions alive by allowing different questions. More questions mean more interest. More suggestions mean more engagement! Share your opinion and view points to verify how much impactful they are.

Seeking feedback should be part of the development of the data architecture. However, it also needs to be recognized that some things could be missed and maintenance will be required. People need to feel comfortable bringing up issues they see. There needs to be someone they can take concerns to. When data issues are uncovered, research needs to be done to determine the root cause. If the root cause comes from the data architecture, there needs to be a process in place to revise, test, communicate, and implement.

Seeking feedback after the decision is made is way to late. For key stakeholder I would always recommend to ensure their support and feedback during the decision process. Trying to convince business to follow a strategy that was made without them is always harder than have them be the promoter of their own decision.

Encouraging feedback from the various teams / stakeholders is key to understand if the communicated information is clear and if there are any concerns or suggestions for improvement and allows for continuous improvement. Actively listening and implementing suggestions not only improves the process but increases trust with the stakeholders/partners.

Think of feedback as both a compass and a mirror. First of all, incorporating feedback is akin to a compass that guides your data architecture decisions towards success. It empowers stakeholders to participate actively, ensuring alignment and collective ownership. Secondly, feedback acts as a mirror, reflecting potential gaps and presenting opportunities for improvement. Embrace diverse perspectives and constructive critiques, viewing them as catalysts for growth. By remaining receptive and adaptable, your data architecture becomes a living entity, optimized to navigate the complexities of your organization's data landscape, hopefully, leading your organization to new heights of effectiveness and relevance.

In short, only communicate this level of detail to those who are impacted. This could easily be considered noise. The business shouldn’t care about how something is architected unless it will impact them in a negative way.

Data architecture decisions are frequently “one way door” decisions—when done correctly, they are a competitive advantage. When done incorrectly, the consequence could be severe. Consequently, communication about data architecture decisions are not just done once or in one forum. They are communicated several times in multiple ways. In addition, they must be collaborative since data touches all parts of an Enterprise. Create a team of experts within the company consisting of data producers and data consumers, collaborate on the decisions and present recommendations as a consensus. This will ensure all stakeholders are considered.

- Start with the business need. Any architecture decision should be backed by a solid business case and should be directly linked to a strategic business value like better customer experience, reduced operating costs etc. - Present various solution approaches audited with proof of concepts to collect the results. With those data points collected, show the sponsors and stakeholders the best way forward. Get the sponsor sign-off. - Create and finalize a project implementation plan, delivery team structure and freeze the updated solution architecture. - Conduct organization wide knowledge sessions to educate all the impacted stakeholders and teams of the decisions, approach and the need for change. - Actively publish project status reports

I believe we should also include which area of the organisation this architectural decision is impacting? It could be anything like business , data , process , technology , infra etc.

USE MEETINGS/COLLABORATION TOOLS: Regular status meetings and updates would help in ensuring that everyone is on the same page and that concerns and questions are addressed timely. Utilizing collaboration tools like Confluence or SharePoint allows for centralized storage of documents and facilitates easier collaboration across various teams. ARCHIVE AND VERSIONAL CONTROL: Keeping an archived and version-controlled history of the decisions helps in tracking changes and provides a reference for future decisions. EXECUTIVE SUMMARY: For upper management or C-level executives, summarizing the decisions and impacts. Include the business value, risks, and how the decisions align with the overall business strategy.