How do you collaborate and coordinate with other software architects and domain experts in your projects?

For those interested in DDD a more accessible book is Learning Domain Driven Design, by Vlad Khononov (O'Reilly) https://learning.oreilly.com/library/view/learning-domain-driven-design/9781098100124/

Understanding the domain is indeed crucial for effective collaboration. In my experience, immersing oneself in the domain language and concepts not only bridges the communication gap between software architects and domain experts but also ensures that the software solutions we develop are aligned with the business needs. Domain-driven design (DDD) has been particularly beneficial in this regard, as it helps in creating a shared understanding and a common vocabulary among all stakeholders.

As an Architect, I always create a pattern to be used for all the domains as a base, to be shared between all the domain owners as the starting point. Each domain owner has the freedom to architect the desired patterns and approaches but in the framework we and all other domain owners agreed upon. Having said that this brings consistency alongside having different thoughts and ways of design and implementation. Also, discussing features together and having a look into other domains will give us more insight and expand our capabilities regarding the new ones.

There was a time that I think software is purely tech, but I eventually understood that domain knowledge is the key to delivering best products. It affects how we design flow, what security protocols to be used, how the system should handle things, what third party tools to be used, etc. It also makes it easier for the architect to plan things that are aligned with the goal of the business and be a better bridge between stakeholders and developers

Regular Meetings: Organize frequent meetings with domain experts to understand the business processes, goals, and challenges. Documentation: Encourage the creation of detailed documentation that captures domain knowledge. This could include flowcharts, data models, and process diagrams.

To actively foster collaboration with the design process we need to adapt and translate between business needs and technological groundwork. This is achievable by creating the insights, metrics, and leverage needed in a way that stakeholders and domain experts can relate to them. So instead of drawing diagrams and explaining them to those who are paid for running the business end of the product, we should state how we are going to help them with their quest. By baking their desired degree of impact into the architecture, we pave the way for far more informed decisions. It allows us to discuss technically sound decisions with other software architects and developers but ultimately validate them according to business criteria.

Workshops and Brainstorming Sessions: Conduct collaborative sessions where architects and domain experts can collectively define the high-level architecture. Prototyping: Develop prototypes or proof-of-concepts to validate architectural decisions early, involving both technical and domain perspectives. Review Sessions: Regularly review architecture with all stakeholders to ensure alignment with business goals.

A well-defined architecture enhances collaboration between software architects and subject matter experts on projects. It provides a common reference for all team members, improving communication and aligning viewpoints. A well-documented architecture also facilitates the elucidation of needs, allowing architects to solicit input from domain experts. It also facilitates efficient coordination by clearly defining roles and interactions, reducing the likelihood of miscommunications and disputes during implementation. Thus, a clear and comprehensive architecture fosters effective coordination, shared understanding, and cooperative collaboration, ultimately achieving project objectives.

Once the architecture is designed, it is important to discuss the risk factors and evaluate each major component with other architects or the entire team to make sure that all important feedback are captures before finalizing a design

In our projects, we foster collaboration through regular meetings, workshops, and discussions to align architectural decisions with business goals. We leverage tools like collaborative document editing platforms Confluence or GDOC and version control systems to share and iterate on architectural artifacts. Domain experts are actively involved in requirements gathering and validation to ensure that architectural decisions meet their needs. Additionally, we encourage open communication channels for feedback and continuous improvement. Regular reviews and peer discussions help validate architectural choices and ensure consensus among team members.

Using lightweight, searchable, source controlled design decisions makes it easy look back and understand the state of a system historically. Using lightweight documentation reduces the burden of having to produce and maintain verbose documentation which is more likely to have mistakes.

Besides the context (why) and decision (what/how) of a design decision, all considered alternatives should be documented (including why they are discarded).

Use a shared space to store architecture decision records to make sure everyone know why components were chosen and designed that way. This is a good way to communicate all changes and keep every involved party aligned. A regualr meeting can also be scheduled to review the current state of things and what are the future goals.

Regular Updates: Maintain open and transparent communication through regular updates, newsletters, or shared documentation. Use Clear Language: Translate technical jargon into understandable terms for domain experts and vice versa to ensure everyone is on the same page. Collaborative Tools: Utilize collaboration tools for documentation and communication to foster continuous engagement.

Effective communication and alignment between software architects and domain specialists are crucial for successful project collaboration. Clear communication reduces misinterpretations and promotes cooperation. Regular meetings, training, and documentation help maintain open lines of communication. Architects must ensure their designs align with the field's nuances, catering to specific business demands and obstacles. Maintaining alignment throughout the project is essential for agile development methodologies, allowing teams to adapt to changing conditions and produce solutions that address business domain objectives.

When I was Chief Architect and when I was the Global Head of R&D and Architecture, I established an Architectural Council. They can be informal and basic or more robust and a place where everyone can discuss ideas, and proposals openly and even establish standards. If the desire of the company is to set a large vision and drive all architecture and development to that vision, then an Architectural Council is a must. The cadence needs to be established along with an outline and an objective that helps get the company closer to the vision. With time, the participants begin recognizing each other's patterns - a great thing. One of the simplest ways is to first, establish a set of common terminology and diagramming styles (mine was C4). Secp

Using ArchUnit or another unit testing framework for architecture adds early feedback about new and evolving code. Adding alerts to monitor critical quality attributes in testing and production environments allows you to gather feedback about whether design decisions are working as expected.

Regular Testing: Conduct frequent testing and validation sessions to ensure the system aligns with both technical and business requirements. User Acceptance Testing (UAT): Involve domain experts in UAT to validate that the system meets their expectations and requirements. Automated Testing: Implement automated testing strategies to ensure ongoing verification of the system's correctness.

Validation and verification are essential processes in software development. Validation ensures the system meets business domain objectives and requirements, requiring collaboration between architects and domain specialists. It involves regular feedback loops, user acceptability testing, and validation sessions. Verification ensures the software complies with technical and design specifications, ensuring alignment with the agreed-upon design. These processes foster a culture of continuous improvement and communication, resulting in a reliable software solution that meets technical and domain-specific requirements.

Validation is key to ensuring architectural soundness. On a financial services project, we simulated transaction loads to verify that our architecture could handle the expected volume without bottlenecks. We used automated testing frameworks to execute these simulations, refining our architecture based on the outcomes.

The one thing that, in my experience, it always comes down to in the end is already summarized in Principle 11 of the Agile Manifesto: The best architectures, requirements, and designs emerge from self-organizing teams. Thus, don't silo your software architecture and allow development teams to have their ideas, interests, and ambitions to be reflected in the services and products they create. Or in other words by the Principle 5 of the Agile Manifesto: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Keep querying the why/what/how. Stakeholders might box themselves in a certain way of doing things. Look outside that box to improve and optimize the architecture and the domain.

Agile Methodologies: Embrace agile methodologies to facilitate adaptability to changing requirements from both technical and business standpoints. Feedback Loops: Establish feedback loops with domain experts to incorporate evolving business needs into the architecture. Refactoring: Be open to refactoring based on lessons learned and changing business priorities.

Software architects and domain specialists must collaborate effectively through the concepts of evolution and adaptation. Evolution involves adapting to changing conditions and demands, while adaptation involves modifying plans and strategies as the project progresses. This flexibility allows teams to work more effectively and seize opportunities. A culture of ongoing learning is essential for collaboration, as architects and experts must share expertise, stay updated on market developments, and apply new knowledge to the project. This ensures robust, responsive, and adaptable software solutions.

This is the pattern I follow the most because I work with startups. We always start with the simplest to hit the time to market goal for the MVP. The strategy often ends up in monolith, which then gets slowly broken into services, then adding cache, load balancing, and other patterns to keep the architecture growing with the business. This prevents too much time spent on building MVP without product market fit.

Writing design retrospectives offers an opportunity for the organization and beyond to learn from your teams successes and failures.

Postmortems for critical incidents and retrospective meetings for common ones are key factors here. After deploying any application, we hold retrospective meetings to discuss what worked and what didn't, leading to improvements such as adopting container orchestration for better scalability and resilience in future projects. Any showstoppers that occur will have a dedicated postmortem meeting, which will produce a list of actions to prevent recurrence.