Привет! Меня зовут Борис Пишванов, руковожу архитекторами решений в Альфа-Банке. В статье хочу поделиться историей нашей команды архитекторов решений, которая включает около 90 человек и занимается созданием и разработкой архитектуры IT-решений для бизнес-инициатив крупного банка. Уверен, многим из вас наша история покажется знакомой, а возможно, кому-то поможет избежать наших ошибок или найти вдохновение для позитивных изменений.

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

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

Нужно было что-то менять на кардинально новое. Мы начали искать подход, который помог бы объединить отдельные инициативы в единую осмысленную систему. И здесь наше внимание привлёк подход Capabilities-Based Planning (CBP), про который мы узнали из TOGAF.

Так родилась простая, но, как оказалось, рабочая идея:

«А давайте подойдём к нашей работе как к развитию бизнес-функции. Через capabilities»

Чем нас заинтересовал именно CBP?

Во-первых, своей ориентацией на долгосрочную перспективу. Вместо того чтобы постоянно тушить пожары и «латать дыры», CBP предлагает посмотреть на организацию через призму её возможностей (capabilities). Это позволяет планировать не отдельные изменения, а комплексное развитие архитектурной практики.

Во-вторых, CBP предполагает возможность говорить на одном языке с бизнесом. Вместо технических деталей мы обсуждаем возможности, которые нужны организации для достижения её стратегических целей. Это значительно упростило коммуникацию с коллегами из бизнеса и сделало обсуждения понятнее и продуктивнее.

В-третьих, нас привлекла гибкость этого подхода. CBP не заставляет вас всё переделывать с нуля, а позволяет постепенно и последовательно развивать архитектуру, опираясь на уже существующие сильные стороны компании и постепенно устраняя слабые.

Именно поэтому мы решили дать шанс Capabilities-Based Planning и уже вскоре убедились, что не ошиблись в своём выборе.

Немного теории о Capabilities-Based Planning (CBP)

Это подход к стратегическому планированию, который фокусируется на бизнес-возможностях организации (capabilities) и желаемых результатах, а не на отдельных проектах или требованиях.

Проще говоря, вместо планирования «Что мы делаем», CBP концентрируется на «Что мы умеем делать» и «Что нам необходимо уметь» для достижения стратегических целей. Каждая бизнес-возможность представляет собой определённую способность компании достичь конкретной цели или результата, объединяющую необходимые элементы: людей, процессы/процедуры, технологии и информацию.

Таким образом, capability – это не просто функция или процесс, а совокупность факторов, необходимых для выполнения определённых задач.

Когда мы внедряем Capabilities-Based Planning, логично не только помогать другим подразделениям развивать свои возможности или требовать от них «всякого», но и смотреть на архитектурную функцию как на отдельный бизнес-юнит.

Мы сами — поставщик архитектурных сервисов, и у нас есть собственные «capabilities», без которых мы не можем эффективно поддерживать развитие организации. Чтобы двигаться от хаоса к зрелости, нужно понять, какие способности нам нужны, и оценить, на каком уровне зрелости они находятся сейчас.

Когда мы начали говорить о развитии архитектурных capabilities, естественно возник вопрос:

«А как понять, насколько зрелая будет та или иная способность? И главное — как её развивать?»

На помощь приходят CMMI — модель зрелости процессов и Architecture Maturity Models от Open Group.

В CMMI for Development (v1.2) под зрелостью понимается степень институционализации способности в организации. Грубо говоря — насколько устойчиво, повторяемо и управляемо то, что вы делаете.

Каждая capability (в нашем случае — архитектурная) может находиться на одном из 5 уровней зрелости:

Initial (Начальный): всё держится на энтузиазме отдельных людей. Нет процесса, всё по ситуации. Один ушёл — всё развалилось.
Managed (Управляемый): деятельность уже проводится регулярно, есть элементарный контроль и ответственность. Но подход всё ещё локальный, не масштабируемый.
Defined (Определённый): процессы задокументированы, стандартизированы, применяются в разных проектах. Уже можно учить новичков и делиться опытом.
Quantitatively Managed (Количественно управляемый): используются метрики, проводится анализ. Решения основаны на данных, а не на ощущениях.
Optimizing (Оптимизирующий): постоянное улучшение встроено в процесс. Идёт активная работа по адаптаии, обучению, экспериментам.

Для удобства оценки зрелости воспользовались таким представлением:

