На словах кажется, что это одно и то же. На практике — это две совершенно разные плоскости мышления.
Простой пример.
Есть пользовательская система. В ней работает пользователь. Есть агент, который помогает этому пользователю.
В систему загружаются документы. Чтобы агент мог с ними работать, документы нужно распознать — подключается внешняя система OCR.
Дальше начинается инженерная логика. Система №1 интегрируется с системой распознавания: передаётся идентификатор, создаётся внутренний ID — всё аккуратно, всё работает. Потом подключается агент. Данные из OCR складываются в Kafka с внутренним идентификатором. Агент читает сообщение и думает: отлично, у меня есть ID, значит я смогу положить результат обратно в исходную систему.
И вот здесь происходит сбой. Идентификатор, который агент получает из Kafka, не совпадает с тем идентификатором, по которому можно обратиться к API процесса в исходной системе. Формально все интеграции были спроектированы. Каждая пара систем взаимодействует корректно. Документация, конечно, средненькая, но технически всё «работает». Только процесс не работает. Потому что никто не проектировал процесс целиком.
Каждый проектировал свою интеграцию:
- система ↔ OCR
- OCR ↔ Kafka
- Kafka ↔ агент
- агент ↔ API
Но никто не проектировал сквозной поток: «Документ загружен → распознан → обработан → результат возвращён в конкретный бизнес-процесс». В результате — дополнительные трудозатраты, доработки, синхронизации, выяснение «какой именно ID это был».
И тут возникает важный вопрос. Кто вообще отвечает за проектирование сквозного процесса? Интуитивно хочется сказать: solution-архитектор. Но часто архитектор рисует высокоуровневый Vision, определяет системы и интеграционные точки — и считает задачу закрытой. А согласование идентификаторов, контекстов, состояний, жизненного цикла сущностей — «это уже детали», которые почему-то должны сами собой сложиться. Не складываются. Потому что интеграция — это про соединение интерфейсов. А процесс — это про синхронизацию смыслов. Можно идеально соединить API и при этом полностью сломать бизнес-поток. Вот здесь и проходит водораздел. Когда вы работаете в сложной системе, вы отвечаете за: — корректность технической интеграции или — за целостность процесса от начала до конца? И это не риторический вопрос. Потому что если никто не отвечает за процесс целиком, то за него потом платят все. А вы в таких историях что проектируете — интеграции или процесс?
Дискуссия