Wystem 2: On Ecosystem APIs
Don’t like reading? Want to watch instead? We have a video for you:
Need something to listen to while going from place A to place B? Forget the video and plug into the audio stream 📻.
The complex problems faced by the social sector demand solutions that transcend the boundaries of any single organization. To achieve systemic progress on the most pressing issues, a shift in mindset is imperative – one that views collaboration and coordinated action as the very building blocks of success. Yet, unlike traditional economic models, our social infrastructure often lacks the connective tissue required for this degree of unified movement.
This lack of seamless connectivity within the social sector is a crucial roadblock. Currently, efforts remain siloed, and a true 'relay' effect is missing. Insights from one project rarely inform future work by another organization in the same space, leading to a loss of valuable knowledge and potential for greater impact. The question lingers: how do we transform this fragmented landscape into a dynamic, interlinked ecosystem where innovation and change can flourish?
We've been thinking a lot about how to get ecosystems of organizations in the social sector to work together and use relays across the ecosystem to address wicked problems. That's easier said than done, because unlike the market system, where the output of a producer becomes the input of the customer who then adds value to it and then takes it onward eventually till you get an end user, we don't quite have the same set of relays in the social sector.
A philanthropist or a donor might give money to an organization for a project, but the output of the project isn't relayed to another organization typically. It's just the project results, and the assessment of impact ends with that organization and doesn’t travel to other parts of the ecosystem. How do we use a computational mindset and in particular the idea of the application programming interface or API to create relays in the social sector?
This Messenger is devoted to the design of Ecosystem APIs.
What is a relay? We're all familiar with the metaphor of relay in a race. I carry a baton, and when I reach the next person in the race, I hand over the baton to them, who, in turn, take it forward to the next person in the relay until you end the race, whether as a winner or not.
How might this work in the social sector?
How do we design relays from one organization to another? Let me give you an example of the kind of challenge that we might face. In last week's messenger we talked about maternal health. So imagine organization A that's working on maternal health. They make sure that an expectant mother is healthy and has got all the resources to go through with a safe and comfortable delivery.
Now, suppose there's another organization, B. that engages with nutrition in infants and toddlers. How do we design a relay between the two organizations? How do we make sure that the same family has a handover from the mother to the child from organization A to organization B? What is the correct handover mechanism? There's no single answer to this question. There could be many ways of doing a handover. The simplest thing to do might be a jointly held spreadsheet in which information about families in the community both organizations serve are jointly available to both Organization A and Organization B. Organization A looks at maternal health and says, I'm done with my job, the child is born, the mother is healthy, I'm now ready to hand over and the spreadsheet. Organization B says, I am now going to take over this family, and I'm going to be serving them as a facilitator of nutrition to the infant rather than as a provider of resources to the mother.
The example of maternal health and infant nutrition highlights a key challenge, but also an extraordinary opportunity. Building an effective relay system demands more than simple data transfer. It requires the development of a shared language, an understanding of the distinct roles each organization plays, and crucially, a focus on the needs of the family at the center of it all. The "spreadsheet solution", while a potential starting point, likely falls short on several fronts.
Instead, imagine a shift towards an ecosystem approach with a platform that hold it all together. This platform would not only enable the secure exchange of necessary information between organizations but serve as a collaborative workspace. It could house standardized assessments, track milestones of the family's journey, and offer seamless access to relevant resources. This interconnectedness fosters shared responsibility, ensures continuity of care, and ultimately empowers the family to take informed ownership of their well-being throughout this vital stage of life.
The common database may be a simple solution, but there can be more complex solutions too. For example, there is the idea of secondment, which is about making people available across organizations. If there is a person in organization A who really understands mothers who becomes available to organization B because child health is deeply tied to maternal health, and nutrition in the child, after all, is primarily function of how the family treats the relationship between the mother and the child. Therefore, it's important for organization B, which is focused on child nutrition, to also engage with organization A that ensures maternal health. And secondment, therefore, could be a very sort of human interface between the two. a human being who's on one side actually travels to the other. So that's a much more involved and expansive interface between the two organizations.
Secondment is compelling because it underscores the importance of human-centered connections within the social sector ecosystem. Through this exchange of expertise, we see knowledge organically flowing between organizations, fostering deeper understandings and breaking down traditional silos. Furthermore, it has the potential to nurture a culture of empathy and collaboration, where individuals truly see themselves as part of a wider network dedicated to holistic improvement.
Of course, there are practical considerations to navigate with secondment. Capacity constraints, funding models, and the sensitive nature of shared information will all require careful attention. However, the potential benefits are significant: an increased capacity for tailoring solutions, the ability to anticipate challenges earlier in the process, and the building of relationships that extend beyond a single project or data exchange.
But this is just at one organization to another organization level, in an ecosystem, there will be many relays. It will be very complex. And how they all interact is something for us to think through. We're not going to be dealing with that in today's Messenger, but maybe we'll talk about it in the future. A good analogy for all of this is that of a restaurant, where a customer comes in, looks at the menu, orders, the server takes the order and goes into the kitchen, hands over the order to the kitchen staff, who prepare the food.
The dish is then handed back to the server who then comes and serves the customer. So there's a cycle from customer to kitchen to customer with the server in the middle and there are only certain things that each one of them care about. Typically, a customer only cares about whether the server is taking their order correctly or not. That's all that the API cares. It doesn't care about all the other things that might be going on in my head as a customer and in the chef's head as the cook. As long as the parts of the system that need to be exposed to other parts of the system are working, we don't care about other things.
Now, imagine this same principle applied to the social sector. In this context, the "customer" is the community, the "menu" represents the range of services and resources available, and the "order" encompasses the unique needs of each family or individual. The success of this model hinges on well-defined communication channels and efficient workflows between those who assess needs, those who design interventions, and those who deliver them on the ground.
The cyclical flow of the restaurant model, with its clearly defined roles and interfaces, paints a compelling picture of the potential within complex social sector ecosystems. This focus on the specific handoffs between stakeholders – those identifying needs, those crafting solutions, and those serving communities – emphasizes the power of well-designed APIs in streamlining processes. By focusing on essential points of interaction, complexity is reduced, allowing resources to be directed towards delivering maximum impact.
However, it's crucial to remember that the individuals and families served by the social sector are not simply "customers." Their needs are multi-faceted, their journeys often unpredictable. This necessitates a balance: a structured approach for operational efficiency must be paired with a genuine commitment to person-centered care. APIs can help ensure that vital information follows those we serve, but they are no substitute for empathy and the ability to build trust.
Perhaps the ideal API for the social sector draws inspiration from the restaurant's exceptional server. They understand the menu inside and out, they anticipate the customer's desires, and they communicate seamlessly with the kitchen staff. Such an API wouldn't simply transfer data; it would facilitate understanding, promote collaboration, and ultimately champion the unique needs of each person or family traversing the ecosystem of care.
TLDR; The idea of the API is to make sure that the things that two organizations need to share are being relayed appropriately. We don't want to interfere too much into the internal processes of the individual organizations.
Will this work? We don't know. But until we try, we have no way of knowing whether this is a good idea or not.