Уровень зрелости/Критерий оценки	1. Initial, Начальный	2. Under Development, Повторяемый	3. Defined, Определённый	4. Managed, Управляемый	5. Measured, Оптимизирующий
Процессы	Не формализованы	Разрабатываются	Согласованы	Согласованы	Согласованы
Инструменты	Не специализированы	Выбираются	Выбраны	Выбраны	Выбраны
Инструкции	Отстутствуют	Разрабатываются	Согласованы	Согласованы	Согласованы
Критерии оценки качества этой способности	Отстутствует	Отстутствует	Отстутствует	Выбраны	Выбраны
Изменение процессов на основе анализа показателей качества	Отстутствует	Отстутствует	Отстутствует	Отстутствует	При необходимости

Как мы начинали внедрять Capabilities-Based Planning (CBP)

Моя идея заключалась в следующем:

Определить наши архитектурные capabilities — то есть то, что мы должны уметь делать как архитектурная функция.
Для каждой capability оценить текущий уровень зрелости и определить, какой уровень мы хотим достичь.
Действовать.

Признаться честно, сначала фраза «давайте опишем наши capabilities» звучала немного абстрактно. Ну, мы же архитекторы, что тут искать? Делаем архитектуру — вот и всё.

Но когда мы начали в это погружаться, поняли: именно в этом и была проблема. Мы вроде бы и заняты полезными делами, но не могли чётко сформулировать: «А в чём, собственно, наша «способность» как подразделения или их много?»

Начали с простого вопроса: «А что мы вообще должны уметь делать как архитектурная функция?»

Мы собрали небольшой воркшоп — без формальностей, просто пообщаться. Задали себе вопрос: «Что мы делаем сейчас? Какие у нас есть продукты и услуги? Что мы реально умеем делать?»

Кто-то сказал: «Мы проводим архитектурные ревью», кто-то — «Мы формируем стандарты», кто-то — «Мы консультируем команды». А потом кто-то бросил: «А есть ли у нас способность влиять на стратегию?».

И решили провести оценку того, как мы это всё делаем. Так появился некий драфт того, что мы сейчас умеем и делаем.

Фокус сместился: от задач — к возможностям.

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

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

Чего-то не хватало, или Почему меня не устроил первый перечень Capabilities

Когда мы составили первый вариант нашей Capability Map, лично меня это не совсем устроило. Список возможностей получился словно отражением того, что мы уже делаем сейчас. И у меня возникло ощущение, что мы смотрим только в зеркало, а не вперёд.

Да, мы честно зафиксировали текущие задачи и области ответственности. Но возник вопрос: а достаточно ли этого? Ведь наверняка мы могли бы делать больше и эффективнее. Может быть, то, как мы сейчас работаем, уже устарело, и стоит заглянуть в будущее или даже посмотреть по сторонам — на другие компании или референсные модели?

На этом этапе стало понятно: надо было не ограничиваться текущими процессами, а заглянуть глубже. Возможно, стоило использовать опыт других организаций, архитектурные фреймворки (например, TOGAF) или референсные Capability Maps из индустрии. Это помогло бы увидеть возможности, которые мы пока даже не рассматриваем, но которые могли бы существенно усилить наш вклад в бизнес. Определить не просто текущие, а целевые capabilities, то есть те, к которым мы хотим прийти через 1-2 года.

Мы начали копать.

Копались в Google, шерстили LinkedIn, ходили по блогам крупных архитекторов, заглядывали в TOGAF, в материалы Open Group, смотрели даже на старые PDF-файлы с конференций. И каждый раз ловили одно и то же чувство:

Вроде всё интересно, но где нормальный, внятный список архитектурных capabilities? Не в формате — «высокий уровень зрелости», а по-человечески: что архитектура должна уметь делать как функция?

Красивые слова, диаграммы с треугольниками есть, а чего-то практического — мало. В какой-то момент мы даже начали сомневаться, а существует ли вообще такой список в природе.

И вот однажды совершенно случайно я наткнулся на статью 2012 года (!) в блоге Open Group — «When Was Your Last Enterprise Architecture Maturity Assessment?»

И вот она реально стала находкой.

Внутри — довольно простой и честный текст. Но главное — в нём был список архитектурных capabilities, которые можно использовать для оценки зрелости архитектурной функции. Без пафоса. Без драмы. Просто список:

Process Area

EA Development

EA Documentation and Standards

EA Governance

EA Competencies

Business Linkage

Business Transformation

Top-level and Senior Management Engagement

Lines of Business Collaboration

Lines of Business Buy-in

EA Web Site

EA Communication and Education

EA Stakeholder Management

Architect Communities

