Frameworx implementation in telecommunication API
The speed of development of the telecommunications market forces its participants to continuously improve their business processes, reducing costs and minimizing the time to develop and launch new services on the market. The big problem in this case is building the right business models within the organization. In the process of implementing the YouMagic.Pro service, we were faced with the fact that each product specialist who began to engage in this project saw its development in its own way. Interfaces, forms changed, we rewrote the code, and all this led to errors in the service. At some point, the stated requirements already ceased to be compatible with the original architecture and we decided to see how business processes were implemented in other telecom companies. As a result of the analysis, we came to the decision to introduce the SID Frameworx reference models from TM Forum.
So, what are reference models and where did they come from.
To begin, consider the concepts of business engineering and the engineering approach. Using business engineering technology, you can create, modify and reorganize enterprises, as well as ensure the consistency of their various components: strategies, structures, business processes, information systems, etc. Business engineering, in turn, is based on an engineering approach, an important feature of which is the use of formalized knowledge adapted for reuse.
Formalized knowledge is knowledge that can be described, documented and shared with other people. They are presented in graphic form, in the form of drawings, specifications, textbooks, procedures. They can be words, numbers and objects. From the point of view of practice, reusable resources and formalized knowledge can be divided into the following categories: In the whole variety of reusable resources, we were interested in reference models for the development, implementation and operation of software for telecoms. They represent reference schemes, procedures and methods of business organization, developed on the basis of real implementation experience in various companies around the world. In this article, we will focus on the concept of Frameworx reference models for telecommunications companies.
Telecommunication and information technologies, as well as the range of services offered by communications companies, are developing and changing extremely dynamically. Now business cannot spend 1-2 years developing a service, as it was in the previous connection. Currently, the time it takes for a service to enter the market is measured in months. Together with them, the components of control information systems, as well as the business processes themselves, are in constant development. At the same time, companies quite often do not have the time to carry out full-scale design of new processes. What can we say about the development, testing and implementation of control modules that will implement new services in systems.
Another difficulty in managing business processes in telecommunication companies is that they automate interaction with customers, giving them the opportunity to independently manage the services provided in real time. Most often this happens through the web interface.
Most programmers, or just techies, will answer the question about business processes in the company: “This is a description of how a request from a support employee is transmitted to a CRM to a technical specialist.” Or give another example from the life of any company. We looked at it from the other side. Connecting a client and his work in his personal account is also a business process. There are also a large number of business processes hidden from the user. For example, unlocking when replenishing the balance; activation of discounts when ordering a specific set or volume of services. All these business processes are overwhelmingly automated in services. When the business process is automatic, then the subjects (people) are practically absent, and the code manages the objects of the business process. And since subjects are code, then he cannot make human-like decisions in the face of insufficient information. In this case, the construction of universal and effective data models for manipulating them with automatic code comes first.
In the process of designing the core of the MTT Business product, we studied the existing experience and found a solution: use informational frameworks. They describe typical structures for constructing models, data for industries or subject areas. Starting from a general description of the main objects (for us, for example, it is a client, service, tariff, etc.) and up to specific diagrams of components already described in the UML notation. They already have the best practices of the experience of specialists who have solved similar problems earlier.
Tele Management Forum (TM Forum) is a non-profit association that brings together telecommunication companies and their suppliers to write standards, guidelines and models for information technology in the telecommunications industry. The association was founded in 1988 at the initiative of British Telecom and AT&T and was first called the OSI / Network Management Forum. By the beginning of 1989, the first OSI / NM Forum protocol specification was approved, and already in 1990 the organization included 85 companies from 13 countries. In the future, TM Forum united almost all the world telecommunication companies.
The main areas of research and development of TM Forum are:
Frameworx is a development of the NGOSS concept. As already mentioned, the main task of this concept is to define standards for the business processes of telecom operators, as well as to unify the presentation formats used in data management systems and interfaces. Features of the Frameworx concept have become several factors.
1. Separation of business processes and applied technical components.
Any business process must be managed as part of a centralized infrastructure. For this, mechanisms are used that provide a sequence of actions. They are also responsible for monitoring the progress of the business process from one application to another.
2. A distributed system with non-rigid connections between its elements.
Frameworx means creating “distributed systems” with non-rigid connections between their elements. This means that instead of a single monolithic application for managing all operations of a telecommunications company, it is proposed to use a set of integrated and interacting applications.
3. General information model.
Frameworx applications should be able to exchange various kinds of data with each other. Moreover, each application must understand how any other application interprets any block of transmitted data. Such a model of work is called a general information model.
The basis of the concept is formed by cards and models of business processes. Frameworx includes the following structures:
The information model is an integral part of Frameworx and defines an approach to the description and use of data involved in the business processes of a communications company.
Information structure (SID) is a basic model and a common dictionary of all the information necessary for the implementation of business processes. Using SID reduces the complexity of maintenance, system integration, development, and design.
From the point of view of practice, the SID Framework can be represented in the form of a diagram.
The MTT Business product has a two-tier architecture:
The portal interacts with the BackEnd API via HTTP JSON RPC2.0. Given that most of the services in it involve the provision of communication services, we can say that there is a third level - the level of the telecommunication network.
When making such a decision, we also understood that in addition to one MTT Business product portal, other portals that implement similar services and business rules can be connected to the API. Our expectations were met, and a year after the launch of the MTT Business product in production, we connected two partners with similar services to the API without any significant modifications.
To implement business logic in the API, we have implemented several SID Framework domains: Product, Customer, Service, Resource. The implementation of the MTT Business service at the development stage did not require the implementation of all business entities (ABE) from these domains. This is due to the fact that, for example, the service support process is implemented in other systems and such business entities as Customer Problem, Customer SLA, Service Trouble, etc., are covered by these systems. The diagram below reflects the business entities implemented in MTT Business.
MTT Business has a private API that allows MTT partners to implement similar telecom services with its help. If you focus only on APIs, you will notice that they do not fully reflect the SID Framework. It is implemented internally and forms the core hidden from the user API. This choice was intentional - the API itself reflects the final business processes, not abstractions.
SID also contains recommendations for implementing the interaction between business entities of different domains. In our case, the main interaction is localized between products, services and resources. This is best reflected in the corresponding SID diagram.
For a visual representation of how these business entities and domains are used in MTT Business, the diagram below reflects the marketing names of the Virtual PBX service, which is one of the key ones in MTT Business.
Any choice involves a subsequent assessment of the effects to which it leads. Formalized or not. Of course, when we chose this approach, we were not sure whether it would be effective in the further development of the code, systems, services and product. And they assumed that a formal audit and assessment, albeit perhaps an internal one, would be required for themselves. However, a “life test” passed by itself. In the process of numerous improvements, the introduction of new services, the implementation of marketing campaigns, etc., the code refinement in many cases was minimal, which allowed us to implement more business ideas than was possible in services with architectural design without looking at the reference information models.
Sources used
Reference models and technologies of business engineering
Kudryavtsev DV Business Engineering Technologies: Textbook. allowance / D.V. Kudryavtsev, M.Yu. Arzumanyan, L.Yu. Grigoryev. - SPb .: Publishing house of the Polytechnic. University, 2014 .-- 427s.
Reference Models
So, what are reference models and where did they come from.
To begin, consider the concepts of business engineering and the engineering approach. Using business engineering technology, you can create, modify and reorganize enterprises, as well as ensure the consistency of their various components: strategies, structures, business processes, information systems, etc. Business engineering, in turn, is based on an engineering approach, an important feature of which is the use of formalized knowledge adapted for reuse.
Formalized knowledge is knowledge that can be described, documented and shared with other people. They are presented in graphic form, in the form of drawings, specifications, textbooks, procedures. They can be words, numbers and objects. From the point of view of practice, reusable resources and formalized knowledge can be divided into the following categories: In the whole variety of reusable resources, we were interested in reference models for the development, implementation and operation of software for telecoms. They represent reference schemes, procedures and methods of business organization, developed on the basis of real implementation experience in various companies around the world. In this article, we will focus on the concept of Frameworx reference models for telecommunications companies.
The benefits of implementing existing models over design from scratch
Telecommunication and information technologies, as well as the range of services offered by communications companies, are developing and changing extremely dynamically. Now business cannot spend 1-2 years developing a service, as it was in the previous connection. Currently, the time it takes for a service to enter the market is measured in months. Together with them, the components of control information systems, as well as the business processes themselves, are in constant development. At the same time, companies quite often do not have the time to carry out full-scale design of new processes. What can we say about the development, testing and implementation of control modules that will implement new services in systems.
Another difficulty in managing business processes in telecommunication companies is that they automate interaction with customers, giving them the opportunity to independently manage the services provided in real time. Most often this happens through the web interface.
Most programmers, or just techies, will answer the question about business processes in the company: “This is a description of how a request from a support employee is transmitted to a CRM to a technical specialist.” Or give another example from the life of any company. We looked at it from the other side. Connecting a client and his work in his personal account is also a business process. There are also a large number of business processes hidden from the user. For example, unlocking when replenishing the balance; activation of discounts when ordering a specific set or volume of services. All these business processes are overwhelmingly automated in services. When the business process is automatic, then the subjects (people) are practically absent, and the code manages the objects of the business process. And since subjects are code, then he cannot make human-like decisions in the face of insufficient information. In this case, the construction of universal and effective data models for manipulating them with automatic code comes first.
In the process of designing the core of the MTT Business product, we studied the existing experience and found a solution: use informational frameworks. They describe typical structures for constructing models, data for industries or subject areas. Starting from a general description of the main objects (for us, for example, it is a client, service, tariff, etc.) and up to specific diagrams of components already described in the UML notation. They already have the best practices of the experience of specialists who have solved similar problems earlier.
Why we chose TM Forum and Frameworx
Tele Management Forum (TM Forum) is a non-profit association that brings together telecommunication companies and their suppliers to write standards, guidelines and models for information technology in the telecommunications industry. The association was founded in 1988 at the initiative of British Telecom and AT&T and was first called the OSI / Network Management Forum. By the beginning of 1989, the first OSI / NM Forum protocol specification was approved, and already in 1990 the organization included 85 companies from 13 countries. In the future, TM Forum united almost all the world telecommunication companies.
The main areas of research and development of TM Forum are:
- Development of the concept of New Generation Operations Systems and Software (NGOSS). This is the main initiative of TM Forum. It consists in simplifying and standardizing the processes of determining, developing and implementing OSS / BSS systems in the telecommunications industry.
- Modeling and automation of processes.
- Regulation of interaction with consumers of services.
TM Forum concepts are used worldwide by information and telecommunication services market leaders.
Frameworx
Frameworx is a development of the NGOSS concept. As already mentioned, the main task of this concept is to define standards for the business processes of telecom operators, as well as to unify the presentation formats used in data management systems and interfaces. Features of the Frameworx concept have become several factors.
1. Separation of business processes and applied technical components.
Any business process must be managed as part of a centralized infrastructure. For this, mechanisms are used that provide a sequence of actions. They are also responsible for monitoring the progress of the business process from one application to another.
2. A distributed system with non-rigid connections between its elements.
Frameworx means creating “distributed systems” with non-rigid connections between their elements. This means that instead of a single monolithic application for managing all operations of a telecommunications company, it is proposed to use a set of integrated and interacting applications.
3. General information model.
Frameworx applications should be able to exchange various kinds of data with each other. Moreover, each application must understand how any other application interprets any block of transmitted data. Such a model of work is called a general information model.
The basis of the concept is formed by cards and models of business processes. Frameworx includes the following structures:
- Expanded eTOM business process map (process framework). It describes the structure of the business processes of telecommunications companies. The core element of this framework is a business task. A task can be a process element when, for example, a set of individual tasks is combined into a certain flow.
- Information model SID (information framework). Defines the approach to the description and use of data involved in the business processes of a communications company. The basic element of the framework is a logical / business entity (information object).
- TAM application map (application framework). Describes the typical structure of the components of the information environment of communication enterprises. The basic element of this framework is functionality. This is a certain set of functions that forms the smallest possible functional unit. A set of one or more functionalities forms an application.
- Integration architecture and contractual definitions of interfaces (integration framework). The basic element of the framework is a service / contract. A service is a combination of functions and information objects that are exposed by the system to interact with the environment. Service is what other applications should know about the application.
- Reference model of business metrics.
- Practical recommendations and examples of use.
SID Framework
The information model is an integral part of Frameworx and defines an approach to the description and use of data involved in the business processes of a communications company.
Information structure (SID) is a basic model and a common dictionary of all the information necessary for the implementation of business processes. Using SID reduces the complexity of maintenance, system integration, development, and design.
From the point of view of practice, the SID Framework can be represented in the form of a diagram.
How and where did we apply the SID
The MTT Business product has a two-tier architecture:
- A web portal with only the necessary logic inside.
- BackEnd API with the implementation of all business processes.
The portal interacts with the BackEnd API via HTTP JSON RPC2.0. Given that most of the services in it involve the provision of communication services, we can say that there is a third level - the level of the telecommunication network.
When making such a decision, we also understood that in addition to one MTT Business product portal, other portals that implement similar services and business rules can be connected to the API. Our expectations were met, and a year after the launch of the MTT Business product in production, we connected two partners with similar services to the API without any significant modifications.
To implement business logic in the API, we have implemented several SID Framework domains: Product, Customer, Service, Resource. The implementation of the MTT Business service at the development stage did not require the implementation of all business entities (ABE) from these domains. This is due to the fact that, for example, the service support process is implemented in other systems and such business entities as Customer Problem, Customer SLA, Service Trouble, etc., are covered by these systems. The diagram below reflects the business entities implemented in MTT Business.
MTT Business has a private API that allows MTT partners to implement similar telecom services with its help. If you focus only on APIs, you will notice that they do not fully reflect the SID Framework. It is implemented internally and forms the core hidden from the user API. This choice was intentional - the API itself reflects the final business processes, not abstractions.
SID also contains recommendations for implementing the interaction between business entities of different domains. In our case, the main interaction is localized between products, services and resources. This is best reflected in the corresponding SID diagram.
For a visual representation of how these business entities and domains are used in MTT Business, the diagram below reflects the marketing names of the Virtual PBX service, which is one of the key ones in MTT Business.
What's next?
Any choice involves a subsequent assessment of the effects to which it leads. Formalized or not. Of course, when we chose this approach, we were not sure whether it would be effective in the further development of the code, systems, services and product. And they assumed that a formal audit and assessment, albeit perhaps an internal one, would be required for themselves. However, a “life test” passed by itself. In the process of numerous improvements, the introduction of new services, the implementation of marketing campaigns, etc., the code refinement in many cases was minimal, which allowed us to implement more business ideas than was possible in services with architectural design without looking at the reference information models.
Sources used
Reference models and technologies of business engineering
Kudryavtsev DV Business Engineering Technologies: Textbook. allowance / D.V. Kudryavtsev, M.Yu. Arzumanyan, L.Yu. Grigoryev. - SPb .: Publishing house of the Polytechnic. University, 2014 .-- 427s.