Over the past couple of few years clear differentials have emerged between two types of business ecosystems: Static ecosystems and dynamic ecosystems. This blog tries to explain the difference between the two and the strategic implications that need to be considered in their deployment.<\/p>\n\n\n\n
Static ecosystems are usually structured and hierarchical. Typically, they have one dominant player who sits at the center (or at the top) and distributes enablement knowledge (learning, marketing \u2026 etc) to a channel using clearly identified and standardized rules of engagement. They could be single or multi-tier (if we add distribution). A typical example here could be a car manufacturer with its dealers, or an IT vendor with a VAR channel.<\/p>\n\n\n\n
Static ecosystems stand in stark contrast to ones that are emerging, which need to be created \u201con the fly\u201d to serve several organizations for a specific period to meet a specific objective, which are ad hoc, and which are non-patriarchal meaning no one entity dominates. An example of this was seen in the past couple of years when several pharmaceuticals got together in a very short period to co-enable, scale, and deliver on the promise of a Covid vaccine. None could have done it alone, so they created alliances among equals. Everyone exchanged knowledge with everyone. Everyone enabled everyone. This occurred under alliance agreements that protected the different entities during the relationship. This ecosystem had to be assembled, scaled, and enabled and at warp speed to meet pandemic deadlines. It did not follow any traditional rigid channel rules; and needed to be much more flexible. Once the mission was accomplished, this type of ecosystem might very well be disassembled. This is basically a dynamic ecosystem<\/strong> spun up, scaled, and spun down at will.<\/p>\n\n\n\n Why is differentiating these two types of ecosystems important to highlight? Quite simply because it has immediate strategic implications for the type of tools and platforms that could be used to deploy them. In other words, if the strategy is to launch a dynamic ecosystem, but tools deployed are static, failure or at best high levels of inefficiency would likely follow. As it happens, most channel tools, which were architected in the 1990\u2019s and 2000\u2019s were developed to serve static partner programs. Bending these traditional ecosystem tools to now serve dynamic ecosystems will therefore not yield the desired results.<\/p>\n\n\n\n Let\u2019s look at an example: I can probably interact with my static channel and partners using a PRM in a unidirectional way and provide knowledge and information. I may even be able to collect some activity from the partners. But what if I was just tasked to integrate with a handful of alliance partners each of whom has their own LMS or CMS? Would I be able to easily connect with them and exchange knowledge? What if they have compliance issues and don\u2019t allow PII to be passed through nor want to send their users to any of my portals? What if they wanted to share information with my organization, while asking that I share mine with them? What if I needed to customize things to each one of them in slightly different ways? Unfortunately, static ecosystem enablement tools are unlikely to solve any of these requests. Technically, such tools would need to be re-architected from the ground-up to be able to do a portion of the above\u2014a difficult, time-consuming, and costly undertaking.<\/p>\n\n\n\n Tools that were designed for dynamic ecosystems, however, can do any of this in a matter of minutes. They were architected with built-in nodal flexibility to allow organizations to spin up an ecosystem node, connect it to their backends, and then network their node with that of any other partner on the network that they want, whenever they want, and in the manner they deem acceptable. These dynamic ecosystem nodes can be taken down in as equally rapid a time frame as they were spun up. They can also serve upstream vendors, side-stream alliances, or downstream channel enablement flows (or a combination thereof). They are virtual, scalable, efficient, and generally cost much less than their static counterparts.<\/p>\n\n\n\n Picture this scenario: Your boss comes in one day and says, \u201cListen Mary, we have this urgent alliance that we need to fully enable. I need our organizations to work with one another seamlessly as if we were one for at least the next 6 months. I need this done asap, and within budget. Are we clear?\u201d Which of the two types of ecosystem tools should you be thinking about? A Static ecosystem platform that requires lengthy deployments and is generally unidirectional? Or a dynamic one that can be spun up in a matter of minutes; that allows any of the alliance companies to have their own node, interconnects them, and integrates with their pre-existing systems; that provides multi-directional flows and metrics; that no single partner can dominate; that is affordable; and that can be switched off in 6 months or once the mission has been realized?.<\/p>\n\n\n\n Dynamic ecosystem platforms are emerging to serve changing industries such as educational institutions who want to connect to industry for extended learning, pharmaceuticals who need to resolve imminent outbreaks, governments who need to connect with other government organizations, non-profits wanting to engage with private organizations, and IT organizations whose traditional static structures no longer can meet their rapidly changing ecosystems. All of them are looking for a more modern architecture that allows speedy, flexible, compliant, and scalable enablement.<\/p>\n\n\n\n If we assume ecosystems will be the next frontier of digital transformation, we must also assume that more dynamic ecosystem platforms will be the ones more likely to succeed in this warp-speed changing world.<\/p>\n\n\n\nKey differentials and strategic implications<\/h3>\n\n\n\n
Tools for dynamic ecosystems with nodal flexibility<\/h3>\n\n\n\n
Dynamic Ecosystems and multi-directional flows and metrics<\/h3>\n\n\n\n
Towards accelerated and scalable enablement<\/h3>\n\n\n\n