The post has been translated automatically. Original language: Russian
One virtual operator launched an SMS service for its subscribers on a partner's network, whose radio network and SMS infrastructure it had fully leased at the start. From the outside, it looked like one technical add-on over the finished platform. Inside, two teams worked on the task in parallel, and they had in common, in fact, only the name of the project: they solved completely different problems in terms of content.
The first team was doing what looked like the main task. By that time, the existing SMS center was already serving the main traffic of the host operator, and a separate circuit had to be built into it for subscribers of the new operator so that their messages would be recognized, routed and charged according to their own rules and would not affect the main traffic in any way. The platform should have remained alone, and the reception and delivery of messages for each operator should have been independent of each other: what was happening at one should not have reflected on the other. The team has fine-tuned the signal stack and the Diameter protocol, the logic for determining the recipient's network, taking into account the portability of the number, the addressing parameters of the new operator circuit and the exchange with the billing system of the host operator, as well as the business logic of anti-spam and lists, separate for each operator. Some of these developments turned out to be versatile enough to be applied later in other similar tasks.
The second team dealt with a part of the task that technically looked much more modest: at the junction of the two infrastructures, there was a discrepancy in the standards of signaling interaction, and it had to be smoothed out by a separate interface component: a working moment of those that occur in almost any integration and are solved along the way. However, it was necessary to work on it inside the protected contour of the customer, and the usual remote access was not enough for this. It was important for the customer to control who exactly entered his technical perimeter and from which device, so the engineer who handled this part was officially registered with the customer's staff, signed an NDA and received a corporate laptop through which he conducted all the work inside someone else's infrastructure. As the requirements for the environment were agreed upon, the task was reassembled several times. Now everything works without constant intervention, connection is required only when changing the network configuration or analyzing incidents, and the laptop remains in the office in this case.
The subscriber of the new operator does not see any of this: neither the reconfiguration of the SMS center, nor the exchange with billing, nor the conversion of signaling protocols, he just gets a working service. But the history of the two teams shows quite well where complexity actually lives in integration projects. It is rarely evenly spread over the code. Usually there is a substantive part that can be planned and evaluated in man-hours, and there is an organizational part that is tied to trust and access to someone else's infrastructure, which by the same standards is almost impossible to evaluate. It is the second part that is less likely to be included in the estimate of deadlines at the start of the project, and it is she who most often moves these deadlines later.
At SC.Soft, we try to include this in the assessment in advance: if a project has someone else's secure perimeter, the plan includes not only time for code, but also time for access clearance, architecture coordination, and more than one iteration of test deployment.
Один виртуальный оператор запустил SMS-сервис для своих абонентов на сети партнёра, чью радиосеть и SMS-инфраструктуру он на старте полностью арендовал. Со стороны это выглядело как одна техническая надстройка над готовой платформой. Внутри над задачей параллельно работали две команды, и общим у них было, по сути, только название проекта: содержательно они решали совершенно разные проблемы.
Первая команда занималась тем, что и выглядело основной задачей. Существующий SMS-центр к тому моменту уже обслуживал основной трафик оператора-хоста, и в него нужно было встроить отдельный контур для абонентов нового оператора, чтобы их сообщения распознавались, маршрутизировались и тарифицировались по собственным правилам и никак не задевали при этом основной трафик. Платформа должна была остаться одна, а приём и доставка сообщений для каждого оператора должны были идти независимо друг от друга: происходящее у одного не должно было отражаться на другом. Команда донастроила сигнальный стек и протокол Diameter, логику определения сети получателя с учётом переносимости номера, параметры адресации нового операторского контура и обмен с системой тарификации оператора-хоста, а заодно бизнес-логику защиты от спама и списков, отдельную для каждого оператора. Часть этих наработок получилась достаточно универсальной, чтобы позже применить её и в других похожих задачах.
Вторая команда занималась частью задачи, которая технически выглядела куда скромнее: на стыке двух инфраструктур обнаружилось несовпадение стандартов сигнального взаимодействия, и его нужно было сгладить отдельным компонентом сопряжения: рабочий момент из тех, что встречаются почти в любой интеграции и решаются по ходу дела. Работать над ним, впрочем, нужно было внутри защищённого контура заказчика, а обычного удалённого доступа для этого оказалось недостаточно. Заказчику было важно контролировать, кто именно и с какого устройства заходит в его технический периметр, поэтому инженер, который занимался этой частью, был официально оформлен в штат заказчика, подписал NDA и получил корпоративный ноутбук, через который вёл всю работу внутри чужой инфраструктуры. По мере согласования требований к окружению задачу несколько раз пересобирали заново. Сейчас всё работает без постоянного вмешательства, подключение требуется только при изменении конфигурации сети или разборе инцидентов, а тот самый ноутбук остаётся в офисе на этот случай.
Абонент нового оператора ничего из этого не видит: ни перенастройку SMS-центра, ни обмен с биллингом, ни преобразование сигнальных протоколов, он просто получает работающий сервис. Но история двух команд неплохо показывает, где на самом деле живёт сложность в интеграционных проектах. Она редко равномерно размазана по коду. Обычно есть содержательная часть, которую можно спланировать и оценить в человеко-часах, и есть организационная часть, завязанная на доверие и доступ к чужой инфраструктуре, которую по этим же меркам оценить почти невозможно. Именно вторая часть реже попадает в оценку сроков на старте проекта, и именно она чаще всего эти сроки потом двигает.
В SC.Soft мы стараемся закладывать это в оценку заранее: если в проекте есть чужой защищённый периметр, в план идёт не только время на код, но и время на оформление доступа, согласование архитектуры и не одну итерацию тестового развёртывания.
Share