Enterprise Investment and Procurement Strategies

Service Qualities

EA Change Management

Requirements Management

EA Tools

Это был глоток свежего воздуха. Наконец-то — не просто «модель зрелости» в 5 стадий, а понятные, обозримые элементы, из которых можно собрать собственную архитектурную Capability Map.

Но довольно быстро стало понятно:

Этот список — это просто набор слов. Умных, правильных, но всё ещё пустых.

А что это значит конкретно для нас?

Мы поняли, что слова типа «EA Documentation and Standards», «Architect Communities», «Requirements Management» звучат сильно…Но что они реально значат в контексте нашей организации? Да еще и на иностранном языке.

Например, для одного «EA Development» — это про работу с TOGAF-циклами и модели ArchiMate, для второго — просто быстро нарисовать картинку для проекта, а для третьего — долгосрочная стратегия развития ИТ-ландшафта банка. А «Architect Communities» — это что? Почта с диаграммой? Документация в Confluence? Презентация для бизнеса? Вовлечённость команд?

Без ясного определения каждый видел в этих словах своё, и мы снова рисковали разойтись в трактовках и действиях.

И тогда мы сделали важный шаг: дали определение каждой capability — как она должна пониматься в нашей архитектурной практике. Обсуждали, спорили, уточняли — пока не получались формулировки, в которых все узнавали себя. Те формулировки, которые отражают нашу деятельность. Например:

Service Qualities / Качество обслуживания: это не просто моделирование, а способность системно формировать архитектурные решения, учитывать зависимости, стандарты, сопровождать жизненный цикл и обеспечить согласованность в масштабах организации.
Architect Communities / Общебанковское архитектурное сообщество: архитектурная способность, позволяющая распространять и масштабировать принципы, подходы и решения, применяемые для достижения бизнес-целей предприятия.

Каждая capability обрела конкретное, «наше» значение, и это был поворотный момент.

Некоторые capabilities у нас вообще не были представлены. Не то чтобы мы их забыли — просто они никогда раньше не были нашей зоной внимания. Часть способностей выходила за рамки зоны ответственности архитекторов решений. Такие способности должны были развивать корпоративные архитекторы. Какие-то объединили в одну способность, от каких-то отказались вовсе.

Например:

Enterprise Investment and Procurement Strategies / Стратегии корпоративных инвестиций и закупок: архитекторы решений не являются постоянными участниками этих процессов. Лишь эпизодически нас привлекают на тендеры. Поэтому отказались
Top-level and Senior Management Engagement / Вовлечение топ-менеджмента: кажется, что эта способность должна быть больше представлена в Корпоративной архитектуре.

По итогам обсуждений и примерок на нашу деятельность получился следующий результат:

Название capability (Eng)	Название способности (Рус)	Описание и границы
EA Communication & Community	Коммуникация и коммьюнити	Способность качественно строить и поддерживать общение, обсуждение и обучение внутри архитектурной практики. Дистрибуция знаний об архитектуре внутри и во вне.
EA Development & Business Transformation	Развитие процесса управления архитектурой	Способность описывать текущие процессы, вносить предложения по «to be», пилотировать новые артефакты и процессы в части методологии, выделять и реализовывать эти активности. Совершенствуем процесс реагирования на изменение условий ведения бизнеса и ведения архитектуры. Выдача рекомендаций по изменению политик и процессов.
EA Documentation and Standarts	Архитектурная документация и стандарты	Способность управления созданием, обновлением, согласованием и актуализацией документации и стандартов.
EA Education	Обучение	Способность обучения архитекторов и от архитекторов.
EA Governance & Compliance	Политики управления архитектурой и контроль	Эффективное управление, контроль и соблюдение архитектуры предприятия.
EA Onboarding	Подбор и адаптация сотрудников	Организация прозрачного, понятного и удобного процесса подбора и адаптации новых сотрудников.
EA Requirements Management	Управление требованиями	Процесс документирования, анализа, отслеживания, определения приоритетов и согласования требований, а затем контроля изменений и информирования соответствующих заинтересованных сторон. Это непрерывный процесс на протяжении всего проекта. Важные для каждого этапа требования меняются в процессе прохождения жизненного цикла проекта, а эта способность позволяет отслеживать и учитывать их.
EA Service Qualities	Качество обслуживания	Улучшение процессов и повышения качества взаимодействия заказчиков с дирекцией архитектуры и дирекции архитектуры с заказчиками и стейкхолдерами.
EA Stakeholder Management	Управление заинтересованными лицами	Обеспечение развития процесса управления заинтересованными лицами. Способность команды выстраивать продуктивные, понятные и устойчивые отношения с теми, кто влияет на архитектуру или зависит от неё.
EA Tools	Архитектурный инструментарий	Развитие инструментов, используемых архитекторами решений при проработке архитектурных решений и ведения репозитория.

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

