Pull to refresh
16
0

Lead Architect

Send message

И то и другое называют паттернами (т.к. есть контекст, проблемы, которые он решает и принципы, которам надо следовать и т.п) и классом програмного обеспечения (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). 

Правильно я понял, что у вас одна команда API PM и несколько команд Архитекторов / Разработчиков?

Да тут все правильно.

Кто должен принять волевое решение и взять на себя ответственность в случае отсутствия консенсуса между командами? Не за что не поверю, что договориться удается прямо всегда.

Приходиться договариваться всегда. Много, конечно, зависит от людей и культуры в компании. Что помогает нам:

1. Понимание во всех трех командах - что самое важно это ценность которую принесет клиентам все IT-решение целиком, а не конкретное название атрибута.

2. "Разрешение на ошибку" - все команды и бизнес-представители, понимают, что при давлении сроков не редки ситуации, когда принято будет не самое оптимальное решение, и его придется переделывать. Тут уже надо смотреть что важнее T2M прямо сейчас, или в перспективе.

3. Опять же, "временные решения" никто не отменял, да они вредны, но иногда приходится идти и на это. (вплоть до того, что системы интегрировались в обход Enterprise API, чтобы вывести новый продукт на рынок вовремя, а потом постепенно интеграция переводилась на Enterprise API). Тут главное, делать это прозрачно и понятно всех заинтересованым лицам (и преимущества и недостатки такого решения, должны быть услышаны всеми)

Я не придираюсь, мне правда очень интересно, как не сделать команду API PM бутылочным горлышком.

Любая команда, которая держит «центральную функцию», может стать бутылочным горлышком. Может тут поможет органичная организация команды: мы разделили наш бизнес-домен на несколько поддоменов, и за каждый поддомен отвечало 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.
  • Во-первых мы и не собирались использовать пока эту информацию (те же порты)
  • Во-вторых есть ограничения в Pivio-LeanIX интеграции (большая часть полей не поддерживается — например lifecycle).
  • Ну и в третьих, если уж нам действительно нужны будут параметры с окружения — можно попробывать использовать интеграцию LeanIX Cloud Native Suite с k8s (https://www.leanix.net/en/solutions/cloud-native-suite). Но повторюсь, пока мы не дошли до такой необходимости.
  • В четверых, если вам все же нужны будут значения с окружения, мы же можете в процессе разворачивания просто вызвать LeanIX REST API и обновить нужные аттрибуты уже в существующих Fact Sheet.
то что вы описываете, в верхних трех строчках, больше похоже на API Management, посмотрите решения класса API Portal / API Management.

Например, konghq.com/products/kong-enterprise/dev-portal, правда, я не уверен что будет удобен если не используете Kong как API Gateway.
странно, месяц назад была. Тогда смотрите официальный сайт — www.leanix.net/en
Да, решение которые мы используем вряд ли можно назвать дешевым, оно скорее применимо в компаниях: где уже есть практика Enterprise Architecture Management, существует описание IT ландшафта и эту EAM практику надо «обновить» с учетом того, что IT ландшафт становится все более «микросервисным».

С моей т.з., вам все равно нужно хранить метаинформацию о компонентах, где-то рядом с кодом самих компонентов. Мы используем yaml файл, antirek использует labels в docker-compose.

После того как у вас действительно есть «информация», то остается достаточно простая задачи по ее сбору в единую документацию и предоставления в удобном виде. И тут уже много вариантов в зависимости от ваших возможностей и требованиям к документации.

  1. Для внутренних нужд мы используем генератор, который создает страницы в confluence wiki на основе метаинформации и конфигурации зависимостей между компонентами. (https://www.youtube.com/watch?v=V56GEtx36HE&feature=youtu.be&t=2693 с 43 минуты, пару слайдов о нашем опыте).
  2. Вы можете попробовать сервис Pivio (http://pivio.io), но тут на ваш риск, проект сейчас не выглядит очень живым и развивающимся.
  3. Так же, вы повторить наш опыт использования проекта github.com/AOEpeople/vistecture. (то же видео что и раньше, но с 35-й минуты).
  4. antirek предлагает просто генерацию html страниц(что очень похоже на пункт 1.)
ну shared DB совсем плохо работает через интернет.
Опять же Web интерфес, тем кому только посмотреть. Да еще помелочам есть плюсы (для примера, OSLC)
Рассматривали более продвинутые (чем SVN и shared DB) методы совместной работы в Sparx EA? EA Cloud, EA PRO Cloud Server / Express / WebEA.
Как-то были эксперементы по падению частоты в сети определять сколько зрителей смотрять передачу. И так же были попытки организовать голосование посредством вкл/выкл. телевизоров (точность, конечно, так себе...)

https://www.youtube.com/watch?v=RVHTJFJig0c
http://mi3ch.livejournal.com/2324533.html
как минимум можно еще использовать частотный словарь по корпусу английского языка. первые 5000-10000 слов вы уже должны знать (ибо самые часто используемые и там же все местоимения, числительные т.п.).
А это кстати, действительно проблема. Очень тяжело давать пример детям читать бумажные книги если я сам читаю только с электронных носителей.
Подтверждаю, в СПб кризис библиотек прошел, сейчас даже в районных библиотеках вполне приличное финансирование, которое позволяет не только поддерживать «классический школьный фонд», но покупать книги совсем для малышей (1,5-6 лет).
У подразделения Lego Education есть методические материалы и курсы для учителей.

Так же не лишним будет прослушать тренинги по правилам проведения соревнований (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

ftp drive или аналог — поможет вам.
Следуя такой логике — пункты приема посылок надо тщательно маскировать и ни кому не говорить где они, тем самым снизим поток посылок (своеобразный перманентный DDOS), тем самым решим еще часть проблема Почты России.
>>И опять мало деталей.
bricklink.com в помощь

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity