Comments 8
Сколько по времени займет добавить новое поле в 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 для реализации того или иного бизнес требования" и является основной темой дискуссий в организационном треугольнике что был показан в статье.
Спасибо за развернутый ответ, он хорошо дополняет статью.
Собственно, интересовало время согласований, понятно, что с технической точки зрения добавление поля не должно являться чем-то суперсложным.
Вот этот момент, собственно, интересует больше всего:
>Команда API PM, в свою очередь, обсуждает с командами разработки и архитектурной >командой изменения в API, и меняет спецификации API.
Это же 3 команды должны прийти к консенсусу, а тут люди болеют, отпуска, командировки, сроки, давление бизнеса.
Правильно я понял, что у вас одна команда API PM и несколько команд Архитекторов / Разработчиков?
Кто должен принять волевое решение и взять на себя ответственность в случае отсутствия консенсуса между командами? Не за что не поверю, что договориться удается прямо всегда.
P.S. Я не придираюсь, мне правда очень интересно, как не сделать команду API PM бутылочным горлышком.
P.P.S. IMHO "entity-characteristic" и прочие хаки нивелируют сам смысл API и приведут к замусориванию и хаосу через пару лет.
Правильно я понял, что у вас одна команда API PM и несколько команд Архитекторов / Разработчиков?
Да тут все правильно.
Кто должен принять волевое решение и взять на себя ответственность в случае отсутствия консенсуса между командами? Не за что не поверю, что договориться удается прямо всегда.
Приходиться договариваться всегда. Много, конечно, зависит от людей и культуры в компании. Что помогает нам:
1. Понимание во всех трех командах - что самое важно это ценность которую принесет клиентам все IT-решение целиком, а не конкретное название атрибута.
2. "Разрешение на ошибку" - все команды и бизнес-представители, понимают, что при давлении сроков не редки ситуации, когда принято будет не самое оптимальное решение, и его придется переделывать. Тут уже надо смотреть что важнее T2M прямо сейчас, или в перспективе.
3. Опять же, "временные решения" никто не отменял, да они вредны, но иногда приходится идти и на это. (вплоть до того, что системы интегрировались в обход Enterprise API, чтобы вывести новый продукт на рынок вовремя, а потом постепенно интеграция переводилась на Enterprise API). Тут главное, делать это прозрачно и понятно всех заинтересованым лицам (и преимущества и недостатки такого решения, должны быть услышаны всеми)
Я не придираюсь, мне правда очень интересно, как не сделать команду API PM бутылочным горлышком.
Любая команда, которая держит «центральную функцию», может стать бутылочным горлышком. Может тут поможет органичная организация команды: мы разделили наш бизнес-домен на несколько поддоменов, и за каждый поддомен отвечало 2-3 человека. Соотвественно их задача развивать API в своем поддомене, и отслеживать что бы решения принятые других поддоменах как минимум не противоречили.
Я так понимаю, что Enterprise API это не что иное, как Enterprise Service Bus (ESB) только собственной разработки. Или под капотом что-то общеизвестное от именитого вендора и просто так называют 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 Gateway это паттерн, а ESB это уже больше про классификацию ПО реализующего, в том числе, и этот паттерн.
И то и другое называют паттернами (т.к. есть контекст, проблемы, которые он решает и принципы, которам надо следовать и т.п) и классом програмного обеспечения (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)
Pipeline for Enterprise API