Как будем мерить?

Когда появилась карта с понятными описаниями, встал следующий логичный вопрос: «А насколько у нас развита каждая из этих способностей?»

Сначала оценили «на глаз». Конечно, субъективно, но уже полезно — вскрывались разные точки зрения.

Потом перешли к более структурированному подходу : взяли таблицу зрелости (которая была в начале) с уровнями от 1 до 5 и короткими описаниями, что значит каждый уровень: от «делаем от случая к случаю» до «измеряем, анализируем и улучшаем». Смотрели по критериям: есть ли инструкции, формализованы ли процессы, есть ли автоматизация и т.д. Оценивали.

Провели голосование. Команда архитекторов решений оценивала зрелость каждой capability. Участники из разных бизнес-направлений часто не соглашались друг с другом.

И здесь мы увидели важную вещь:

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

То, что хорошо для Цифрового бизнеса, может быть губительно для Операционного департамента. Где-то предполагается запуск небольших инициатив по доработки фронта или интеграции с внешними партнерами и бизнес-требования динамично меняются, а где-то задачи затрагивают core-функции банка и требуют более тщательной документации и анализа.

В итоге мы приняли компромиссное решение — брать среднее значение по всей организации как «текущий уровень». Это позволяло не затирать особенности направлений, но всё же двигаться как единая команда. То, что касалось корпоративной архитектуры не оценивали и не брали во внимание.

В итоге получилась следующая карта способностей с оценкой текущей ситуации и планом на год:

А дальше — план действий

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

Начинаем разрабатывать процессы и документировать их.
Смотрим какие инструменты нам потребуются для автоматизации процессов.
Разрабатываем инструкции.

При этом держим табличку перед глазами.

Уровень зрелости/ Критерий оценки	1. Initial Начальный	2. Under Development Повторяемый
Процессы	Не формализованы	Разрабатываются
Инструменты	Не специализированы	Выбираются
Инструкции	Отстутствуют	Разрабатываются
Критерии оценки качества этой способности	Отстутствует	Отстутствует
Изменение процессов на основе анализа показателей качества	Отстутствует	Отстутствует

Когда архитекторы начинали работу с архитектурными capabilities, этот вид деятельности вызывал отторжение, так как казалось, что это вообще-то не архитектурная задача, а больше менеджерская: ходить, замерять, отслеживать прогресс. Часто приходилось слышать: «Ну, карта способностей, уровни зрелости — серьёзно? Это вообще кому-то интересно?»

Но всё изменилось, когда произошло переосмысление в том, как именно архитекторы могут в этом участвовать. Работа с архитектурными capabilities — это не просто про процессы, это ещё и про улучшение того, с чем работаешь каждый день ты сам и твои коллеги, а также личное развитие.

Организовали всё просто

📌 Раз в квартал мы пересобираемся по группам, которые работают над развитием конкретных архитектурных способностей.

Всегда есть:

Куратор capability(или подгруппы) — тот, кто координирует работу, задаёт ритм, цели и корректирует квартальный и годовой план развития.
Эксперты, которые давно развивают эту тему.
И, главное, архитекторы, которые сами выбирают, в какую способность они хотят включиться.

Поэтому, если архитектор приходит в новую capability , он всегда знает что происходит и зачем. А если не понимает, то ему расскажут те, кто давно «в теме».

Каждый может найти что-то близкое себе — не сверху по приказу, а снизу по интересу. За каждой capability стоит возможность развить реальные soft и hard skills.

Примеры из жизни:

Например, есть команда, которая разрабатывает плагин для Sparx EA — помогает всей организации быстрее и удобнее работать с архитектурным репозиторием. Хочешь прокачивать скилы в разработке — подключайся.

А если хочешь прокачать публичные выступления, присоединяйся к capability, связанной с взаимодействием с архитектурным комьюнити. Организуй митап, подготовь воркшоп или выступление — и получи живой опыт, который пригодится не только в архитектуре.

Про прошествии двух лет уже можно подводить какой-то итог

Когда мы начинали этот путь, то, честно говоря, не было уверенности, к чему это всё приведёт. Capabilities, зрелости, карты, голосования — всё это звучало хорошо на словах, но мы задавались вопросом: «А будет ли реальный эффект? Или это просто красивая методология для внутреннего отчёта?»

