Good software architecture is context-specific, but there is one thing the architecture community agrees on, it's the importance and power of Conway's Law. “Conway's Law is essentially the observation that the architecture of a software system looks remarkably similar to the organization structure of the development teams that built it.” One way to use Conway’s Law to our advantage is to perform what is known as an 'Inverse Conway Manoeuvre'. This enables you to evolve your team and organizational structure to promote your desired architecture. Domain-Driven Design plays a role with Conway's Law to help define organization structures, since a key part of DDD is to identify Bounded Contexts. A key characteristic of a Bounded Context is that it has its own Ubiquitous Language, which is defined and understood by the people working in that context.

We (Danske Bank) are working on a Digital transformation journey enabling us to become a better bank. Our journey is guided by our North Star & Turn to New Technology principles, with the Better Ways of Working and Team Topology initiative enabling our Agile and DevOps culture. We are applying Domain-Driven Design to reshape and transform our existin software landscape. Our journey started with DDD training across the organization using DDD Bootcamps with hands-on training and a DDD focused guild. We have successfully stablished a Domain-Driven Architecture at Scale using an Infusion model. Collaborative Modelling using EventStorming & StoryTelling helped domain teams to discover their domains and produce artifacts such as EventStorming board, Context Map, Domain Model and Resource Model in 2-12 weeks. These artifacts are the starting input for the development of microservices and deploying to cloud by Design & Implementation infused enabler teams. Enabler teams are buddies to stream aligned teams on defining clear boundaries for core domains and untangling tightly coupled business logic, which is exposed as an API with minimal reverse engineering. New and updated business capability started becoming available within 3-6 months. The process is being matured by applying initiatives such as two-way feedback loop, Make a Captain, Fail Fast, MVP and No-more-capability development on mainframe.

Challenges we currently face are:
1. Strict ownership of operation data within core systems
2. Analytical data team working in silos with no understanding of domain data (Analytical data ownership).
There is currently a paradigm shift happening in the design of a data platform at enterprise level and a realignment of operation and analytical data ownership. An enable for this are the Data Mesh principles of Data as Product, Self-Serve Data Platform and Federated computation governance. These principles resonate well with the domain ownership principle of Domain Driven Design.