8. Практика архитектуры предприятия

Архитектурные характеристики предприятия

До недавнего времени «архитектурой предприятия» называлась и практика проектирования и моделирования предприятия (практика оргдизайна), совмещённая с собственно архитектурной работой в её современном понимании (как это описано в курсе «Системная инженерия»), и прихват к этой практике работ по проектированию и архитектуре информационных систем предприятия, плюс ещё так могли называть концепцию организации-предприятия, совмещённую с воплощёнными в этой концепции архитектурными решениями.

Сегодня всё это стараются рассматривать отдельно. Так что архитектурная практика для организации — это принятие архитектурных решений по верхнеуровневому составу оргзвеньев и способам взаимодействия оргзвеньев, а также надзора за соблюдением менеджерами по оргразвитию (оргпроектировщиками и лидерами) этих решений. Информационные системы при этом существенны для организации взаимодействия между оргзвеньями, поэтому архитектура организации обычно включает в себя как часть и архитектуру корпоративных информационных систем.

Если оргдизайн распределился по организации, то архитектурой занимаются обычно более централизованно — ибо хорошая архитектура как раз и позволяет распараллелить работу большого числа оргдизайнеров. Тут все те же рассуждения, что и про разработчиков и архитекторов, которые проводились в «Системной инженерии», только это всё разворачивается для организационной системы, которую «разрабатывают» (то есть создают и развивают) менеджеры оргразвития. Общий тренд — это работа множества независимых оргзвеньев как маленьких команд, координируемая через корпоративный софт («организационный экзокортекс»).

Всё это делается для того, чтобы привести в приемлемые значения архитектурные характеристики предприятия (-ilities/-ости, то есть надёжность, масштабируемость и т.д.). Они те же, что и для систем общего вида, небольшое их число отбирается как самые важные для организации и дальше предлагаются меры, чтобы удержать приемлемые для бизнесмена значения этих характеристик. Бизнесмен тут важен, потому как ему надо будет продавать организацию, а её цена будет существенно зависеть от значения этих характеристик. Можно думать об архитектурной работе и так, что оргдизайнеры стремятся удовлетворить прежде всего сиюминутные интересы визионеров (по-быстрому реализовать в организации оргвозможности, позволяющие удовлетворить текущих клиентов, выдать рынку как можно быстрее и дешевле хорошо продающиеся сейчас продукты и сервисы компании), но вот архитекторы следят, что бы формула «деньги сейчас» была более полной (этот вариант был предложен в такой формулировке Элияху Голдраттом): «деньги сейчас и в будущем». Вот архитекторы как раз стоят на страже «денег в будущем»: их задача в том, чтобы организация могла быстро приспособиться к непредвиденным изменениям, которые несёт будущее. В будущем могут быть виражи/pivots (смена направлений деятельности фирмы), резкий рост (проблемы масштабируемости), резкое изменение текущей технологии (переход на иные принципы работы, например, переход к 3D-печати готовых изделий вместо литья заготовок и последующей их долгой обработки), покупка субконтракторов для слияния их организаций с купившей их фирмой, и что угодно ещё. Архитекторы должны держать организацию в форме, которая позволяет это всё «переварить», причём быстро.

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

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

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

Для эволюции сугубо технических систем получены похожие результаты, и там считалось, каким образом можно изолировать ошибки в модулях, если пытаться их улучшить в ходе эволюции. В работе «Role of design complexity in technology improvement»² проверялось, насколько хорошо выполняется примерно тот сюжет, который рассказывает Tony Seba в разделе по стратегированию: насколько при наличии улучшений в отдельных модулях системы мы можем уменьшить цену (или, что то же самое — улучшить характеристики, не меняя цены). Бралось число модулей N, число взаимодействий между модулями (connectivity) D и оценивалось падение цены в зависимости от попыток улучшений при случайных мутациях. Вот результат:

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

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

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

Границы в оргзвеньях невидимы, если «общение софта» двух оргзвеньев ещё как-то можно отследить, то общение людей в двух оргзвеньях отследить крайне сложно. При этом помним о неявных зависимостях, они тоже будут проявляться точно так же, как и в любых других системах. Например, помним, как были популярны в 90х годах идеи повторного использования в софте — и они не выжили, ибо «повторное использование» оказалось замаскированными межмодульными связями: вроде как правишь кусок кода для одного места, а он ломает работу четырёх других мест, где он был «повторно использован». В организациях будут проявляться все те же эффекты.

Исторические подходы к орг-архитектуре

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

