At the Explore DDD conference in Denver, Colorado, Diana Montalion said software architecture is about designing for knowledge flow, with the goal of software teams learning more about the system they are building. Knowledge flow contrasts with the common focus on knowledge stock, which is about information that is already known. She sees effective architects as librarians, helping disseminate knowledge.
In the words of Dave Snowden, "The flow of knowledge is more important than the storage of knowledge." This thinking is analogous to the differences between a growth versus a fixed mindset, terms coined by Carol S. Dweck.
In her keynote presentation, Montalion described organizations seeking a transformation because their legacy systems and processes encountered various limitations. However, those orgs expect a new architecture to stay within existing boundaries and provide rational, predictable results. This will result in something "new" that faces the same limitations and does not greatly enhance the system's capabilities. The audience was receptive to an anecdote where a company wanted microservices without understanding what that really meant or wanting to make all the changes necessary to operate a distributed system successfully.
Among the many quotes she shared throughout the presentation was one from Robert M. Pirsig: "If a factory is torn down, but the rationality which produced it is left standing, then that rationality will simply produce another factory." She thinks back-to-the-office mandates have roots in a resurgence of this type of thinking.
In order to achieve a change in the team's mindset, architects need to fully understand what created the current mindset. Using an iceberg metaphor, she said it's easy to focus on what is visible. Not only is this a limited view of the system, but it can also be very biased by what people complain about, ranging from users to other teams to legacy code or almost anything.
To gain a better understanding of a system, look under the surface to find patterns, trends, values and beliefs that shape the system. She said this "helps identify the mindset out of which the system's goals, power structures, rules, and culture arise." Identifying this mindset allows you to avoid a lift-and-shift to a new architecture that has all the same problems underneath the surface.
Montalion walked through six elements that she believes architecture should include when the goal is knowledge flow. First, communicate the context because all stakeholders and the software team must have a shared understanding of the context to be aligned on what needs to be developed. Next, cultivate a growth mindset. Montalion quoted Peter Senge, saying, "Sharing knowledge occurs when people are genuinely interested in helping one another develop new capacities for action; it is about creating learning processes."
The third element is understanding the relationships in the system and what effects they produce. Bounded contexts are part of a system, but they also have relationships to each other, and that is what generates a core domain. She cited Russel Ackoff, who said, "A system is never the sum of its parts - it’s the product of their interaction." Those interactions also include relationships between people and teams, because a socio-technical system has both software parts and people parts.
Next, we need to architect capabilities rather than "platforms" or "pipelines" or "microservices." Focusing on what a system must do, adapt to, and make sense of within a domain (rather than how to build or deploy it) means thinking at a higher level, almost "designing the system of designing the system." Montalion believes this is critical because "transformation doesn't scale through procedures and pipelines - it scales through capabilities. And capabilities are architected, not engineered."
To achieve maximum transformation, look for leverage points. These are places in the system where a small shift in the structure can produce significant, lasting change. This allows teams to unlock and release the energy that's bound up in "legacy" processes and thinking. However, finding these is not the same as being able to exploit them. In the words of Donella Meadows, "We know from bitter experience that when we do discover the system's leverage points, hardly anybody will believe us." Montalion calls this The 18-Month Rule, because people are slow to change how they see and do things. When they eventually reach the same conclusion, they won't believe it's what you told them 18 months ago.
Going through all the previous steps places architects and leaders in a position to cultivate and generate knowledge flow. "Leadership is about powering a company that leverages its knowledge," said Montalion. Architects are often asked to create a diagram showing exactly what to build, but the real request is for knowledge flow. Montalion acknowledged that this is an ability that grows over time. "We need to practice knowledge flow to learn knowledge flow."
Having provided the general concept of knowledge flow, Montalion used examples to explain some techniques and practices architects can adopt. Because large systems are complex, and understanding everything will take time, it helps to just get started, and have documentation and processes that can evolve organically.
Too often, there is not one place where someone can go to learn about a system, its capabilities, and the domain. Even when some documentation exists, it's difficult to "click into" an area to see more detail. The goal is to create a knowledge graph with collections, views, tags, and bidirectional links for relationships. Although these concepts are not new, and go back to the basic idea of hypertext and hypermedia, there is room for improvement in the technology available to create knowledge graphs.
Creating a knowledge repository is one tangible artifact along the journey of architecting for knowledge flow. Architects know "it depends" is often the right answer. Montalion was enthusiastic about this, because "we get to figure out what it depends on. That's wisdom." Architects can facilitate the sharing of knowledge, which encourages the development of new capacities for action. That is what is needed to achieve a transformation.
