Часто во время обсуждения e-gov инициатив, мы скатываемся в обсуждение конкретных сервисов или конкретных технологий, будь то ProZorro, Machine learning или Blockchain. И хотя всё это очень классно и определённо двигает нас в правильном направлении, есть одно но...
Мы можем сделать одну супер-пупер глобальную и монолитную ситему, которая будет уметь предоставлять все услуги государства и иметь доступ ко всем необходимым данным. И по-началу это будет даже работать.
Но любой разработчик вам скажет, что в какой-то момент развивать такой монолит будет практически невозможно. При необходимости вносить какие-либо изменения, мы будем бояться сломать какой-то другой сервис и даже, если автоматическое тестирование нас от этого спасёт, количество внутренних связей этой системы будет расти экспоненциально, а значит и стоимость развития/поддержки тоже.
С другой стороны, мы можем каждый сервис сделать полностью независимым от других. И не испытвать подобных проблем роста.
Но тогда о хорошей кросс-сервисной интеграции можно забыть. Ведь чем более сервис независим, тем меньше он знает о других. А, если он о них не знает, то и нормально интегрироваться с ними не может.
Опытные инженеры знают, что оба случая после анализа и переработки чаще всего приобретают следующий вид:
- Все сервисы максимально децентрализованы и независимы
- Но есть единый протокол общения для всех
- (*опционально) есть единая точка входа (или БД), которая в определённом смысле отвечает за интеграцию сервисов друг с другом
ИМХО предложенный здесь формальный язык является идеальным кандидатом для того, что бы быть этим связующим звеном (пункты 2 и 3) для всеx сервисов e-gov.