Прошло почти 2 года. И теперь, оглянувшись назад, могу сказать: да, результат есть. И он очень заметный — на всех уровнях.

Что это дало?

Единое понимание архитектурной функции. Мы больше не какие-то «люди, которые делают схемы». Мы — команда, у которой есть понятные способности, зоны ответственности, показатели зрелости и планы развития. Архитектура стала чёткой функцией, понятной всем.
Быстрее и качественнее решения. Повысилась зрелость процессов — меньше суеты, больше предсказуемости, работа автоматизируется.
Гибкость и устойчивость. Благодаря разным рабочим группам по capabilities, мы (как система) стали адаптивнее: не завязаны на отдельных людей, есть устойчивые процессы и ролевое распределение.
Я получил инструмент для развития команды. Теперь могу честно говорить с архитекторами: «Вот твоя текущая зона роста, вот где ты можешь вырасти», и у нас для этого есть реальные возможности.
Повысилась вовлечённость команды. Архитекторы начали видеть, что они не просто «вписываются в процессы», а влияют на то, как развивается архитектурная практика. Команды сами предлагают инициативы, инструменты, форматы — и делают это потому, что им интересно, а не потому, что «надо».
Личностный и профессиональный рост архитекторов. Каждый может использовать работу с capability как способ развития себя — в технике, в коммуникациях, в лидерстве. Кто-то научился быть наставником, кто-то начал выступать, кто-то прокачал аналитику, кто-то стал создателем внутренних инструментов.
Больше участия, меньше «надо». Архитекторы теперь выбирают сами, в каких capabilities участвовать. Это их выбор, их вклад, и это их драйвит.
Появилось чувство смысла. Когда ты понимаешь, что развиваешь не просто проект, а способность организации — это заряжает. Ты влияешь на целое.

Приведу примеры некоторых достижений

№1. Адаптация новых сотрудников и подбор.

Адаптация нового архитектора — длительный процесс. Часто он довольно сильно растянут во времени. И это — способность любой команды включить нового сотрудника в рабочий процесс. Мы и смотрели на это, как на способность нашей команды, как процесс развития конкретных компетенций, которые можно отслеживать и помогать прокачивать новому сотруднику.

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

Группа взялась за это: за описание процессов, поиск точек автоматизации, выбор критериев оценки. Например, сделали трек для нового сотрудника на внутреннем портале. Сначала на испытательный срок, потом стали смотреть как на карьерный трек.

Группа развития этой способности планирует, оценивает, улучшает процесс на постоянной основе.

Почти каждый день понятно, что требуется от нового сотрудника на этапе испытательного срока.
Чуть ли не каждый день расписан: что и как делать, где, какой доступ получить. Выделен наставник со своим планом работ.
Выбираются метрики оценки действий и наставника, и нового сотрудника.
Внедрены чек-листы онбординга, разработаны внутренние курсы по Архитектуре на внутреннем портале.
Построен трек адаптации сотрудника на 4-9 месяцев по развитию и hard и soft скиллов.

Что планируем сделать для развития еще этой способности? Как стать в адаптации более зрелыми? Есть ли ещё критерии, которые помогут понять насколько качественно адаптируется сотрудник?

Онбординг на бизнес-направлении с учетом специфики.
Включение типовых паттернов в трек адаптации.
Построение карьерного трека на 10 месяца — 2 года.

Это то, что уже в планах.

№2. Архитектурный инструментарий.

Способность по развитию Архитектурного инструментария выглядит более прикладной. Это то, что касалось каждого архитектора, с чем мы сталкиваемся каждый день. Тем более, что у нас уже был внедрен Sparx EA, а параллельно мы разрабатывали собственный аналог cmdb. Так что здесь мы стартовали не с нуля.

Результат от повышения зрелости более очевиден. Здесь требуются и понятные инструкции, особенно для новичков, и средства автоматизации, упрощающие и ускоряющие формирование архитектурных решений.

У нас в архитектурном репозитории закрыт вопрос с ведения архитектуры решений через Sparx EA.

Команда разработала к нему плагин для упрощения и ускорения работы архитектора решения.
Подключена автоматическая валидация всех архитектурных решения по внутренним правилам ведения нотации, а также правилам обеспечения безопасности.
Ввиду импортозамещения и санкций наша самописная cmdb переросла в архитектурный репозиторий с системой документооборота. По сути, у нас единая система с информацией обо всех системах, ответственных за системы, архитектуре, формирования и согласования всей документации.