• Линейная структура управления, которая выживала лучше всего там, где речь шла о каком-то узком ассортименте и массовом производстве. Компания разбивалась на части (а там ещё на части, и так «до самого низу») по стадиям жизненного цикла, «этапам» (жизненный цикл 1.0) — и там осуществлялась попытка реализовать «водопад» или «конвейер». Во главе стоял начальник (мы говорим о полномочиях) как условный «менеджер проекта/продукта»::роль, чья задача была — выпустить работающий продукт (в голове у него — целевая система). Специалисты по самым разным практикам подчинялись этому «менеджеру проекта» (операционному менеджеру) по иерархии управления. И всё отлично работало, пока продукт был один. Проблемы были, когда продуктов оказалось несколько.

• Функциональная структура управления, в которой учитывалось, что продуктов выпускается много, жизненные циклы у них разные, а функционально все работы делаются специалистами по каким-то практикам. Это соответствовало пониманию жизненного цикла 2.0. Эти специалисты по разным практикам и стали главными, ибо менеджеров проектов было много, и они торговались за то, чтобы какой-нибудь Олег выполнил свою уникальную работу на ограниченном ресурсе этого Олега в его проекте, а не на проекте другого менеджера. Эта структура оказалась более живучей (в голове у функциональных менеджеров была система создания), но и там были проблемы: вечный скандал за ресурсы. А ещё в дело вмешивались администраторы, которые непосредственно в работе не участвовали, но могли запросто перекрыть кислород любому подразделению, если им что-то не нравилось. В ходу был мем про «леди-хранительницу печати», которая была без полномочий и просто ставила печать на бумаги, подписанные боссом. Но когда она невзлюбила какое-то подразделение, то по самым разным очень творчески придумываемым причинам печать на документах этого подразделения не ставилась — то она была всегда «на обеде, вышла» для этого подразделения, то печать ставилась смазанной, то случайно рвался сам документ, и так всегда. Смысл мема в том, что в функциональной структуре была вечная склока борьбы за ресурсы — ибо операционных менеджеров было много.

• Матричная структура управления просто заявила, что она одновременно и линейная, и функциональная. А отдельные люди и отдельные команды подчиняются одновременно и функциональным менеджерам, и менеджерам проектов, причём в случае конфликтов требований они обращаются к своим менеджерам, а те к своим менеджерам, и так до самого верха иерархии, где всё сходилось на генеральном директоре. Формально это было неработоспособно, но по факту работало относительно хорошо: люди уторговывали свои ресурсы в неформальной схеме работы, которая никак не совпадала с формальной структурой полномочий. Поэтому неформально люди понимали, кто в каждой ситуации может давать указания о распределении ресурсов (проектный начальник какого-то уровня или функциональный начальник какого-то оргзвена, связанного с практиками).

• Кроссфункциональные команды стали ответом на вопрос о том, что делать отдельным специалистам в матричной структуре. Люди формально оставались работниками в штатном расписании функциональной структуры (подразделение), но их переводили особыми приказами во временное подчинение проектным менеджерам в команды проектов, набирая команду спецов по всем необходимым практикам (кросс-функционально, «через все практики»). Команда проекта подчинялась начальнику проекта, но люди «числились» за функциональными подразделениями. То есть это по факту было восстановление линейной структуры управления при наличии одновременно и функциональной структуры — но жизнь была уже полегче, ибо функциональная структура не менялась, а вот кроссфункциональные команды менялись. Уже не лихорадило с выплатой зарплаты, уходом в отпуск, обеспечением рабочего места и прочим администрированием, ибо работник вроде как постоянно работал на одном рабочем месте, но по факту его оргзвеном была кроссфункциональная команда — и как только она становилась большой и таких команд становилось много, это наследовало все проблемы линейной организации, функциональной организации и матричной организации с её «неформальными коммуникациями».

