Ну вот вы себе придумали кучу дополнительных условий, а на основе этого говорите, что никакая концепция не нужна. При замене системы с А на А1 очевидно, что все интеграции, касающиеся этой системы, нужно переписать. С Б на Б1 аналогично и так далее.
Так что вопрос как переписывать:
1. Как пойдёт
2. По правилам
Если внедряется кшд, то интеграции тоже переписываются. И да, само собой, что оставлять старые интеграции, добавляя новые - это бред. Вот только этого никто делать и не собирался. Так что вот именно в этой ситуации описание концепции, описание правил разработки, формирование регламентов максимально своевременно и оправдано
Давайте чуть упростим ситуацию для общего понимания.
Есть системы А, Б и В. Каждая сейчас интегрирована с каждой. Как? Хрен его знает, потому что делалось это несколько лет назад, документации нет. Доработка существующих интеграций - это сложно, потому что нет прозрачного понимания как оно должно работать, сопровождается ошибками. Поддерживается как-нибудь. Обычно по принципу работает - не трожь.
Решено, что системы А, Б и В будут заменены отдельными проектами на А1, Б1 и В1 соответственно. Это даёт кучу своих плюсов, расширение функционала и т.д.
Но помимо этого мы внедряем кшд. Здесь логика простая, кшд позволит сильно упростить дальнейшее сопровождение интеграций.
Каждую систему будет заменять своя отдельная команда внедрения, а значит и способы интеграции, которые они будут использовать на проекте, скорее всего будут отличаться. Кому-то нравится использовать сервисы интеграции, кому-то веб-сервисы, кто-то использует XML, кто-то json. У кого-то инициатором обмена будет шина, у кого-то система, кто-то отправляет квитанции о получении сообщений, кто-то считает это лишним. Думаю вы понимаете о чем я говорю, здесь вариантов много.
Если мы просто скажем этим командам "интегрируйте через шину", то они сделают как-то по-своему, а потом нам нужно будет поддерживать эти разные реализации. И поддержке на каждом этапе нужно сначала понять о какой системе/интеграции идет речь, а только потом, получив ответ как она должна работать, решать возникающие проблемы. То же самое при доработке интеграций.
Если же описать концепцию, то она ответит на все эти вопросы, а значит все реализуют одинаково. В концепции будет описано какие механизмы должны быть переиспользуемыми.
И вот сейчас, опять же для простоты есть 6 потоков. При внедрении шины потоков станет больше. Но потом их количество будет уменьшаться, точек мониторинга будет становиться меньше и после внедрения всех систем и после устранения прямых интеграций между системами их сопровождение станет сильно легче и комфортнее.
Ну да, не в чистом поле. В будущем будет реализовано несколько проектов, которые заменят старые системы на новые. То есть новые интеграции нужно разработать и поддерживать независимо от способа реализации. Интеграции не потребуют новых отделов поддержки, так что здесь точно не дороже.
А унификация подходов (использование готовых механизмов для упаковки сообщения в новый формат, заполнение заголовков единой процедурой, единый механизм передачи сообщений, единый механизм разбора сообщения, единый механизм квитирования при получении, единый способ мониторинга, который не нужно разрабатывать) сделает разработку, начиная со второй только дешевле, а не дороже
Несколько десятков систем, несколько сотен интеграционных потоков, впереди проекты по замене устаревших систем на новые. Если не написать этот документ, то каждая команда, делающая проект, выполнит интеграции по своим правилам, реализует мониторинг так, как посчитает нужным. После этого поддержка огромного зоопарка разных интеграций будет дороже. Если мы сейчас сформируем общие механизмы, которые будут использоваться в разработке новых интеграций, то уже начиная со второго проекта, разработка, касающаяся интеграций тоже станет дешевле.
Итого, если коротко:
Единый подход - проще поддерживать. Быстрее скорость реакции техподдержки на инциденты
Более быстрая поддержка = более дешевая поддержка, поскольку нужно меньше специалистов
Более дешёвая разработка за счёт переиспользования общих модулей в новых проектах и на сопровождении
Удивительно, что отрицательная, а не нулевая, но ок.
В моём случае никто из топов и не посмотрит на документ. Это документ для разработчиков, чтобы они понимали что делать, для лидов команд, чтобы могли контролировать разработчиков и для аналитиков, чтобы могли понимать "как с этой фигнёй работать".
Ради интереса зашёл на вики на страничку про esb. Она ни разу не отвечает на вопрос "а как конкретно эта штука должна работать" не говоря о том, что в компании бывают нюансы, которые меняют способ её использования, а значит какого-то единого стандарта не существует.
Поэтому могу сказать уверенно, если я не напишу этот документ, проект внедрения шины будет провален и пользы от её использования компания не увидит.
Вы очень упрощаете работу архитектора. Например сейчас я описываю документ "Концепция интеграции". Его появление связано с тем, что в компании появилась шина данных. И я именно, что широкими мазками объясняю как будет работать шина, как с ней будут работать другие системы, кто к кому будет подключаться, какие данные будут передаваться, как будет работать мониторинг и т.д.
И на этом моменте мне абсолютно плевать что за системы будут с шиной работать и какой стек технологий используется, этому документу плевать даже какая будет использоваться шина.
Очевидно, что стек любого ещё не выбранного документа я не знаю, но описать документ могу. А вот отдать его написание бизнес-аналитикам невозможно, они далеки от ит, чтобы принимать такие решения.
Ну вот вы себе придумали кучу дополнительных условий, а на основе этого говорите, что никакая концепция не нужна. При замене системы с А на А1 очевидно, что все интеграции, касающиеся этой системы, нужно переписать. С Б на Б1 аналогично и так далее.
Так что вопрос как переписывать:
1. Как пойдёт
2. По правилам
Если внедряется кшд, то интеграции тоже переписываются. И да, само собой, что оставлять старые интеграции, добавляя новые - это бред. Вот только этого никто делать и не собирался. Так что вот именно в этой ситуации описание концепции, описание правил разработки, формирование регламентов максимально своевременно и оправдано
Давайте чуть упростим ситуацию для общего понимания.
Есть системы А, Б и В. Каждая сейчас интегрирована с каждой. Как? Хрен его знает, потому что делалось это несколько лет назад, документации нет. Доработка существующих интеграций - это сложно, потому что нет прозрачного понимания как оно должно работать, сопровождается ошибками. Поддерживается как-нибудь. Обычно по принципу работает - не трожь.
Решено, что системы А, Б и В будут заменены отдельными проектами на А1, Б1 и В1 соответственно. Это даёт кучу своих плюсов, расширение функционала и т.д.
Но помимо этого мы внедряем кшд. Здесь логика простая, кшд позволит сильно упростить дальнейшее сопровождение интеграций.
Каждую систему будет заменять своя отдельная команда внедрения, а значит и способы интеграции, которые они будут использовать на проекте, скорее всего будут отличаться. Кому-то нравится использовать сервисы интеграции, кому-то веб-сервисы, кто-то использует XML, кто-то json. У кого-то инициатором обмена будет шина, у кого-то система, кто-то отправляет квитанции о получении сообщений, кто-то считает это лишним. Думаю вы понимаете о чем я говорю, здесь вариантов много.
Если мы просто скажем этим командам "интегрируйте через шину", то они сделают как-то по-своему, а потом нам нужно будет поддерживать эти разные реализации. И поддержке на каждом этапе нужно сначала понять о какой системе/интеграции идет речь, а только потом, получив ответ как она должна работать, решать возникающие проблемы. То же самое при доработке интеграций.
Если же описать концепцию, то она ответит на все эти вопросы, а значит все реализуют одинаково. В концепции будет описано какие механизмы должны быть переиспользуемыми.
И вот сейчас, опять же для простоты есть 6 потоков. При внедрении шины потоков станет больше. Но потом их количество будет уменьшаться, точек мониторинга будет становиться меньше и после внедрения всех систем и после устранения прямых интеграций между системами их сопровождение станет сильно легче и комфортнее.
Ну да, не в чистом поле. В будущем будет реализовано несколько проектов, которые заменят старые системы на новые. То есть новые интеграции нужно разработать и поддерживать независимо от способа реализации. Интеграции не потребуют новых отделов поддержки, так что здесь точно не дороже.
А унификация подходов (использование готовых механизмов для упаковки сообщения в новый формат, заполнение заголовков единой процедурой, единый механизм передачи сообщений, единый механизм разбора сообщения, единый механизм квитирования при получении, единый способ мониторинга, который не нужно разрабатывать) сделает разработку, начиная со второй только дешевле, а не дороже
Несколько десятков систем, несколько сотен интеграционных потоков, впереди проекты по замене устаревших систем на новые. Если не написать этот документ, то каждая команда, делающая проект, выполнит интеграции по своим правилам, реализует мониторинг так, как посчитает нужным. После этого поддержка огромного зоопарка разных интеграций будет дороже. Если мы сейчас сформируем общие механизмы, которые будут использоваться в разработке новых интеграций, то уже начиная со второго проекта, разработка, касающаяся интеграций тоже станет дешевле.
Итого, если коротко:
Единый подход - проще поддерживать. Быстрее скорость реакции техподдержки на инциденты
Более быстрая поддержка = более дешевая поддержка, поскольку нужно меньше специалистов
Более дешёвая разработка за счёт переиспользования общих модулей в новых проектах и на сопровождении
Удивительно, что отрицательная, а не нулевая, но ок.
В моём случае никто из топов и не посмотрит на документ. Это документ для разработчиков, чтобы они понимали что делать, для лидов команд, чтобы могли контролировать разработчиков и для аналитиков, чтобы могли понимать "как с этой фигнёй работать".
Ради интереса зашёл на вики на страничку про esb. Она ни разу не отвечает на вопрос "а как конкретно эта штука должна работать" не говоря о том, что в компании бывают нюансы, которые меняют способ её использования, а значит какого-то единого стандарта не существует.
Поэтому могу сказать уверенно, если я не напишу этот документ, проект внедрения шины будет провален и пользы от её использования компания не увидит.
Вы очень упрощаете работу архитектора. Например сейчас я описываю документ "Концепция интеграции". Его появление связано с тем, что в компании появилась шина данных. И я именно, что широкими мазками объясняю как будет работать шина, как с ней будут работать другие системы, кто к кому будет подключаться, какие данные будут передаваться, как будет работать мониторинг и т.д.
И на этом моменте мне абсолютно плевать что за системы будут с шиной работать и какой стек технологий используется, этому документу плевать даже какая будет использоваться шина.
Очевидно, что стек любого ещё не выбранного документа я не знаю, но описать документ могу. А вот отдать его написание бизнес-аналитикам невозможно, они далеки от ит, чтобы принимать такие решения.
И этих решений сильно больше, чем кажется.