Зашел разговор о том, что казалось бы устоявшуюся в рынке «тройку» Software Acrhitect / Solution Acrhitect / Enterprise Architect никак нельзя считать основанной на «трех видах архитектуры». Это никакие не «виды архитектуры», а просто так оказывается удобно нарезать области ответственности в крупной организации за принятие технических решений разного характера и масштаба. Причем на поверку оказывается, что даже при однаковости названий этих ролей реальная ответственность в организацииях порезана сильно по-разному., так что общей карты даже и не составить. Например, «функциональные архитекторы» в одной организации напоминают «доменных архитекторов» в другой организации, но все же отличаются тем, входит ли в область ответственности решения уровня инфраструктуры.
Если пытаться искать что-то реально устойчивое, то мы найдем скорее не роли, и даже не какие-то хаарктерные предметы/области ответственности, а скорее линии потенциального разреза, по которым разные компании частенько проводят границы. При этом линий этих довольно много, и если порезать по всем этим линиям — получится абсурдно мелко, поэтому каждая компания определяет свой орг-дизайн (а роли — это про орг-дизайн), выбирая какие-то из этих линий, причем на разных уровнях и в разных орг-единицах — набор выбранных линиц разреза может быть совершенно разный и это нормально. Само же (статистическое) существование этих линий гоорит нам о потенциале, о том, что связи поперек этой линии достаточно слабы, так что по ней резать «ну в принципе можно». А вот, например, резать по признаку «фаза ЖЦ клиента» не стоит.
Навскидку описал коротко эти «базовые типовые линии разделения ответственностей, формирующие типовые паттерны ролей архитекторов»:
- Деление «по масштабу«. Оно же стратегия/тактика. Кто-то думает за крупное, кто-то — за части.
- Деление «по бизнесу» — если мы с т.з. системной организации бизнеса видим уже разделенные (по многочисленным возможным бизнес-причинам (из-за функциональной структуры деятельности, масштаба, территориальности, законодательства, истории слияний/поглощений, и т.п.) бизнес-функции или орг-единицы, то это может быть удобная линия разреза для ответственности в ИТ и ролей архитекторов
- Деление «по изменениям» — если идет параллельно несколько проектов изменений, то, хотя это не статические образования, но они достаточно долгие, чтобы за их целостностью нужно было следить и одновременно удерживать scope от расширения (PM), и техническую полноту и реализуемость WBS (architect). Так рождается project/programme/solution architect как роль.
- Деление «по доменам» и поддоменам. Даже в рамках общей орг-структуры можно выделить какие-то поддомены и группы бизнес-функциональности, между которыми слабые связи и свои жаргоны и ubiquity-языки (DDD). Можно делить. Доменный архитектор получается.
- Деление «по техническим системам«. Вот если у нас уже есть несколько технических систем (например включая и софт и инфраструктуру), то дальнейшее ведение их ЖЦ может быть областью ответственности.
- Классическое деление «бизнес»/»ИТ». «Бизнес» тут — это устройство организационной системы, использующей ИТ. Оно аж в язык вошло. По этой линии можно резать.
- Можно взять и поделить софт по линии «функциональность/устройство» (черный/прозрачный ящик). Про это было много копий сломано, но вообще так можно, если и там и там много сложности набирается.
- Можно поделить по линии «свой софт/готовая инфраструктура«. Потому что софт мы проектируем от паттернов и есть много свободы и нужно не переусложнить. А в инфраструктуре мы работаем от того, что есть на рынке и надо знать рынок и свойства готовых продуктов. Четко видная линия разреза.
- Можно делить по viewpoint’ам (аспектам). Но тут традиционно некоторые хорошо выделяются (security, compliance), в которых много регуляции и вообще стандартных проблем-решений, а другие — хуже (performance??? reliability??? сомневаюсь), в которых больше уникальности и больше связей с уникальной функциональностью, и поэтому хуже отделяется. Рынок подсказывает наличием спец-инструментов и специалистов и аутсорсинга по тому же security и secure SDLC.
- Можно делить по видам базовых технологий/платформ, но только если мы в технике тоже можем провести границу со слабыми связями. Например backend-frontend. Или database можно отделить, если там сложно (Oracle) и граница четкая. AWS/OnPremise. Java/.NET.
Не знаю, как еще бывают, но наверное есть.
Можно накидывать еще примеры, если кто видел другую базу для разделения.
Ну вот и получается, что названные типичные паттерны ограничены/сформированы/оформлены несколькими из этих «потенциальных линий разреза».
- «Enterprise Architect» — в ответственности «все предприятие», при этом с тремя опциями по линиям «IT/орг-механизмы/бизнес-модель»
- «Solution Architect» — в ответственности «одна инициатива изменения», иногда включая орг-механизмы, иногда — только IT.
- «Software Architect» — в ответственности отдельная программная техническая система и без инфраструктуры, иногда (все чаще) с указанием экосистемы разработки.
Это не «виды архитектуры», а паттерны нарезки ответственностей (=> ролей и должностей).
Можно добавить, что глубина разделения труда (обычно по этим видам линий) в целом, конечно, растет.
Очередной «эффективный», «удобный», «естественный» для разделения центр или область ответственности формируется под воздействием нескольких трендов:
- укрупнение организаций (Сбер Всё, так что нужно как-то биться по дивизионам, направлениям, филиалам, дочкам, и т.п.)
- усложнение функциональное (нужно делать более крутые штуки) и по показателям качества (терабайты данных, миллионы юзеров, глобальность, гарантии надежности, etc)
- усложнение технологическое (много новых технологий появляется и закрепляется, объем того, чем нужно владеть в сумме чтобы реализовать хоть что-то — растет)
- снижение возраста и уровня общих компетенций в IT (меньше влезает в голову одному человеку, и он хуже понимает/держит много уровней и аспектов)
- появление новых инфраструктур и относительно замкнутых экосистем, которые имеют свои «языки» и т.о. формируют границы. (архитектор AWS != архитектор GCP/Azure, Software Architect Java != Software Architect .NET)
Это очень динамичный процесс, все это плывет и меняется, за 5 лет сильно, особенно «по низам». Но сами разновидности «линий деления» кажутся устойчивыми.
Встречающиеся иногда «списки видов архитекторов и их ответственностей» нам говорят о «естественном» существовании некоторых реперов, устойчивых точек, на которых можно наметить центры областей ответственности. Массовость говорит о том, что там чаще всего локальные оптимумы. Но при этом в конкретной организации можно нарезать как угодно (но лучше по линиям!), и может это даже будет эффективно из-за какой-то специфики организации, ее бизнеса и стратегий. Но в погоне за ачивкой «уникальной стратегии и культуры компании» надо помнить, что любое отклонение от массовой культуры разделения специализаций может и принести бенефиты, но затруднит подбор/подготовку кадров.
Если вы можете объяснить, почему делите в данной орг-единице и на данном уровне ответственности архитекторов именно так, а не иначе, то это значит, что вы осознанно подходите к орг-дизайну, а не просто «скопировали список ролей».
Ну, и надо всегда помнить, что за любое разделение ролей придется платить — дорогой коммуникацией и координацией. Поэтому делить надо тогда, когда по каким-то причинам уже нельзя не делить.