Современная (SoTA) орг-архитектура
Как всегда, передовые идеи по инженерии надо смотреть в современной литературе по инженерии корпоративных информационных систем, а уже с лагом в десяток лет они появятся в инженерии других видов систем (в том числе инженерии предприятия). Передовые идеи по архитектуре надо тем самым тоже смотреть в литературе по архитектуре корпоративных информационных систем и ожидать далее их появления в практике архитектуры предприятия. Тем не менее, можно уже сегодня использовать эти идеи, строить архитектурную работу на их основе. Эта литература была приведена в курсе «Системная инженерия», самое время вернуться к этому курсу и посмотреть указанную литературу в разделе по архитектуре. Вот основные книги, которые следует хотя бы полистать:
Над каждой книгой стоит год её издания, читать надо слева направо: в 2017 году уточнили понятие архитектуры и в 2022 году выпустили второе издание книги Building Evolutionary Architecture, в 2019 году прояснили каким образом неиерархически думать об оргструктурах в Team Topologies, далее идея архитектуры как отдельной от разработки дисциплины получала развитие по части уточнения как архитектурных характеристик и предложения для них метрик, так и архитектурных паттернов для трудных случаев.
В этот короткий список намеренно не попали книги по архитектуре «железных» систем (там более старые идеи), но попала книга по архитектуре (и оргдизайну) организаций Team Topologies, которая как раз опирается на более-менее свежие архитектурные идеи, которые обсуждаются в современной программной инженерии — и там как раз одна из первых идей касается вредности долго размышлять над организационной иерархией, как это было принято исторически: общение/взаимодействие в командах::оргзвенья и коллективах::оргзвеньях как командах команд идёт не по иерархиям, иерархии затрудняют понимание происходящего, поэтому обсуждаем взаимодействия прежде всего, а не иерархии. А как надо обсуждать взаимодействие команд? Чтение книги даёт какие-то начальные ответы на эти вопросы (в основе там, конечно, обратный манёвр Конвея и понимание различий между основными инженерными ролями — визионера, разработчика, архитектора, инженера платформы). Конечно, если у вас фирма не занимается разработкой корпоративного софта, то советы книги не приложимы впрямую. Но материала наших курсов и материала этих книг достаточно, чтобы вы разобрались с тамошними идеями в части приложения их к вашим организационным реалиям.
Эта современная литература очень контринтуитивна, она противоречит общераспространённым верованиям/мифам про организацию (например, в курсе «Системная инженерия» приводится пример исследования, в котором показывается, что скорости выполнения работы маленькими и большими командами оказываются примерно равными, а вот число дефектов в результатах работы больших команд оказывается больше из-за неизбежного развала конфигурации в силу невозможности точно скоординировать сложную деятельность большого числа людей. Вернитесь к материалу курса «Системная инженерия», найдите это место, посмотрите этот материал с точки зрения идей по архитектуре организации, это ведь не связано с функциональной направленностью работы оргзвена, чем занимался бы оргпроектировщик, это связано с принципами разбиения на оргзвенья, это вопрос орг-архитектора. Оргпроектировщик, конечно, учтёт этот принцип в своей работе — спроектирует организацию с маленькими командами, но вот само указание о том, что команды должны быть маленькие, поступит к нему от орг-архитектора, и ещё орг-архитектор выполнит менторскую функцию, разъясняя оргпроектировщику, почему маленькие команды правильны, и потом ещё выполнит надзор/governance на предмет выполнения этого архитектурного решения).
Материал раздела по орг-архитектуре намеренно короткий (если не считать, что вам обязательно надо прочесть в рамках работы над материалом этого раздела ещё и пару книжек по архитектуре софта и архитектуре организации). Много больше в нашем курсе рассказано (и ещё будет рассказано в следующем разделе, про лидерство) про работу организатора («разработчика» организации), и много меньше — про работу бизнесмена («визионера» организации), орг-архитектора («архитектора» организации), администратора («инженера внутренней платформы разработки/DevOps» организации). Идея тут в том, что большинству придётся так или иначе столкнуться с организацией работы в каком-то проекте — побыть операционным менеджером и менеджером по развитию (оргпроектировщиком, лидером), никуда от этого не деться. И лучше бы это знание разработчика (организатора, в том числе «самоорганизатора» как организатора собственной личности) всем иметь «из коробки», готовое к использованию. А вот знание орг-архитектора и администратора — оно более редкое, поэтому его обязательно нужно иметь на обзорном уровне, чтобы понимать работу архитектора и администратора, когда вы с ними сталкиваетесь, но если вы становитесь профессиональным архитектором и администратором, то вам придётся довольно много доучиваться.