• Горизонтальная структура управления была попыткой отразить тот факт, что люди как-то общаются и утрясают свои дела в неформальной структуре, не совпадающей с границами команд. Рассуждения эти питались двумя идеями: 1. Раз уж ни линейная/проектно-продуктная, ни функциональная по практикам работы иерархии не работают, а матричная структура и кроссфункциональные команды не могут решить этих противоречий, то откажемся от них вообще. Как-нибудь разберёмся неформально, позволим общаться людям всем со всеми, сотрудничать во всём. 2. Утопические социалистические идеи коммунального существования (фирма-колхоз, коллективное хозяйство, «у нас тут дружная семья, все занимаются всем, нет должностей/оргмест, свободная работа свободных людей над тем, что им нравится»). Такой «коммунизм», конечно, в природе существует, но обычно где-то там находится какой-то источник сверхприбыли, который обслуживается очень узкой неформальной группой хорошо организованных (то есть все там понимают, кто чем занят, у кого какие роли, кто что кому делает и как быстро) людей, а остальные изображают «семью» вместо рабочего коллектива, при этом нравы в этой семье часто нездоровые. Этот тренд ухода от иерархии в оргструктуре имеет множество названий. Например, пять-восемь лет назад была очень модна холакратия, но лидеры этого подхода успели отказаться от неё в пользу других оргструктур³. Сторонники спиральной динамики⁴ напирают на жёсткую последовательность так называемых «уровней развития», при этом подход общих для всех ступенек развития опровергнут, но до сих пор любят говорить о «бирюзовых/teal организациях», которые тоже игнорируют идею авторитарного подчинения воле руководителя-вождя или даже идею жёсткого следования организационным нормам⁵, что тоже было в острой моде пять-восемь лет назад, и тоже сегодня уже не модно (но помним про растянутость пелотона: люди, которые узнали об этой идее десяток лет назад, до сих пор продолжают говорить о «бирюзовых организациях» как о менеджерском фронтире).

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

В итоге исторически победила формальная функциональная структура, в которой вроде бы считается, что подразделения (не оргзвенья! «подразделения согласно иерархическому штатному расписанию, со структурой подчинения строго по иерархии») организованы 1:1 в соответствии с функциональной декомпозицией (одна практика работы, выполняемая одной организационной ролью, соответствует одному подразделению). Поэтому функциональная декомпозиция по оргролям вроде как была достаточна для понимания концепции организации — а сам такой принцип был как раз архитектурным: «делим всё на оргроли, создаём подразделения, а уж как они общаются — это уж как получится, но при надобности создадим кросс-функциональные команды, в наших архитектурных диаграммах они отражаться не будут». После этого стали популярными изображения типовых функциональный декомпозиций, которые получили название справочных/reference архитектур. Эти типовые функциональные декомпозиции разрабатывались поставщиками корпоративного софта, которым было удобно по подобным диаграммам объяснять, какие функции поддерживает этот софт. Ещё такие функциональные декомпозиции были удобны оргпроектировщикам (называвшим себя архитекторами предприятия), которые брали их за начальную точку в своей работе по оргпроектированию верхнего уровня.

Вот пример справочной архитектуры для банковской деятельности⁶, и обратите внимание на невозможность обсуждения архитектуры — непонятны взаимодействия между отдельными функциями, это не функциональная диаграмма/принципиальная схема предприятия, а именно что декомпозиция функций. То есть вроде как в названии слово «архитектура» есть, а ничего про интерфейсы и взаимодействие модулей мы сказать не можем, обсудить связность/coupling не можем:

Эта справочная архитектура по старой традиции показана в диаграммном языке архитектуры предприятия ArchiMate⁷, и в ней выбраны значки практик::поведение «шеврончики вверх», а названия даны вообще для оргролей::функциональных объектов.

Справочная архитектура предприятия ArchiSurance из примера использования языка ArchiMate выглядит так⁸:

Тут центральное понятие оргвозможности/capabilitities: те же практики, только уже воплощённые, причём у каких-то оргзвеньев есть ресурсы и полномочия для выполнения сервисов согласно этим практикам. Но точно так же нет оргзвеньев и интерфейсов, показывающих их взаимодействие, оргзвенья тут подразумеваются, а не описываются.

Даже диаграммная форма тут лишняя: показана просто функциональная декомпозиция предприятия (отношения часть-целое показаны вложением графических элементов, но могли бы быть показаны стрелочкой с ромбиком на конце, как это рассказывалось в курсе «Системное мышление»). Эти справочные архитектуры вполне могут быть отражены в аутлайне/outlines (иерархическое оглавление, вложенные списки).

Эти типовые/справочные разбиения практик чисто исторически называются «архитектурами». Архитектура занимается не столько функциональными описаниями в концепции системы, сколько накладывает ограничения на конструктивное описание. Орг-архитектура сегодня — это:

• принципы разбиения предприятия на модули (часто и само верхнеуровневое разбиение), то есть на оргзвенья (не только подразделения, но и структуры вне штатного расписания — комиссии, кросс-функциональные программы, интегральные команды введения в эксплуатацию/integrated delivery teams, «производственные кооперации» из организованных согласно договору подрядчиков вне границ текущего юридического лица и т.д.).

