Open Platform 3.0™ Snapshot – Wider Business Ecosystems (Informative)
An enterprise can act as an entity within the ecosystem of another enterprise, or within a wider business ecosystem that is not maintained by any particular enterprise. In such a wider ecosystem, each enterprise makes services available for use by other enterprises.
An enterprise ecosystem can participate in more than one wider ecosystem. For this reason a wider ecosystem does not have to involve all of the services of each of its enterprises or all parts of their enterprise ecosystems – only those parts that are relevant to the purpose of the wider ecosystem.
The Open Platform 3.0 standard is concerned with scenarios where new and emerging technology trends are in use (e.g., IoT devices providing data used by a data analytics service). The services provided by these technologies may involve multiple providers. An example scenario is described in Appendix B.
Participation
An enterprise typically belongs to more than one ecosystem, if only because it delivers more than one type of service. This in itself is a reason that an enterprise’s strategic relationship to any one ecosystem may change. In some cases an ecosystem may consist exclusively of enterprises that have an agreed common goal. In general, however, each enterprise has its own interests in the ecosystem, which therefore determine the extent and scope of its commitment to the ecosystem as a whole.
In the biological world a common example of an ecosystem is a pond. All of the participants have an interest in the continued health of the ecosystem. Some of them, however, are in a position to leave the pond (think frogs or birds) for another that offers better prospects. If all the frogs leave the pond, the ecosystem will change drastically – but to attempt to predict the result would be to trivialize the way ecosystems work. The ecosystem will figure out how to compensate or it won’t and will die or totally transform.
It is the same in a business ecosystem. Every participating enterprise has to be concerned about the health of the whole thing but has its own level of commitment and options. Enterprises are human organizations and are therefore capable of reasoning in advance about these things. That allows them to take into consideration the possible behavior of types of participant, of whose concrete existence they may not be aware.
Taking the general case, we can say that, by defining a business ecosystem, we have identified a group of participants (organizations, individuals, things), whose interactions are the scope of the ecosystem. All the participants have an interest in the health of the system but their concept of value within and commitment to the ecosystem and their specific dependencies vary from one participant to the next. Each participant, therefore, has to construct its own view of all these factors (functional and non-functional), the degree of uncertainty associated with them, and its own risk and mitigation strategy in that context.
Service Catalogs
The service catalog is central to relationships between parties in such an ecosystem. The contractual, on-demand nature of service aggregation requires on-demand contracts, whether by system or human users. One enterprise’s catalog will include and/or be dependent on services provided by other enterprises. Each party has its own catalog and the combination of these catalogs is where the whole ecosystem works.
This means that all aspects of the enterprise ecosystem – see Enterprise Ecosystem Reference Model – that are relevant to the service under consideration are dependent on parts of the service delivered by other enterprises participating in the business ecosystem.
Dependencies
A dependency may be indirect. For example, consider three enterprises A, B, and C, where Enterprise A offers a business analytics service, which is used by Enterprise B, and draws data from a data aggregation service provided by Enterprise C. An element of enterprise operations offered by Enterprise A is dependent on one offered by Enterprise C (which may or may not be covered by some form of contract or SLA).
The ability of any enterprise to deliver according to expectations depends on factors such as resource availability and cost, applicable laws and regulations, and the enterprise’s strategy, all of which are liable to change. Enterprise A is indirectly dependent on these factors as they affect Enterprise C. The degree of risk associated with this dependency will be determined by the nature of the relationship between the parties, which may be a supplier/consumer contract, a partnership, or simply a usage relationship (e.g., using a public service’s API).
Enterprise B is a consumer of Enterprise A’s service and is therefore also dependent on the service of Enterprise C. Enterprise B has no direct relationship with Enterprise C but is dependent on the quality and reliability of its service. It is in general advisable to obtain as much information as possible about a consumed service and the conditions affecting its delivery. Where such information is not available, Enterprise B may be able to impose (auditable) contractual obligations on the use of third parties. In any event it has to develop a strategy to determine its risk appetite and deal with a level of uncertainty.