Eem bm questions
5.1 Questions of Key Importance for the Infrastructure Implementation An infrastructure for an inclusive ecosystem has three different types of ecosystem that have to be related to each other. They are: the business ecosystem, the digital service ecosystem and the software ecosystem.
Figure 9: Components of an Ecosystem
The business ecosystem is a dynamic structure of organizations that work together in a specific core business, in this case in the delivering of services for disabled individuals, creating value in a network of actors. The ecosystem’s actors affect, and are affected by, the creation and delivery of each other’s offerings. Thus, the business ecosystem is composed of inter-member flows of material, energy, knowledge and money. The ecosystem may emerge spontaneously due to a common interest or demand, or as a result of long-term strategic planning. The members share the common ecosystem regulation but are able to act independently, and join and leave the ecosystem freely, since there is no dependency between ecosystem members. The digital service ecosystem is a socio-technical complex system that enables service providers to reach shared goals and gain added value by utilizing the services of other members in the ecosystem. Digital service ecosystem can be characterized for being an open, loosely coupled, domain-clustered, demand-driven, self-organizing agents’ environment, in which each species (human, economic species and digital species, i.e. computer, software and application) is proactive and responsive for its own benefit or profit. The product of a digital service ecosystem is a digital service that is entirely automated and that can be anything that can be delivered through an information infrastructure, e.g. web, mobile devices or any other forms of delivery. The members share the service taxonomy and service descriptions that can be categorized, for example, by domain, purpose or technology. The software ecosystem has some common elements with digital service ecosystems, such as self-regulation, networked character and shared value. However, the definition of a software ecosystem suggests that in general there will be some technology underpinning the ecosystem, whereas in a digital service ecosystem the members are not bound to a shared development platform or technology. Business and digital service ecosystems can be created dynamically, whereas in software ecosystems, a common platform is required to be developed first. A software ecosystem can be a part of a digital service ecosystem, but in that case the software must be provided as a service to the ecosystem. In a software ecosystem the focus is on technical, syntactic and semantic interoperability and interactions between systems and humans, and there is an increased dependency between ecosystem members. Inclusive software ecosystems are often based multi-sided markets principles and characterized by a special type of network externality (a sort or quality parameter) that depends on consumption of the same good or service by several agents (individuals, providers, or organizations) David (1985), Katz and Shapiro (1985), Farrell and Saloner (1985). This externality, however, does not depend on consumption of agents in the same class (for example, consumers of the same product), but on consumption of different, but “compatible”, agents on an opposite market side. For example, in joining an inclusive service ecosystem as P4 all, at the moment to make the decision to use the software ecosystem, a buyer will take into account the number of potential sellers using the same software, in addition to the price of the service or to the business model used. The importance of service innovation for people with disabilities has become a key issue due to dynamicity in customer demand, faster time-to-market, increased competition and the possibilities of co-creation in value networks using external ideas often called as open innovations that support and ensure the inclusion of all Europeans. Further, the possibility to innovate services either outside or inside the ecosystem require cross- domain engineering an open data ecosystem that freely exploits the available data. This creates the possibility to open internal data for sharing service ideas but at the same time use the external knowledge and innovation components for actors and allows external parties to use its knowledge in the development of new services. Figure 10: An Inclusive Ecosystem
An inclusive ecosystem should be able to describe the capability model that defines the properties of the ecosystem, and how these are implemented using the ecosystem services that the ecosystem infrastructure provides. The capabilities define the purpose of the ecosystem, its ability to perform actions and the rules of how to operate in the ecosystem. The capabilities define the governance activities and regulation processes for the ecosystem for directing, monitoring and managing the ecosystem. These include, for example, how a trusted collaboration can be established between members, what the interaction rules are, how to join and leave the ecosystem, and how to described and deliver services. In addition, the ecosystem capabilities define how the knowledge is managed. As a digital inclusive ecosystem enables members to utilize the methods and technologies that best suit their own needs, two main elements are required to be defined and provided by the ecosystem to engineer services in an ecosystem: They are: The ecosystem members. That can be defined to include service providers, service brokers, service consumers and infrastructure providers. Service consumers use the services and define the usage goals for the services, i.e. tasks that need support. They may also report on problems and failures in the service usage and provide feedback for the service validation. Service providers are independent members that provide digital services to be used by other ecosystem members or consumers. Service brokers promote the services, enable service delivery and match the demand with the best available services. Infrastructure providers provide services that implement the purpose and capabilities of the ecosystem, such as establishing, modifying, monitoring and terminating collaborations, and operations for joining and leaving collaborations. The ecosystem infrastructure that is required to make services interoperable, available, and easily consumed and thus manage all service ecosystem operations. Infrastructure is further expected to implement ecosystem capabilities, supporting the utilization of core competencies and core assets, flexible business networking, and efficient business decision making. The infrastructure also includes the taxonomy and shared descriptions of services (categorized by domain, purpose and technology etc.). The infrastructure provides the following models and assets: The ecosystem capabilities that described the capability model that defined the properties of the ecosystem and how they are implemented. The capabilities define the purpose of the ecosystem its ability to perform actions and the ruled of how to operate in the ecosystem. The capabilities define also the activities and regulations, and processes for the ecosystem for directing monitoring and managing the ecosystem. This include for example how trusted collaboration can be established between members, interaction rules and describe the deliver services. Ecosystem infrastructure supports the utilization of core competencies and core assets flexible business networking and efficient business decision making. The infrastructure also includes the taxonomy and shares description of services (categorized by domain purpose and technology. The ecosystem infrastructure has, further to be supported by the domain model and the knowledge management model. • The domain model describes the concepts of the domain and the relationships between those concepts. The domain model can be used for configuring and adapting service artifacts for use in other domains. Thus, it supports evolution of the service ecosystem. • Knowledge management model enables reuse of the existing knowledge on the business, and design practices and existing assets in the development of new service, maximizing semantic interoperability and alignment among ecosystem members, services and technologies. For example, quality ontologies define the concepts, relations, rules and their instances, which comprise the relevant knowledge of a topic and assists in reaching quality requirements, and quality-driven design methods enable to achieve the quality requirements in the architecture. The knowledge management model requires a knowledge repository unit for storage of the collaboration models, service descriptions and ontologies of service types to support interoperability validation and to guarantee the effectiveness of the service ecosystem by maximizing semantic interoperability and alignment among ecosystem members, services and technologies.
5.1.1 Digital services In a digital service ecosystem, digital services are provided by independent ecosystem members, where they provide additional value for both service consumers and other service providers. Service providers do not necessarily provide a complete service for consumers but can just provide part of a composite service. Service level agreements (SLAs) are negotiated between the atomic service providers and the composite service provider, describing the agreed-upon terms with respect to quality of service and other related concerns. Infrastructures for inclusive ecosystems that support services are, however, responsible for providing tool support for the activities of the service engineering, e.g. for using quality ontologies in all development phases (design, implementation, and testing). In addition, support services assist its members in value creation, for example, by contract making, finding partners, services, and/or markets, and analyzing business model. The infrastructure should also provide collaboration support services for ecosystem members, e.g. for communication and document sharing. The ecosystem should be aware of the quality of the services in the ecosystem’s service registry; therefore, the ecosystem should also include support services for run-time quality monitoring and analysis of services. Furthermore, the service registry should provide feedback mechanisms for users to provide feedback about the service, thus supporting requirements change and evolution. An inclusive ecosystem needs to constantly perform a Service requirements analysis to determine the consistency and completeness of requirements, and also the priority of requirements. The purpose is to analyze the capabilities and constraints of the existing services, different potential technologies for service creation and the contribution of the service to the different business cases defined in the earlier phase. The starting point here is the existing service architecture and/or description of services, or a sketch of new service architecture. A candidate service is identified during service requirement identification and business analysis are listed and checked with partners. The similar services are merged and those with no business potential are rejected. The taxonomy and shared descriptions of services provided by ecosystem infrastructure enables to categorize services by technology, domain and purpose. For each service, the requirements are analyzed, and combined if necessary. The trade-off analysis is performed for conflicting requirements according to their importance and the results of the business analysis. Also, quality requirements are prioritized based on their importance to stakeholders and as a result of the trade-off analysis. Further, Service requirements negotiation is needed to communicate the service requirements to the business and technical stakeholders involved in service development and agree the service requirement specification with the ecosystem members. This means active collaboration among the members of the digital service ecosystem by exploiting the ecosystem infrastructure. The starting point of this phase is the analyzed service requirements description that gives the first proposal of the balanced service requirements. E-mail and collaboration support services (e.g. document share points, co-design tools, video conferences and telecommunications) can be used for communication and negotiation between ecosystem members. 5.1.2 Constraints, threats and exceptions Since the ecosystem is dynamic, it evolves all the time as new members, services and value networks emerge. The knowledge management component should evolve too, adapting to the needs of the ecosystem. Also, new support services should emerge as and when needed. Since the requirement for innovation is continuous inside the ecosystem, this kind of new service would enable the service providers to detect easily what kind of services have demand inside the ecosystem. In addition, as the ecosystem monitors the quality of its services, it should also provide a matchmaking service for service selection to match the required quality with the provided quality. In the case of individuals with disabilities there is no embedded knowledge in design teams or in business experts about what the real needs for different groups are. For this reason, an inclusive ecosystem should be based on interactive principles and allow individuals to influence the supply and development of services using i.e. voting as a method to identify most demanded services. Voting is. However, rarely needed for design decisions, but it is also possible to be organized by using the support services developed in the ecosystem However, to ensure an effective voting process the users must have a working data connection on his/her device in order to vote. The ecosystem should in parallel offers scalable software resources for system – critical services and to solve bottle necks of the system. In addition to this, the device will need a personal account which is needed for registering with the service. Due to service evolution, special attention has to be paid to documenting the agreed design decisions, the proposals that have been discarded and the reasons behind the decisions. The ecosystem support services (automated or practical guides) assisting in negotiation among the ecosystem members has to allow participation in the service requirements specification and use via textual and graphical notations that make requirements specifications complete, understandable and useful for all ecosystem members. The requirements specification will turn in a complete description of the behavior of the services to be developed. To do this, it will be necessary to cluster the groups of services based on their usage and/or technical relations prior to a service specification . For instance, in the case of transport services it will be necessary to exchange information about the usage and effectiveness of the services offered by the government in different countries, as well as eventual complementary needs that can be delivered by the ecosystem. List of candidates services should be checked with partners, and similar services with different names and those with no business potential rejected. Service candidates can be quite heterogeneous both in scale and conceptual level. A service candidate should comprise functionalities from algorithms and functions to sub-systems consisting of several servers. In order to better grasp the overall requirements for the ecosystem, the services should be classified into a service taxonomy based on their technology position. A partner interested in providing a service candidate could then check the requirements set to it and similar services tracing their links to the case descriptions.