• принципы организации взаимодействия этих модулей между собой (интерфейсы, возможность непосредственного взаимодействия оргзвеньев/«видимость модулей», средства коммуникации, способы организации совместной работы).

Мы намеренно не упоминаем в нашем курсе многочисленную литературу по классической архитектуре предприятия, рассказывающие о старинных идеях. Мы намеренно не даём ссылки (то есть не рекомендуем к использованию!) на

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

• стандарты IDEFx (из многочисленных этих стандартов берут главным образом стандарт функциональной декомпозиции IDEF0, но читают его как декомпозицию стадий работ — другой стандарт IDEF3, но это опять оказывается не про архитектуру), моделях Захмана (там общие слова, что «оргпроекты нужно моделировать»),

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

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

• Оргпроект (концепция предприятия и в целом модели деятельности предприятия, раньше «архитектура предприятия»): практики, проекты-процессы-контрольные точки, оргроли и оргзвенья (структура оргзвеньев и их связь: современная орг-архитектура тут), IT-поддержка управления работами.

• Стратегия (раньше «бизнес-архитектура»): бизнес-модель, мотивация (полезность, цели), справимся ли мы (capabilities, resources), с какими партнёрами и на каких рынках. А где «архитектура»? Тут, скорее, прописываются архитектурные решения по структурированию рыночной ниши, которую хочет занять предприятие, реверс-инжиниринг архитектурных решений, которые можно предположить (а иногда при формировании новых рынков и навязать) для надсистем целевой системы предприятия прежде всего, а также для надсистемы предприятия как инвестиционной среды. Ну, и слово «архитектура» тут исторически, от древнего понимания «архитектуры предприятия».

Бизнес-архитекторы, тем не менее, имеют уже свои профессиональные стандарты и корпуса знаний (BABoK⁹ — business analysis body of knowledge, и обратите внимание на ещё один сдвиг в терминологии: уже не бизнес-архитектура, а бизнес-анализ, акцент не на архитектурном синтезе, а на декомпозиции, анализе), свою ассоциацию¹⁰ — и если речь идёт о стратегировании и роли бизнесмена, то вам может быть интересно поработать с этими материалами, только не обращайте внимания на слово «архитектура», когда будете читать тексты этих «аналитиков» (тамошние описания имеют далёкое отношение к принципам разбиения чего бы то ни было на оргзвенья и налаживания интерфейсов между этими оргзвеньями).

TEST Бирюзовая организация

!!! Тимофей начитался книг по горизонтальным организационным структурам и настаивает, чтобы кто угодно мог поручить работу кому угодно, игнорируя организационную структуру. Это он называет «бирюзовой организацией» и призывает всех идти в это светлое будущее. Он прав?

--- да, это написано в современных книгах по менеджменту ### Нет, коммунистическая утопия (очень похожая по описаниям: все всем помогают, и нет главных) тоже аппетитно описана, а результат ровно обратный: террор и ужасы диктатуры. Люди, увольняющиеся из подобных холакратий, горизонтальных и «бирюзовых» организаций и приоткрывающие внутреннее их устройство, свидетельствуют совсем о другом.

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

+++ нет, это приведёт к катастрофе в части операционного менеджмента ### Да, выполнение рекомендаций Тимофея опасно для организации: она потеряет модульную структуру. Вместо отмены неудачно проведённых границ оргзвеньев/подразделений/модулей нужно просто лучше провести эти границы (использовать, например, методики DSM/design structure matrix по улучшению модульности).

Современная (SoTA) орг-архитектура

Как всегда, передовые идеи по инженерии надо смотреть в современной литературе по инженерии корпоративных информационных систем, а уже с лагом в десяток лет они появятся в инженерии других видов систем (в том числе инженерии предприятия). Передовые идеи по архитектуре надо тем самым тоже смотреть в литературе по архитектуре корпоративных информационных систем и ожидать далее их появления в практике архитектуры предприятия. Тем не менее, можно уже сегодня использовать эти идеи, строить архитектурную работу на их основе. Эта литература была приведена в курсе «Системная инженерия», самое время вернуться к этому курсу и посмотреть указанную литературу в разделе по архитектуре. Вот основные книги, которые следует хотя бы полистать:

Над каждой книгой стоит год её издания, читать надо слева направо: в 2017 году уточнили понятие архитектуры и в 2022 году выпустили второе издание книги Building Evolutionary Architecture, в 2019 году прояснили каким образом неиерархически думать об оргструктурах в Team Topologies, далее идея архитектуры как отдельной от разработки дисциплины получала развитие по части уточнения как архитектурных характеристик и предложения для них метрик, так и архитектурных паттернов для трудных случаев.