Хотя многое сделано, многое прошло пилотное тестирование или ещё и в планах. Мы запустили пилот по сбору актуальную архитектуры («as is») по данным с промышленной среды. Планируем объединить ведение системной и бизнес архитектуры в едином репозитории. Ведётся разработка по предоставлению сетевых доступов на основе архитектурного решения. Разрабатываем AI-ассистента архитектора, помогающего с формированием архитектурных решений на основе предоставленных бизнес-требований.

Но не всё гладко

Когда мы начали развивать архитектурные capabilities, было понятно, что все они стартуют с разного уровня зрелости. Но мы немного удивились тому, как по-разному идёт прогресс.

📈 В одних зонах — прямо полёт. Команды берут инициативу, появляются инструменты, всё летит.
🐢 В других — мы как будто вязнем. Вроде все согласны, что это важно, но двигаться тяжело. Нет чёткого плана, нет прогресса.

Особенно это стало заметно на примере двух способностей: управление требованиями и управление заинтересованными сторонами. Попробую поделиться предположениями, почему так может происходит и также буду рад вашим предположениям в комментариях к статье.

В «технических» capabilities (инструменты, документация), процессы, как правило, проще описать и внедрить. Там есть чёткая грань «до — после», меньше людей вовлечено, больше предсказуемости.
А вот в управлении требованиями или вовлечением стейкхолдеров — всё тоньше. Это живые процессы, часто негласные, ситуативные. У всех своё понимание, у всех своя реальность. Попробуй опиши «как мы управляем ожиданиями людей» — это уже не процесс, а искусство.

В зоне EA-инструментов мы прямо чувствуем результат: появился плагин — стало удобно.
А вот в управлении требованиями заинтересованными сторонами...Какие у нас инструменты? Документы? Мы описали типовых заинтересованных лиц и их требований/ожидания. Из инструментов мы запилили прототип приложения, которое собирает возможных stakeholder’ов к задаче, исходя из исторических данных и возможных используемых систем.

Инструкцию по работе с архитектурным репозиторием написать можно. А вот как написать инструкцию по «вовлечению заинтересованных сторон»? Особенно если каждый проект — с разным контекстом, уровнем зрелости, скоростью и бизнесом. Кажется, здесь необходима не инструкция, а набор практик, подходов, шаблонов коммуникации, которые требуют живой работы, не просто чтения PDF.

А как измерить качество работы с требованиями? Или успешность взаимодействия со стейкхолдерами?

И т.д.

Мы научились не расстраиваться. Мы научились видеть в этом вызов — не технический, а человеческий. И именно поэтому, когда мы добьёмся прогресса в этих областях, это будет не просто галочка в таблице зрелости. Это будет реальное взросление архитектурной функции).

Итого

После всей проделанной работы — от составления карты способностей до оценки зрелости, от создания рабочих групп до внедрения улучшений — у нас сложилось твёрдое убеждение:

Подход на основе capabilities — это один из самых мощных и осмысленных инструментов развития архитектурной функции.

Это не просто модная методика. Это рабочая модель управления архитектурным подразделением как полноценной бизнес-функцией.

Вот почему это работает:

№1. Чем выше зрелость процессов — тем быстрее и прозрачнее становится работа.

Понятно, кто за что отвечает, кто принимает решения, у кого спрашивать. Это резко повышает скорость решения задач и снижает количество «зависших» задач.

№2. Capabilities придают смысл.

Мы перестаём быть просто «группой архитекторов». Мы становимся системой, у которой есть свои ключевые способности, зоны силы, зоны роста. Это позволяет не только показать свою ценность бизнесу, но и самому понять, зачем мы тут и куда развиваемся.

№3. Capabilities позволяют архитектуре становиться более зрелой.

Через зрелость способностей мы управляем не задачами, а системным развитием: процессов, инструментов, навыков, культуры. Мы не просто реагируем на запросы, а создаём фундамент для устойчивой трансформации.

№4. Это мощный инструмент вовлечения и развития команды

Каждый архитектор может:

Выбрать, в какую способность он хочет вложиться.
Прокачать свои личные компетенции.
Внести свой вклад в общее дело.

И это создаёт ту самую среду, в которой появляется инициатива, командная динамика и профессиональный рост.

Он даёт структуру, вовлечённость, прозрачность и самое главное — более осмысленное развитие.

Как мы ввязались в подход «Архитектура через способности» и довели её от абстракции до чего-то осязаемого