The Ecosystem Architect - You Already Are One, You Just Didn't Know It

Joeri van Es

As architects, we are accustomed to creating frameworks for our own organizations. However, our work is increasingly extending beyond the boundaries of our own domains. We contribute to and use reference architectures: frameworks of shared principles and models that serve as a guide for an entire sector, such as the Dutch government (NORA), municipalities (GEMMA), or the education sector (ROSA). 

A reference architecture does not contain standards itself, but functions as an overarching organizational blueprint. It determines where and how more specific standards and agreements should be applied within the ecosystem. A good example is the IAM (Identity and Access Management) domain within ROSA (the education reference architecture), which develops patterns for identity and access management. It provides puzzle pieces that show how this can be organized across the domain. 

As soon as you work with such a framework, you transcend the role of an Enterprise Architect. You are then shaping an entire network of collaborating, autonomous organizations. This is the essence of ecosystem architecture. Every architect who contributes to a reference architecture and uses it is, in practice, an ecosystem architect. Often without calling it that. 

The Inevitable Journey Outward 

This shift from an internal focus to an external orientation was a logical evolution, which we can describe through a series of clear steps [1]. Initially, Enterprise Architecture (EA) was primarily inward-focused, centered on the organization itself. The first step outward was the creation of an Extended Enterprise Architecture (EEA), in which external parties such as customers, partners, and suppliers were included in the architecture. The next phase was that of the federated or collaborative network. Here, multiple organizations actively exchanged parts of their architecture and negotiated standards and processes for mutual benefit. This is the phase where most ecosystems within the Dutch public sector now seem to be. The final steps in this development lead to a Business Ecosystem Architecture. In this, a central player analyzes the architectures of specific partners for strategic interventions, which ultimately leads to a comprehensive BEA in which an overarching network organization defines and manages the standards for the entire ecosystem. 

This entire development takes place within what we call a business ecosystem. This concept, introduced by James Moore [3], applies principles from nature to the economy. We can define a business ecosystem as a dynamic, self-organizing network of interdependent organizations that collaborate across traditional industrial boundaries to co-create value. These ecosystems often arise from government digital initiatives and lead to a rich network of actors and their interconnected information technology. Within this context, it is essential that processes, data, and IT systems align seamlessly to achieve interoperability. 

The 'Aha!' Moment: The Reference Architecture as the Big Picture 

The reference architectures that emerged from this were the answer to this complexity. In practice, we often see them as a rulebook for our own puzzle piece; a checklist to ensure we are 'compliant with the standard.' 

Herein lies the revelation. Unconsciously, we were doing something much more fundamental. We were not creating a rulebook, but the image of the entire puzzle. With our reference architectures, we gave concrete form to the most mature stage of collaboration: the Business Ecosystem Architecture. 

The Power of the Common Denominator 

These ecosystem architectures are of a clever kind. Instead of trying to capture all the puzzle pieces in detail and link them together through complex technology, a reference architecture makes a pragmatic choice. It consciously focuses on the common denominator: an abstract model that only records the shared principles, patterns, and building blocks that apply to all parties. 

This is a strategic choice. The goal of architecture is not to collect details, but to gain insight into the interdependencies of a complex socio-technical system, so that we can change it with precision. An overly detailed big picture is distracting; an abstract, shared blueprint provides focus on the crucial connections. 

The Gain: A Focus on Interoperability 

By viewing our reference architecture as the big picture, the end goal of our work shifts from conformity to interoperability. A comprehensive definition of this is: 

"The ability of distinct systems to share semantically compatible information, perform compatible transactions, and collaborate in a way that aligns with the business processes of the users. [2] "

This includes multiple layers: 

• Technical interoperability: Can the systems technically communicate with each other via shared protocols? 

• Semantic interoperability: Do the systems understand the information in the same way? Do we use a shared conceptual framework? 

• Operational or business interoperability: Are the business processes and policies of the organizations aligned with each other? 

A reference architecture is not the same as an Interoperability Framework (IF) [2], but it is an important supplement to it. Where an IF focuses on the concrete interfaces and standards, a reference architecture focuses on the overarching functional and organizational structure. The reference architecture is the blueprint that creates the necessary conditions for real, layered interoperability to emerge. 

Embrace Your Role as an Ecosystem Architect 

The message is clear. As soon as you work with a reference architecture, you are an ecosystem architect. The instruments you use daily are more powerful than you might think. Let's embrace our reference architectures for what they really are: the strategic blueprints for our digital ecosystems. Let's use them to not only fit our own puzzle piece, but to make the entire puzzle of the public sector ecosystem fit together better. 

References 

[1] Drews, P., & Schirmer, I. (2014, September). From Enterprise Architecture to Business Ecosystem Architecture. 

[2] Rothenberg, J., Botterman, M., & van Oranje-Nassau, C. (2008). Towards a Dutch Interoperability Framework. Recommendations to the Forum Standaardisatie. RAND Europe. 

[3] Moore, J. (1996). The death of competition: Leadership & strategy in the age of business ecosystems.