English | EN 
Introduction
In the ever-evolving landscape of enterprise architecture, managing complexity and ensuring seamless integration of technologies are essential. Enterprise architecture practices are not merely about creating static blueprints or enforcing rigid standards; they are about fostering a dynamic and adaptive approach to guide the flow of change within organizations. By employing metaphors like the flow of a river, we can better understand how practices such as technology standardization and solution architecturing contribute to the overall efficiency and agility of an organization. These practices are essential for navigating the intricate interplay between structure and flow, much like managing the Dutch waterways requires continuous effort and collaboration.
Technology Standardization
Imagine an organization as a vast landscape with rivers of data and processes flowing through it. Technology standardization is like regulating the width and depth of these riverbeds. By defining and enforcing standards for programming languages, databases, operating systems, and hardware platforms, the organization aims to reduce complexity, improve interoperability, and lower maintenance costs. This practice ensures that the flow of data and processes becomes more predictable and efficient, preventing the formation of isolated pools, or technology silos, and ensuring that all parts of the system can easily connect.
However, just as a river forced into a concrete channel can become rigid and inflexible, over-standardization can stifle innovation. The key is to strike a balance, ensuring that standards are clear and beneficial without becoming overly restrictive.
To achieve this, it’s crucial to communicate the rationale behind standardization choices. Developers and practitioners must understand not just the standards themselves, but why they are beneficial. This is like explaining why certain dimensions of a riverbed are necessary for optimal flow and navigation. By fostering “practical understandability” (Schatzki, 2001), we promote practical knowledge of how to operate within the given constraints.
Standardization should not be seen as a static, one-time activity. Instead, it must be continuously reviewed and adapted to accommodate new technologies and evolving business needs. Just as a riverbed may need to be dredged or widened over time, technology standards need to be periodically reassessed.
Moreover, fostering a community of practice around technology standards allows practitioners to share experiences, discuss challenges, and collectively refine the standards. This resembles the ongoing communication and collaboration among stakeholders involved in managing a waterway, like lock operators, skippers, and water boards.
Solution Architecting
Solution architects are like the engineers tasked with designing and building bridges across a river. Each bridge, or solution, must be carefully designed to connect different parts of the landscape—business units or systems—while ensuring that the overall flow of the river, or business processes, is not disrupted. The bridge must be strong enough to withstand the current, or data volume, and be aligned with the overall direction of the river, or enterprise architecture.
Solution architecting involves a lot of negotiation and compromise between different stakeholders. The “doings” of solution architects should focus on building consensus and finding solutions that meet the needs of all parties involved. This process is similar to negotiating the design and placement of a bridge with various stakeholders, such as local communities, environmental agencies, and transportation authorities.
Solution architects work with various tools and representations, like UML diagrams, prototypes, and technical specifications. These “material arrangements” are not just passive tools but actively shape the way architects think and interact. Encouraging the use of tools that facilitate collaboration and visualization makes the architecture more tangible and understandable to everyone involved, much like how physical models and simulations are used in bridge design.
Furthermore, solution architects should continuously monitor the implementation of their designs and reflect on the outcomes. This “reflexive monitoring” (Schatzki, 2001) allows them to learn from their experiences and improve their practice over time, much like a bridge engineer who observes how a bridge performs under different conditions and makes adjustments to future designs.
Conclusion
By applying the lens of practice theory and employing metaphors like flow and the river, we gain a richer understanding of enterprise architecture practices.
These examples demonstrate that enterprise architecture is not just about creating static documents but about fostering a dynamic and adaptive approach to managing complexity within organizations. It is not about dictating a fixed route but about guiding the flow of change towards a desired future. As with the management of our Dutch waterways, it requires continuous effort, collaboration, and a deep understanding of the intricate interplay between structure and flow.
References
Schatzki, T. R. (2001). Introduction: Practice theory. In T. R. Schatzki, K. Knorr-Cetina, & E. von Savigny (Eds.), The practice turn in contemporary theory (pp. 1–14). Routledge.