Operating services in multi-domain environments is inherently more complex than in a single domain because of the existence of multiple managed domains with various operating procedures, devices and systems in use. This increased complexity on one side and the demand to provide efficient and reliable services in such environment on the other impose the need to automate service operations processes and procedures. However, in loosely coupled federated service environments where participating domains retain absolute control over internal resources and processes, remotely operated configuration commands, which are prerequisite for automated operations, directly threaten the autonomy of the participating members. In this article, we identify key business processes and required operating support systems components unique to federated environments by analysing process flows for services jointly provided by European National Research and Education Networks. Although we conclude that the involvement of human operators in key service operations processes is inevitable, we propose a new workflow scheme and other necessary components needed to integrate domains in a way that minimizes manual intervention. The proposed scheme interconnects independently operating trouble ticket systems (TTSs) from participating domains in a federated TTS (FTTS). The proposed FTTS is not constrained just to the basic function of TTS-fault management, but it supports all key federated service operation activities like service provisioning, problem or performance management. The proposed fully decentralized federated scheme retains the main inherent capabilities of TTSs such as tracking, escalation and expiration and at the same time supports the desired federated service communication processes. federated domain is reluctant to abandon its own tools as this could incur additional transition and training costs. In that sense, we seek to leverage the existing capabilities of the already installed NREN-based TTSs in order to implement the proposed FTTS.The following minimum set of capabilities of individual TTS of the various NRENs was considered necessary for the proposed FTTS's successful implementation: (a) the possibility to create several types of TTs; (b) a customizable TT data model; (c) a customizable TT life cycle (workflow) with custom states and post-functions; (d) external communication via e-mail that can trigger a TT creation or status change; and (e) the possibility to define user-defined templates for e-mail communication. All these capabilities are regularly found in most of the open-source and commercial TTSs that are in use nowadays.The implementation of the proposed FTTS incorporates the following stages: (a) TT data model design; (b) specification of the communication between domain TTSs and necessary supporting tools; (c) workflow definition; and finally (d) the implementation and component's selection. These stages are described in the following sections.
Proposed federated trouble ticket data modelOur federated TT data mod...
