С BPM-suite tool известно, какие сервисы нужны для данного процессам. Сложность сосит в том, что реализаторы разный процессов должны договариваться, если появляются общие сервисы. Так, что все очень динамично и ажильно.

"Основная задача архитектора - отложить принятие важных решений на как можно более долгий срок. Тем самым обеспечив эволюционное развитие. Выбирая то или иное решение нужно всегда думать о том как оно будет изменено (planned obsolescence)". Эти три предложения противоречат друг другу. Основная задача архитектора - обеспечить развитие (хотя зависит от задачи). Поэтому, некие важные решения принимаются как можно раньше.

Никаких противоречий. Суть эволюционной архитектуры - минимизация upfront решений. Но для практической реализации данного подхода нужно принять много важных решений. Чуть позже сформулирую более развёрнуто, общих фраз недостаточно.

Так это минимизация 1) уровня детализации (обозначаем все "upfront решения") или 2) количества  (откладываем на потом "upfront решения" )?

На мой взгляд оба варианта возможны. Мы не можем точно знать, какие требования появятся у заказчика на следующей итерации.

Возможно, какие-то будут требовать создания нового решения внутри системы. А если пытаться заложить принципиально любую расширяемость, то это уже почти платформа

Так, реальный пример. Заказчик - у системы, дополнительно ко всему функционалу, должны быть высокие уровни flexibility, security, privare, safety and relisience; low cost of operaiton and short time-to-market.  Ваш выбор?

Вы не могли бы уточнить термины privare и relisience?

Oops, where was my spell checker - privacy and resilience

А в чем разница между вторым и первым? Мне кажнтся, количество и детализация сильно связаны.

Контекст обсуждения определен утверждениями, что  "Основная задача архитектора - отложить принятие важных решений на как можно более долгий срок." и "Суть эволюционной архитектуры - минимизация upfront решений." Известно, что количество "важных upfront решений" зависит от ширины охвата и глубины проработки.  Ну дальше все зависит, как всегда. Какая задача, каков клиент, какие решения. Чаще всего, получается фигура, которая отнюдь не прямоугольник.

Друзья, а дайте практический совет: насколько отечественные банки восприимчивы к теме BIAN? Вот в телекоме, TAM и eTOM - это наше все. Если корпоративный архитектор в телко не знает что сказать в той или иной ситуации, он говорит что-то невнятно про TMForum. В банках так же?

Мы работаем над тем, чтобы банки ссылались на TMF, етомы, темы, сиды ;) ищем места процессингов, аккаунтинг енжинов и тп. Новая карта transformation to an agile на раз с банками. Надо тут подумать, где там nfv;)

Максим, не теряй корни TMF)

А что это за карта transformation to an agile, расскажешь?

лови

она только что появилось, это новое для телко, но явно нужно выравнивать с соседними индустриями

Прикольно

Однозначно будет полезно для других индустрий. В телко это как бы само собой разумеющаяся картинка, а для банков будет откровением