Войти
Работаем: пн–пт 9:00–18:00Начать диагностику
Внутренний сервис может быть критичным и при этом не иметь публичного API. Может работать на старом стеке. Может использовать общую базу с другим приложением. Может содержать бизнес-логику, которую никто уже полностью не описывает. AMPE интегрирует такие системы без предположения, что их обязательно нужно сразу переписать. Сначала мы выясняем, какую функцию они реально выполняют, от чего зависят и какие границы можно сделать безопасными.
Начать диагностикуПриложение может формально принадлежать компании.
Поэтому первое действие — не «добавить endpoint».
Первое действие — понять реальную цену изменения.
оборудованием; старой БД; конкретным разработчиком; регламентом; внешним модулем; неизменяемой интеграцией.
Иногда лучший вариант — добавить API.
Иногда — публиковать события.
Иногда — выделить read-only view.
Иногда — поставить адаптер рядом с системой.
Иногда — читать файл.
Иногда — вообще сначала вынести критическую бизнес-логику из приложения.
AMPE выбирает способ по жизненному циклу системы и риску, а не по удобству первого прототипа.
В таблице появился статус «3».
Почему именно 3?
Кто его ставит?
Что должно произойти после?
Можно ли вернуть назад?
Какие побочные действия запускаются?
Если интеграция начинает работать напрямую с данными, не понимая этой логики, технически корректная запись может создать бизнес-ошибку.
Поэтому мы восстанавливаем семантику до подключения.
Собственная система заказов должна передавать финансовый факт в ERP.
Старый производственный софт — получать задания из нового контура.
Внутренний портал — запускать процессы в CRM или BPM.
Legacy-приложение — отдавать данные в DWH.
Система на площадке — работать локально и синхронизироваться с центральным контуром.
Несколько внутренних сервисов — перестать ходить напрямую в одну общую БД.
В каждом случае проблема разная, даже если пользователь называет её одним словом «интеграция».
Два приложения читают и пишут одни таблицы.
Сначала это быстро.
AMPE не обязательно разрывает такую связь сразу.
Но если shared database уже мешает развитию, мы постепенно вводим ownership и явные контракты.
кто владеет схемой; кто имеет право менять колонку; какой сервис нарушил данные; можно ли развернуть приложения независимо.
Внутренняя система может использовать старые названия, коды и модель данных.
Новые сервисы не обязаны наследовать это навсегда.
Adapter переводит legacy-модель в современный контракт и изолирует старые особенности.
Так модернизация может идти постепенно, без требования переписать всё сразу.
интеграция может быть рациональнее замены.
AMPE отделяет технологический возраст от реальной архитектурной проблемы.
стабильна; понятно выполняет узкую функцию; редко меняется; не создаёт высокий риск —
В этот момент интеграционный слой начинает компенсировать ограничения приложения.
Это может быть допустимым переходным состоянием.
Но его важно честно назвать переходным, а не превращать в постоянную архитектуру.
новой таблицей рядом; скриптом; ручной выгрузкой; отдельным cron; ещё одним Excel.
«У нас все свои» не защищает от breaking changes.
Команды меняются.
Сервисы выпускаются независимо.
Зависимостей становится больше.
Иначе внутренняя интеграция со временем становится самой хрупкой.
явная схема; семантика; версионирование; правила ошибок; идемпотентность; ownership.
Для производства, склада, площадки или объекта связь с центральным контуром может быть нестабильной.
AMPE проектирует автономность как часть процесса, а не как аварийный костыль.
что разрешено делать offline; какие данные кэшируются; как накапливаются события; как разрешаются конфликты после восстановления связи.
Мы сначала определяем роль внутренней системы.
Потом её данные и бизнес-границы.
Далее — допустимую точку интеграции.
При необходимости ставим adapter или middleware.
Изолируем legacy-особенности.
Добавляем наблюдаемость, retry и reconciliation.
И только после этого решаем, должна система остаться, постепенно измениться или быть заменена.
Критичные внутренние приложения можно подключать без опасного вмешательства в их ядро.
Legacy меньше распространяет свои особенности на новые системы.
Shared database постепенно перестаёт быть неявным API.
Внутренние контракты становятся понятными.
Модернизацию можно проводить поэтапно.
И главное — компания перестаёт выбирать между двумя крайностями: «ничего не трогать» и «переписать всё с нуля».
Первый шаг
Описать: что она делает; кто от неё зависит; какие данные из неё нужны; что сегодня переносится вручную; какие изменения особенно рискованны. Этого достаточно, чтобы найти первую безопасную интеграционную границу.