В этот короткий список намеренно не попали книги по архитектуре «железных» систем (там более старые идеи), но попала книга по архитектуре (и оргдизайну) организаций Team Topologies, которая как раз опирается на более-менее свежие архитектурные идеи, которые обсуждаются в современной программной инженерии — и там как раз одна из первых идей касается вредности долго размышлять над организационной иерархией, как это было принято исторически: общение/взаимодействие в командах::оргзвенья и коллективах::оргзвеньях как командах команд идёт не по иерархиям, иерархии затрудняют понимание происходящего, поэтому обсуждаем взаимодействия прежде всего, а не иерархии. А как надо обсуждать взаимодействие команд? Чтение книги даёт какие-то начальные ответы на эти вопросы (в основе там, конечно, обратный манёвр Конвея и понимание различий между основными инженерными ролями — визионера, разработчика, архитектора, инженера платформы). Конечно, если у вас фирма не занимается разработкой корпоративного софта, то советы книги не приложимы впрямую. Но материала наших курсов и материала этих книг достаточно, чтобы вы разобрались с тамошними идеями в части приложения их к вашим организационным реалиям.

Эта современная литература очень контринтуитивна, она противоречит общераспространённым верованиям/мифам про организацию (например, в курсе «Системная инженерия» приводится пример исследования, в котором показывается, что скорости выполнения работы маленькими и большими командами оказываются примерно равными, а вот число дефектов в результатах работы больших команд оказывается больше из-за неизбежного развала конфигурации в силу невозможности точно скоординировать сложную деятельность большого числа людей. Вернитесь к материалу курса «Системная инженерия», найдите это место, посмотрите этот материал с точки зрения идей по архитектуре организации, это ведь не связано с функциональной направленностью работы оргзвена, чем занимался бы оргпроектировщик, это связано с принципами разбиения на оргзвенья, это вопрос орг-архитектора. Оргпроектировщик, конечно, учтёт этот принцип в своей работе — спроектирует организацию с маленькими командами, но вот само указание о том, что команды должны быть маленькие, поступит к нему от орг-архитектора, и ещё орг-архитектор выполнит менторскую функцию, разъясняя оргпроектировщику, почему маленькие команды правильны, и потом ещё выполнит надзор/governance на предмет выполнения этого архитектурного решения).

Материал раздела по орг-архитектуре намеренно короткий (если не считать, что вам обязательно надо прочесть в рамках работы над материалом этого раздела ещё и пару книжек по архитектуре софта и архитектуре организации). Много больше в нашем курсе рассказано (и ещё будет рассказано в следующем разделе, про лидерство) про работу организатора («разработчика» организации), и много меньше — про работу бизнесмена («визионера» организации), орг-архитектора («архитектора» организации), администратора («инженера внутренней платформы разработки/DevOps» организации). Идея тут в том, что большинству придётся так или иначе столкнуться с организацией работы в каком-то проекте — побыть операционным менеджером и менеджером по развитию (оргпроектировщиком, лидером), никуда от этого не деться. И лучше бы это знание разработчика (организатора, в том числе «самоорганизатора» как организатора собственной личности) всем иметь «из коробки», готовое к использованию. А вот знание орг-архитектора и администратора — оно более редкое, поэтому его обязательно нужно иметь на обзорном уровне, чтобы понимать работу архитектора и администратора, когда вы с ними сталкиваетесь, но если вы становитесь профессиональным архитектором и администратором, то вам придётся довольно много доучиваться.

Задания

Поставьте отметку о выполнении:

1. Прочтена книга Neal Ford, Rebecca Parsons, Patrick Kua «Building Evolutionary Architectures», 2022 (второе издание).

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

3. Прочтена книга Matthew Skelton, Manuel Pais, «Team Topologies», 2019

4. Написан пост с эссе, где вы обсуждаете на основе материала книги Building Evolutionary Architecture, что в книге Team Topologies можно отнести к практикам оргпроектирования, а что к практикам орг-архитектуры.

5. Опубликовано эссе, в котором характеризуется оргструктура (архитектурный стиль) вашей текущей организации. Эта оргструктура линейная, функциональная, матричная, «горизонтальная», или вы её видите как-то по-другому? Какие порождаемые этой оргструктурой основные проблемы наиболее часто обсуждаются в компании? Какие вы могли бы дать предложения по совершенствованию оргструктуры? Приведите примеры орг-архитектурных решений в формате ADR (подробности по этому формату приводились в курсе «Системная инженерия»).