И то и другое называют паттернами (т.к. есть контекст, проблемы, которые он решает и принципы, которам надо следовать и т.п) и классом програмного обеспечения (Kong API Gateway, WSO2, Mule, Red Hat 3scale, Oracle ESB)
"An ESB, or enterprise service bus, is an architectural pattern whereby a centralized software component performs integrations between applications." (https://www.ibm.com/cloud/learn/esb)
В этой статье сделан акцент на то, что Enterprise API это в первую очередь набор спецификаций API, которые покрывают функциональность существующих систем и используются для создания новых сервисов и продуктов. Особенность нашего набора Enterprise API, что он построен на базе TMF Open API и использует стиль REST.
Естественно, одни IT системы предоставляют сервисы реализующие это спецификации (providers), другие IT системы потребляют эти API (consumers).
И для интеграции этих систем, с технической точки зрения, Enterprise API развернут на API Gateway (который сделан на основе Kong API Gateway плюс небольшие доработки).
Можно, я не буду писать тут сходства и различие подходов интеграции на API Gateway и Enterprise Service Bus? (во-первых, это уже не раз обсуждалось куда более именитыми архитекторам, а во вторых, не хочу разжечь тут holywar).
Правильно я понял, что у вас одна команда API PM и несколько команд Архитекторов / Разработчиков?
Да тут все правильно.
Кто должен принять волевое решение и взять на себя ответственность в случае отсутствия консенсуса между командами? Не за что не поверю, что договориться удается прямо всегда.
Приходиться договариваться всегда. Много, конечно, зависит от людей и культуры в компании. Что помогает нам:
1. Понимание во всех трех командах - что самое важно это ценность которую принесет клиентам все IT-решение целиком, а не конкретное название атрибута.
2. "Разрешение на ошибку" - все команды и бизнес-представители, понимают, что при давлении сроков не редки ситуации, когда принято будет не самое оптимальное решение, и его придется переделывать. Тут уже надо смотреть что важнее T2M прямо сейчас, или в перспективе.
3. Опять же, "временные решения" никто не отменял, да они вредны, но иногда приходится идти и на это. (вплоть до того, что системы интегрировались в обход Enterprise API, чтобы вывести новый продукт на рынок вовремя, а потом постепенно интеграция переводилась на Enterprise API). Тут главное, делать это прозрачно и понятно всех заинтересованым лицам (и преимущества и недостатки такого решения, должны быть услышаны всеми)
Я не придираюсь, мне правда очень интересно, как не сделать команду API PM бутылочным горлышком.
Любая команда, которая держит «центральную функцию», может стать бутылочным горлышком. Может тут поможет органичная организация команды: мы разделили наш бизнес-домен на несколько поддоменов, и за каждый поддомен отвечало 2-3 человека. Соотвественно их задача развивать API в своем поддомене, и отслеживать что бы решения принятые других поддоменах как минимум не противоречили.
А теперь подробнее и издалека: требование "добавить поле", все же очень техническое. И вероятно, до того, как мы придем к пониманию что это нам "нужно новое поле", будет проделана какая-то работа над бизнес-требованиями (например, для "Для эффективной работы второй линии поддержки необходимо чтобы IT-системы документировали серийный номер оборудования (модема) и отображали его в пользовательских интерфейсах для оператора поддержки".)
Если же действительно, окажется, что нужно добавить одно поле и оно не является обязательным (optional) то изменения совместимы (в большинстве случаев) и можно просто выпустить новую minor версию текущего API. В силу того, что поставки и демонстрации изменений происходят раз в спринт, то изменения в спецификации будут доступны в конце спринта.
В каких-то критических случаях, когда отсутствие поля угрожает текущим бизнес- процессам или безопасности решения, можно сделать и срочную "поставку", но это уже "тушение пожаров" и тут "гордиться" быстрыми изменениями не стоит.
В случае если необходимо сделать несовместимое изменение в спецификации (например, mandatory атрибут в схеме request) то тут могут быть разные варианты (потому что это дорого поддерживать много версий API параллельно и не все системы-потребители готовы быстро перейти на новую версию):
создание сразу новой версии спецификации - её так же можно сделать за один спринт, но стараются не спешить (см. ниже)
попробовать "накопить" набор несовместимых изменений и выпустить новую major версию API с задержкой (от месяца до 3 месяцев, что примерно укладывается в Program Increment в терминах SAFe framework'а)
пересмотреть (совместно с представителями бизнеса) приоритет требования.
Кроме этого, в TMF Open API использует шаблон "entity-characteristic" (который схож по логике с "Entity–attribute–value"), он позволяет добавлять характеристики к объектам не меняя структуры объекта (и его схемы). У этого подхода есть недостатки (непрозрачность изменений, сложность реализации клиентской части и т.п.), но его можно использовать и для "добавления поля" при этом оставляя спецификацию API без изменений.
Именно вопросы, "что нужно (и нужно ли) изменить в API для реализации того или иного бизнес требования" и является основной темой дискуссий в организационном треугольнике что был показан в статье.
Сразу видно, читали «в деталях» и даже пытались применить.
Да, естественно, параметры которые специфичны для окружения у нас не храняться в yaml.
Во-первых мы и не собирались использовать пока эту информацию (те же порты)
Во-вторых есть ограничения в Pivio-LeanIX интеграции (большая часть полей не поддерживается — например lifecycle).
Ну и в третьих, если уж нам действительно нужны будут параметры с окружения — можно попробывать использовать интеграцию LeanIX Cloud Native Suite с k8s (https://www.leanix.net/en/solutions/cloud-native-suite). Но повторюсь, пока мы не дошли до такой необходимости.
В четверых, если вам все же нужны будут значения с окружения, мы же можете в процессе разворачивания просто вызвать LeanIX REST API и обновить нужные аттрибуты уже в существующих Fact Sheet.
Да, решение которые мы используем вряд ли можно назвать дешевым, оно скорее применимо в компаниях: где уже есть практика Enterprise Architecture Management, существует описание IT ландшафта и эту EAM практику надо «обновить» с учетом того, что IT ландшафт становится все более «микросервисным».
С моей т.з., вам все равно нужно хранить метаинформацию о компонентах, где-то рядом с кодом самих компонентов. Мы используем yaml файл, antirek использует labels в docker-compose.
После того как у вас действительно есть «информация», то остается достаточно простая задачи по ее сбору в единую документацию и предоставления в удобном виде. И тут уже много вариантов в зависимости от ваших возможностей и требованиям к документации.
Для внутренних нужд мы используем генератор, который создает страницы в confluence wiki на основе метаинформации и конфигурации зависимостей между компонентами. (https://www.youtube.com/watch?v=V56GEtx36HE&feature=youtu.be&t=2693 с 43 минуты, пару слайдов о нашем опыте).
Вы можете попробовать сервис Pivio (http://pivio.io), но тут на ваш риск, проект сейчас не выглядит очень живым и развивающимся.
Так же, вы повторить наш опыт использования проекта github.com/AOEpeople/vistecture. (то же видео что и раньше, но с 35-й минуты).
antirek предлагает просто генерацию html страниц(что очень похоже на пункт 1.)
Как-то были эксперементы по падению частоты в сети определять сколько зрителей смотрять передачу. И так же были попытки организовать голосование посредством вкл/выкл. телевизоров (точность, конечно, так себе...)
как минимум можно еще использовать частотный словарь по корпусу английского языка. первые 5000-10000 слов вы уже должны знать (ибо самые часто используемые и там же все местоимения, числительные т.п.).
Подтверждаю, в СПб кризис библиотек прошел, сейчас даже в районных библиотеках вполне приличное финансирование, которое позволяет не только поддерживать «классический школьный фонд», но покупать книги совсем для малышей (1,5-6 лет).
Следуя такой логике — пункты приема посылок надо тщательно маскировать и ни кому не говорить где они, тем самым снизим поток посылок (своеобразный перманентный DDOS), тем самым решим еще часть проблема Почты России.
И то и другое называют паттернами (т.к. есть контекст, проблемы, которые он решает и принципы, которам надо следовать и т.п) и классом програмного обеспечения (Kong API Gateway, WSO2, Mule, Red Hat 3scale, Oracle ESB)
"An ESB, or enterprise service bus, is an architectural pattern whereby a centralized software component performs integrations between applications."
(https://www.ibm.com/cloud/learn/esb)
"Pattern: API Gateway " (https://microservices.io/patterns/apigateway.html)
"An API gateway is an API management tool " (https://www.redhat.com/en/topics/api/what-does-an-api-gateway-do)
"An enterprise service bus (ESB) is a software platform" (https://searchapparchitecture.techtarget.com/definition/Enterprise-Service-Bus-ESB)
В этой статье сделан акцент на то, что Enterprise API это в первую очередь набор спецификаций API, которые покрывают функциональность существующих систем и используются для создания новых сервисов и продуктов. Особенность нашего набора Enterprise API, что он построен на базе TMF Open API и использует стиль REST.
Естественно, одни IT системы предоставляют сервисы реализующие это спецификации (providers), другие IT системы потребляют эти API (consumers).
И для интеграции этих систем, с технической точки зрения, Enterprise API развернут на API Gateway (который сделан на основе Kong API Gateway плюс небольшие доработки).
Можно, я не буду писать тут сходства и различие подходов интеграции на API Gateway и Enterprise Service Bus? (во-первых, это уже не раз обсуждалось куда более именитыми архитекторам, а во вторых, не хочу разжечь тут holywar).
Да тут все правильно.
Приходиться договариваться всегда. Много, конечно, зависит от людей и культуры в компании. Что помогает нам:
1. Понимание во всех трех командах - что самое важно это ценность которую принесет клиентам все IT-решение целиком, а не конкретное название атрибута.
2. "Разрешение на ошибку" - все команды и бизнес-представители, понимают, что при давлении сроков не редки ситуации, когда принято будет не самое оптимальное решение, и его придется переделывать. Тут уже надо смотреть что важнее T2M прямо сейчас, или в перспективе.
3. Опять же, "временные решения" никто не отменял, да они вредны, но иногда приходится идти и на это. (вплоть до того, что системы интегрировались в обход Enterprise API, чтобы вывести новый продукт на рынок вовремя, а потом постепенно интеграция переводилась на Enterprise API). Тут главное, делать это прозрачно и понятно всех заинтересованым лицам (и преимущества и недостатки такого решения, должны быть услышаны всеми)
Любая команда, которая держит «центральную функцию», может стать бутылочным горлышком. Может тут поможет органичная организация команды: мы разделили наш бизнес-домен на несколько поддоменов, и за каждый поддомен отвечало 2-3 человека. Соотвественно их задача развивать API в своем поддомене, и отслеживать что бы решения принятые других поддоменах как минимум не противоречили.
Короткий ответ: 1 спринт
А теперь подробнее и издалека: требование "добавить поле", все же очень техническое. И вероятно, до того, как мы придем к пониманию что это нам "нужно новое поле", будет проделана какая-то работа над бизнес-требованиями (например, для "Для эффективной работы второй линии поддержки необходимо чтобы IT-системы документировали серийный номер оборудования (модема) и отображали его в пользовательских интерфейсах для оператора поддержки".)
Если же действительно, окажется, что нужно добавить одно поле и оно не является обязательным (optional) то изменения совместимы (в большинстве случаев) и можно просто выпустить новую minor версию текущего API. В силу того, что поставки и демонстрации изменений происходят раз в спринт, то изменения в спецификации будут доступны в конце спринта.
В каких-то критических случаях, когда отсутствие поля угрожает текущим бизнес- процессам или безопасности решения, можно сделать и срочную "поставку", но это уже "тушение пожаров" и тут "гордиться" быстрыми изменениями не стоит.
В случае если необходимо сделать несовместимое изменение в спецификации (например, mandatory атрибут в схеме request) то тут могут быть разные варианты (потому что это дорого поддерживать много версий API параллельно и не все системы-потребители готовы быстро перейти на новую версию):
создание сразу новой версии спецификации - её так же можно сделать за один спринт, но стараются не спешить (см. ниже)
попробовать "накопить" набор несовместимых изменений и выпустить новую major версию API с задержкой (от месяца до 3 месяцев, что примерно укладывается в Program Increment в терминах SAFe framework'а)
пересмотреть (совместно с представителями бизнеса) приоритет требования.
Кроме этого, в TMF Open API использует шаблон "entity-characteristic" (который схож по логике с "Entity–attribute–value"), он позволяет добавлять характеристики к объектам не меняя структуры объекта (и его схемы). У этого подхода есть недостатки (непрозрачность изменений, сложность реализации клиентской части и т.п.), но его можно использовать и для "добавления поля" при этом оставляя спецификацию API без изменений.
Именно вопросы, "что нужно (и нужно ли) изменить в API для реализации того или иного бизнес требования" и является основной темой дискуссий в организационном треугольнике что был показан в статье.
Да, естественно, параметры которые специфичны для окружения у нас не храняться в yaml.
Например, konghq.com/products/kong-enterprise/dev-portal, правда, я не уверен что будет удобен если не используете Kong как API Gateway.
С моей т.з., вам все равно нужно хранить метаинформацию о компонентах, где-то рядом с кодом самих компонентов. Мы используем yaml файл, antirek использует labels в docker-compose.
После того как у вас действительно есть «информация», то остается достаточно простая задачи по ее сбору в единую документацию и предоставления в удобном виде. И тут уже много вариантов в зависимости от ваших возможностей и требованиям к документации.
Опять же Web интерфес, тем кому только посмотреть. Да еще помелочам есть плюсы (для примера, OSLC)
https://www.youtube.com/watch?v=RVHTJFJig0c
http://mi3ch.livejournal.com/2324533.html
Так же не лишним будет прослушать тренинги по правилам проведения соревнований (WRO/FIRST LEGO).
education.lego.com/ru-ru/lego-education-product-database/mindstorms-ev3/2005544-lego-mindstorms-education-ev3-design-engineering-projects
education.lego.com/ru-ru/preschool-and-school/secondary/mindstorms-education-ev3/teaching-resources/academy
wroboto.ru/regions/SaintPetersburg/news/news_125.html
bricklink.com в помощь