Проблематика Манифеста
В Манифесте Маккомб заявляет о зависимости многих организаций от приложений. Годами компании «вырабатывали привычку» хранить информацию в базах данных бизнес-приложений. Как итог, компании имеют разрозненные массивы информации, и реализация интеграционных решений в этой ситуации требует огромных усилий и финансовых вложений.
Поставив в центр системы корпоративные данные, компании перестанут быть зависимыми от прикладного ПО и его разработчиков. Появится возможность включать в систему предприятия любые новые приложения и исключать старые.
Из Манифеста
Мы раскрыли основную причину беспорядка в информационных системах крупных учреждений. Это ориентация на приложения, которая придает ПО приоритет над данными. Выход состоит в том, чтобы перевернуть ситуацию с ног на голову. Данные – это центр вселенной, приложения эфемерны.
Модель-ориентированная архитектура
В последнее время много внимания в публикациях отводится теме архитектуры и разработке
на основе моделей MDA (Model Driven Architecture) и MDD или MDSD (Model Driven Software
Development). В отечественной практике устоявшихся терминов еще не возникло, поэтому
я буду называть их МОА (модель–ориентированная архитектура) и МУР (модель–управляемая
разработка). Не вдаваясь в подробности этих направлений, выделим только ключевые
моменты.
Основная цель МОА — минимизация затрат, связанных с привязкой к конкретным системным
платформам и программным инфраструктурам. Для этого вводятся вышестоящие уровни
описаний программной системы и предметной области, на основе которых в идеале решается
или облегчается задача генерации программного кода, настроек, параметров и т.п.
для различных платформ.
Классический и относительно простой пример из этой серии, который используется
уже давно, — моделирование баз данных. На основе одной концептуальной модели данных
вы можете поддерживать несколько связанных с ней физических моделей для различных
СУБД.
С появлением UML (Unified Modeling Language — унифицированный язык моделирования)
и поддерживающих его инструментов появилась возможность работать по аналогичной
схеме в терминах объектов. При этом сам UML имеет самый низкий уровень абстракции,
это сырье для ваших моделей, а собственно МОА начинается, когда вы создаете свои
стереотипы, параметры и настройки и определяете правила генерации кода и данных
для нижестоящего уровня.
По-видимому, наиболее мощной и высокоуровневой практической реализацией идей
MDA на сегодня является инструментарий ARIS Toolset, предназначенный для моделирования
информационных систем управления предприятием.
Направление МУР возникло как частное решение в ответ на недостатки классической
«водопадной» методологии разработки, зачастую обнаруживающей неприемлемо долгий
цикл внесения изменений. МУР укорачивает цикл от внесения изменения в модель до
получения скомпилированного продукта.
Основные стратегии применения МОА для приложений баз данных
Прежде чем рассматривать стратегии, договоримся об используемых терминах. Названия
направлений носят весьма условный характер (терминология еще не сформировалась)
и определяются акцентом, отправной точкой моделирования, выбранной в соответствии
с исходными условиями. Термины «физическая модель данных» (ФМД) и «объектно-ориентированные
модели» (ООМ) используются в понятии инструмента моделирования Sybase PowerDesigner
(15-дневную версию вы можете загрузить с сайта производителя). ФМД подразумевает
описание структур и запросов к данным с учетом специфики конкретных СУБД, а ООМ
— совокупность диаграмм, использующих нотацию UML.
Объектно-центричная стратегия. Ядром разработки являются ООМ,
в минимальном случае — диаграмма классов. Все структурные изменения вносятся на
уровне ООМ, и из нее же генерируется ФМД. В рамках этой стратегии с наименьшими
затратами обеспечивается независимость от типа СУБД.
Эта стратегия рекомендуется для новых проектов, не требующих привязки к существующим
БД, или если БД находится под полным контролем создаваемого приложения, т.е. нет
необходимости сохранять совместимость с другими приложениями.
Датацентричная стратегия. Ядром разработки является ФМД,
как правило восстановленная (reverse engineering) из существующей БД. Все структурные
изменения вносятся на уровне ФМД, и ООМ (диаграмма классов) также восстанавливается
по ФМД или синхронизируется с ней.
Эта стратегия необходима, если вы создаете приложение, работающее с уже существующими
БД, менять структуру которых вы можете только в очень ограниченных пределах, как
правило, путем добавления новых таблиц и атрибутов.
На схемах, приведенных на рис. 1 и 2, показаны процессы разработки, характерные
для каждой из стратегий. Выделенный овал — ключевая модель, которая является центром
внесения изменений.
В рамках статьи мы рассмотрим только вторую, датацентричную схему разработки.
Во-первых, она чаще встречается, а во-вторых, более сложна по количеству преобразований
между моделями. Кроме того, поняв суть, вы сможете самостоятельно реализовать объектно-центричную
схему, адаптировав ту же самую технологию.
Шаг 1. Для начала разберемся…
Что же на самом деле означает уход с рынка SAP и Oracle? Это всего лишь указывает на то, что те бизнесы, ключевые процессы которых были завязаны на зарубежном ПО, вынуждены будут еще какое-то время его использовать, но без технической поддержки от вендора и регулярных обновлений.
Доля рынка Oracle, SAP и Microsoft увеличиваться в России уже не будет — это факт. Но бизнес-то развивается, потребности его растут, то есть, нужен будет новый стек, с которым будут работать специалисты — разработчики, аналитики и тестировщики.
Следовательно, через несколько лет найти разработчиков для поддержки этих зарубежных решений будет очень сложно и дорого. Никто не захочет работать с устаревшим продуктом. Это примерно, как сейчас, найти программиста для 1С «семерки».
Получается, что именно сегодня делать многомиллионные проекты по импортозамещению, когда налицо ограничение по времени, высокий ажиотаж и ценники, нецелесообразно. Замена условного SAP на 1С — это неподъемная история на годы. При этом все on-premise продукты как работали, так и работают, даже зарубежные.
Потребность в датацентрической архитектуре
Моделецентрическое применение ML1. Потребность в высокоуровневой кастомизации2
Важность больших массивов данныхЭндрю Ынсчитает, что датацентрическое ML даёт бОльшую отдачу и продвигает идею революции в сообществе в сторону датацентричности.Он приводит пример задачи обнаружения дефектов в стали, в котором моделецентрическая методика не смогла повысить точность модели, а датацентрическая методика увеличила точность на 16%.
Датацентрический способ применения ML
Внедрение датацентрической инфраструктуры
4. Контроль версий данных
а) Neptune
контроля версий данных при помощи Neptune
- Отслеживать версию массива данных в прогонах машинного обучения при помощи .
- Запрашивать версию массива данных из предыдущих прогонов, чтобы гарантировать, что вы выполняете обучение на одной версии массива данных.
- Упорядочивать метаданные версий массивов данных в Neptune UI.
Пример сравнения массивов данных в Neptune UIпримеры кода
б) Weights & Biases
- Использовать артефакты для контроля версий массивов данных и моделей, а также для отслеживания зависимостей и результатов в конвейерах машинного обучения.
- Хранить полные массивы данных непосредственно в артефактах или использовать ссылки на артефакты для указания на данные в других системах наподобие S3, GCP, или на локальной машине.
примеры кода
в)
- Записывать версии данных и моделей в коммиты Git, параллельно с хранением их на машинах пользователей или в облачном хранилище.
- Переключаться между различным содержимым данных.
- Создавать метафайлы с описанием того, какие массивы данных и артефакты ML нужно отслеживать.
примеры кода
- Повышает точность; использование данных в качестве стратегического ресурса гарантирует более точные оценки, наблюдения и решения.
- Устраняет необходимость сложных преобразований данных.
- Уменьшает количество ошибок и несоответствий в данных.
- Предоставляет важную информацию о внутренних и внешних трендах, позволяющую принимать более оптимальные решения.
- Снижает расходы.
- Упрощает доступ к данным для руководства.
- Снижает избыточность данных.
- Повышает качество и надёжность данных.
Шаг 3. Выбираем варианты
Вариант А
Ничего не менять и продолжать жить на необновляемых монолитах. Но тогда вскоре процессы ваши встанут, разработчиков под них вы не найдете или стоить они будут заоблачно дорого. В конце концов — это путь в никуда.
Вариант Б-1
Одно из самых простых и актуальных в настоящий момент решений — это построение собственной API-центричной архитектуры. У этого подхода есть ряд преимуществ. Прежде всего, вам необязательно на этом этапе отказываться от использования SAP или Oracle.
Пока они работают, можно выстроить свою архитектуру, основываясь на лучших DevOps-практиках, а впоследствии вообще отказаться от иностранного ПО и выстроить свою собственную экосистему.
Вариант Б-2
Если же экосистема не ваша траектория развития, то можно будет плавно перейти с иностранного ПО на отечественное, без потерь по времени и качеству.
Кейс
Заменить Oracle на PostgreSQL сегодня можно, как и SAP на 1С ERP. Вопрос не в этом, а в том, как обеспечить связность этих систем с остальным IT-контуром и в какую сторону его развивать?
У нас богатый опыт в перестраивании существующих связей и замене монолитной структуры на API-центричную с помощью low-code системы. Это в десятки раз быстрее, чем переход с монолита на монолит.
Мы предлагаем сменить акцент на методику, которая позволит обезопасить бизнес в будущем — на API-центричную архитектуру и блок API-менеджмента с middleware в виде low-code платформы.
Чтобы не было рисков и процессы происходили бесшовно, перевести на API все процессы, которые можно, создать каталоги API, сделать BFF, композитные API и обеспечить API-оркестрацию нужным системам. И все это можно реализовать с помощью разработчиков уровня junior/middle и системных аналитиков, если использовать low-code платформу.
На примере аналогичной работы с высоконагруженными проектами мы наблюдаем ускорение time-to-market в 2,5-4 раза, при этом скорость локализации и исправления инцидентов вырастает в 5 раз, а емкость продуктовых IT-команд — в 2 раза.
Добавьте к этому 25 млрд. бизнес-транзакций в месяц и около 8 тыс. транзакций в секунду — на выходе вы получите то, что кардинально изменит ваш бизнес к лучшему.
В целом, импортозамещение сейчас имеет смысл только для зарубежных SaaS-решений, которые находятся в облаке, и доступ к ним был заблокирован для российских пользователей.
Для компаний, на чьи серверы установлены on-Premise продукты, мы видим оптимальное решение — строить свою экосистему, чтобы в техническом плане больше не зависеть ни от политики, ни от экономики, ни от каких-либо иных форс-мажоров.
Шаг 2. Что менять, а что пока нет?
Если что-то и имеет смысл заменять прямо сейчас, так это зарубежные SaaS-сервисы, так как доступ к ним полностью отключили, и вера в них умерла. Концепция облачных сервисов изначально несла в себе риски для IT-инфраструктуры, так как предоставленное по подписке ПО в любой момент может быть заблокировано.
Теперь это понимает не только российский энтерпрайз, но и бизнес в других странах. За границей вполне себе осознают, что они, также как и Россия, могут оказаться в похожей ситуации.
Поэтому для технических директоров и руководителей IT-подразделений крупного бизнеса сейчас самое время сказать себе «Стоп!» и посмотреть на глобальную картину.
Перейти на отечественное ПО? Да, можно, но одного волевого решения руководства «теперь вы работаете в другой программе» мало. Необходимо обеспечить плавный и бесшовный переход с условного SAP на условный 1С. Это займет не один год и потребует огромного количества финансов и человеческих ресурсов.
Размеры затрат и сроки в этом случае нельзя спрогнозировать. И самое главное, после такого перехода вы подсадите свой бизнес на ту же иглу, только уже отечественного производства.
Сложность в том, что эти системы взаимодействуют с окружающим IT-ландшафтом: выгрузки на сайт, мобильные приложения, чат-боты, государственные сервисы и т. д. Таких взаимосвязей и сервисов, которые от них питаются очень много и процессы завязаны на формат, периодичность и особенность этих систем.
Ключевые принципы Манифеста
В Манифесте не представлено конкретных решений по преобразованию IT-ландшафта. Каждая компания выбирает свой путь перехода к дата-центричной архитектуре. Тем не менее, в Манифесте представлены принципы, которые позволят встать на путь извлечения выгоды из корпоративных данных. Это не технические советы, но основы нового мышления.
Из Манифеста
- Данные являются важнейшим активом любой организации
- Большинство современных систем ориентировано на приложения
- Хранение данных в проприетарном ПО – это ошибка
- Дороговизна и сложность корпоративных систем связана с отношением приложений к данным
- Мы понимаем, что ориентация на приложения приносит деньги
- Но дата-центричный подход принесёт больше
Если вы хотите узнать больше о дата-центричном подходе в управлении данными, начните изучение с трудов Дэйва Маккомба The Data-Centric Revolution: Restoring Sanity to Enterprise Information Systems и Software Wasteland: How the Application-Centric Mindset is Hobbling our Enterprises.
И конечно, познакомьтесь с The Data-Centric Manifesto.
Подробнее о требованиях к платформе для реализации дата-центричной архитектуры, ее преимуществах, отличиях от концепций Data Lake и Corporate Data Cloud можно прочитать в нашей статье.
Платформа АрхиГраф предоставляет весь необходимый инструментарий и обладает всеми характеристиками, необходимыми для реализации дата-центричной ИТ-архитектуры предприятия. Создание такой архитектуры является решающим шагом на пути цифровизации предприятия, перехода к управлению, основанному на данных.
Чему отдавать приоритет: количеству или качеству данных?
Качество данных
Различные подходы к созданию ограничивающих прямоугольниковПоэтому необходимо тщательно составлять инструкции по аннотированию, чтобы инженеры ML и дата-саентисты размечали данные согласованно.Согласно исследованию, приблизительно 3,4% сэмплов в часто используемых массивах данных имеют ошибочные метки, и ошибок больше в больших моделях.
Важность согласованности в малых массивах данных | ИсточникЭндрю ЫнТочность моделей зависит от качества данных;
Сколько данных достаточно?
Yolov5
- Минимум 1,5 тысяч изображений на каждый класс.
- Минимум 10 тысяч экземпляров (размеченных объектов) на класс в сумме.
Зацикливание
Зачем вообще нужно управлять внесением изменений? На первый взгляд все просто:
поставили задачу, спроектировали предметную область, реализовали систему, запустили
в работу…
Во-первых, задача может оказаться сложной, а предметная область неизвестной.
Во-вторых, срок создания даже не очень сложной системы исчисляется месяцами, а за
это время требования могут измениться.
Классическая схема типа «водопад» подразумевает последовательное прохождение
стадий: от анализа до приемочных испытаний. Упор делается на глубокий анализ предметной
области, создание моделей, тщательную проработку архитектур. Соответственно эта
стадия является наиболее ответственной и длительной. Весьма вероятно, что в это
время у заказчика возникнет желание изменить или уточнить свои требования. Тогда
процесс возвращается на исходную точку и повторяется. Так как требования в условиях
динамичного окружения бизнеса могут меняться часто, то «водопад» просто зацикливается
на первой стадии.
В противоположность «водопаду» создатели методологии экстремального программирования
решили проблему радикально: в явном виде исключили из процесса стадию анализа. Раз
зацикливается, то в топку ее. Вместо тщательного и долгого анализа со слов заказчика
пишутся краткие истории, описывающие предполагаемое применение системы, и команда
разработчиков сразу же приступает к реализации. Поскольку при таком децентрализованном
подходе неизбежно дублирование реализаций, эту проблему предлагается решать факторизацией
(реструктуризацией, рефакторингом). В идеале эволюционным путем должно получиться
оптимальное решение, и притом без привлечения аналитиков и архитекторов. Но если
система достаточно сложная, то затраты на факторизацию с каждой итерацией растут.
В один прекрасный день наступает «момент истины», когда по требуемым усилиям дальнейшая
факторизация становится сравнима с полной переделкой системы. Вот таким образом
agile-методологии типа экстремального программирования тоже приводят к зацикливанию,
но на стадии реализации.
