Почему бизнес-аналитик или проектный менеджер вряд ли вырастет в системного архитектора, что такое "серый ящик", чем solution architect отличается от systems architect и от чего зависит количество итераций в проекте.
"Из моей практики видно, что если результатом коммуникации должны быть взятые на себя обязательства, планы или решения. В противном случае это не коммуникация, это что-то другое, это какое-то бесполезное времяпровождение, которое проект дальше по жизненному циклу не продвигает. Такое общение не ведет к успеху проекта".
Лучков Александр, практик-исследователь применимости системного подхода в области проектирования технических систем. Действующий участник российского отделения INCOSE.
Подкаст:
https://anchor.fm/alexander-turkhanov/episodes/ep-e6hkd0
https://podcasts.apple.com/
https://music.yandex.ru/album/8792620
Т. Всем привет. И сегодня мы с Александром Лучковым, системным архитектором. И тема нашего разговора - это как вообще системная архитектура помогает реализовать стратегию предприятия. И, знаете, я не так давно смотрел один фильм Кристофера Нолана, один из последних, "Дюнкерк". Это военная операция второй мировой войны, когда фашисты разгромили Францию на материке, разгромили Великобританию, и Великобритания вытаскивала свои войска с материка, 300,000 человек, к себе обратно на остров. И вот как этот замысел, большой, как он реализовывался в реальной жизни. Реальное месиво, ничего не понятно, что летает, что происходит, военные задания все рушатся, то есть ничего не работает, никакие планы не работают. И как центральным организующим элементом всего этого бардака там служил адмирал, который, собственно и удерживал выполнение замысла вот этой военной операции на земле. И в моем понимании системный архитектор - это тот человек, который во всем многообразии жизни в большом проекте как-то удерживает целостность и реализацию этого замысла. Вот что ты по этому поводу думаешь?
Л. По поводу системного архитектора можно растащить примерно следующие понятия для начала. Первое - это продукт, который вы поставляете в реальной жизни и его воплощение, физические штуки. Второе - знания об этом продукте. Третье - документация об этом продукте. Поскольку вот эти три штуки между собой редко синхронизированы, то нужен кто-то, кто будет за этим следить. Вот этот человек и есть системный архитектор. Если же говорить о том, какую же пользу он приносит организации, то следует упомянуть о законе Конвея, который был сформулирован в виде "структура организации точно копирует структуру создаваемого ею продукта", при этом он работает и в обратную сторону. То есть никакая организация не может создать продукт, который не соответствует ее структуре. Или, по крайней мере, она будет делать его очень неэффективно. Поэтому тот человек, который отвечает за структуру создаваемого продукта, его границы, описания и ограничения, которые на это накладываются, он, по сути, для организации является источником данных о необходимых компетенциях при проектировании и создании этого продукта, о необходимых затратах, планах работ ну и так далее. То есть, это человек, который по сути предоставляет организации основания для собственного самопроектирования.
Т. А чем тогда это отличается от руководителя проекта? Планы, прочее - это ведь все, чем занимается проектный менеджмент?
Л. Проектный менеджмент занимается планами на основании тех данных, которые системный архитектор предоставляет. Поскольку системный архитектор - это не студент со скамьи, это человек, выросший из какой-то глубокой технической экспертизы, у него есть опыт как работы в поле, так и в планировании деятельности, то его данные, его результаты труда, являются основаниями для того, чтобы проектный менеджер имел представления куда копать, куда направлять команду, как правильно приоретизировать распределение ресурсов.
Т. Ну не очень понятно. Вот смотри, ты занимаешься аэронавигационными системами. Ваш продукт - это какая-то аэронавигационная система бортовая или наземная.
Л. В нашем случае наземная или аэродромная.
Т. Наземная или аэродромная, окей. Чем занимается системный архитектор, где эта грань с проектным менеджером?
Л. Проектному менеджеру первое, что дает системный архитектор - это структуры продукта. То есть результат труда - это перечень кусков системы, которые надо сделать. Второе, что он дает - это перечень экспертизы, которую надо привлечь в проектированию и дальнейшей разработке. На каких этапах жизненного цикла какие эксперты должны привлекаться, какими компетенциями обладать, ну и как между собой, по идее, это должно взаимодействовать. Потому что структура продукта, опять же, отражает структуру коммуникаций внутри организации. Если у вас есть два куска системы, которые должны между собой общаться, логично, что два подразделения, которые их создают, должны между собой общаться, чтобы договориться об интерфейсах между этими кусками системы.
Т. То есть он вместе с руководителем проекта пишет эту концепцию эксплуатации, где есть в том числе разделение этих работ в проекте.
Л. Концепция эксплуатации появляется одновременно со следующими штуками. Есть такая замечательная модель, модель многих вершин, twin peaks model, она говорит о том, что у вас постановка задачи всегда появляется одновременно с неким видением, может быть ошибочным, ее воплощения и реализации. Поэтому план коммуникаций и структура продукта и постановка задачи и ограничения системы - это все аспекты одного большого процесса, в который вовлечены как минимум следующие люди. Это бизнес-аналитик, который со стороны заказчика или со стороны потребителя анализирует потребности и выкатывает требования к решению, которое они хотят к себе встроить. С другой стороны, это, конечно же, ребята, которые планируют проверку и приемку в эксплуатацию той продукции, которую вы будете делать. Третьи люди - это как раз проектные менеджеры, которые говорят, а вообще в состоянии ли мы это построить за те ресурсы, которые у нас есть. И четвертый чувак - это как раз системный архитектор, который говорит о способе, которым можно удовлетворить потребности вот этих всех разных, непохожих и зачастую противоположных людей.
Т. Другими словами, системный архитектор с точки зрения реализации стратегии он как раз задает рамку какие работы туда должны войти и как выставлять приоритеты с точки зрения того, как создать тот самый продукт?
Л. По сути, да. То есть он, конечно же общается со всеми остальными, которые там риск-инженеры, инженеры по требованиям, инженеры по испытаниям, но он поддерживает во-первых такую очень важную штуку как методология проектирования в целом, то есть какие картинки рисовать, какой у нас будет план документирования, какие проектные команды участвуют в согласовании каких моделей, какие интересы выражают эти модели ну и прочие вещи. И, соответственно, на основании тех моделей, документов и практик проектирования, которые он предоставляет, и ведется разработка, задается направление развития продукта.
Т. Окей, понятно. Ты обрисовал такую идеальную картинку, а как оно в реально жизни-то? Что не так в реальных проектах?
Л. В реальных проектах обычно есть слабое разделение зон ответственностей разных ролей. С одной стороны архитектурную практику, часть ее, может тащить руководитель проекта, тот, кто работает в должности руководителя проекта. Часть этой же архитектурной практики, определение ключевых решений, разбиение системы на компоненты, может тащить за собой ведущий разработчик, ну и так далее. Очень много людей, которые вступают в роль архитектора, играют роль архитектора, при этом не осознавая того, что это именно архитектурная практика согласно какому-то идеализированному представлению.
Т. Где про эти идеализированные представления можно прочитать?
Л. Идеализированные представления можно почитать в международных стандартах, это, например, ИСО15288, он же ГОСТ 75193, но я рекомендую обращаться к оригиналу. Сейчас действующий вариант от 2015 года, он достаточно качественно описывает архитектурную практику, то есть что сама практика из себя представляет. И если вы замечаете, что вы выполняете какую-то из деятельностей из состава этой практики, значит вы неосознанно или осознанно прыгнули в роль системного архитектора.
Т. Если ты неосознанно выполняешь эту роль системного архитектора, то к чему это приводит? Вкратце, какие последствия?
Л. Неосознанность роли приводит к пропуску существенных аспектов деятельности. Например, вы теряете заинтересованные стороны, вы теряете ключевые требования, вы упускаете из вида жизненный цикл и его этапы, вы упускаете в первую очередь качество вашего продукта. Самый основной риск - это то, что будут ошибочно выстроены коммуникации, ошибочно приняты решения, которые на поздних стадиях жизненного цикла приведут вас либо к провалу либо к банкротству, либо к другим потерям, финансовым, репутационным, зависит от того, чем вы готовы будете платить за ошибочные решения.
Т. Если вспоминать ИСО15288, то там же говорится, что есть черный ящик системы, есть прозрачный ящик системы, и архитектор - это ведь тот, кто работает с прозрачным ящиком? С черным ящиком работает как раз инженер по требованиям?
Л. Если мы рассматриваем ту самую модель многих вершин и итеративную разработку, поскольку у нас по сути весь проект - это уточнение и переход от неопределенности к полной определенности.
Т. То есть мы по V-модели идем вниз?
Л. А потом еще и вверх! От непонимания мы всегда двигаемся к пониманию. За созданное понимание, что оно в принципе создано, описано, утверждено и так далее, за это отвечает системный архитектор, за его исполнение, наполнение, за описание полупрозрачного или серого ящика, который всегда лежит на пути движения от черного ящика к белому ящику тоже он отвечает, в том числе за то, каким образом уточнять описание системы и создаваемого продукта. Методики проектирования, нужные картинки, иногда нужные документы, в том смысле какие документы нам нужно создать и как между собой они должны быть связаны, чтобы наш проект развивался, мы могли его уточнять дальше, передавать на производство, заказывать детальки у поставщиков, собирать на месте, а потом еще денег заработать на том, чтобы это потом еще и утилизировать.
Т. Когда ты так описываешь работу системного архитектора, может сложиться впечатление, что это какой-то методолог, но это же не совсем так?
Л. В частности, одна их функций системного архитектора методическая. Потому что он в том числе определяет набор моделей и средства моделирования. Например, мы делаем все в виде сплошного текста, мы делаем все в виде картинок и UML, или мы делаем все это на основе model-based systems engineering, моделеориентированной системной инженерии или просто на основе моделеориентированной разработки, MDD. Все эти частные подходы и компетенции в области выбора подхода к проектированию и лежат на исполнителе практики системной архитектуры, который, по сути, и есть системный архитектор.
Т. Если говорить про итеративность подходов, то возникает два вопроса - где разница между архитектором частного технического решения, solution architect, и системным архитектором, systems architect? Это первый вопрос. И второй вопрос - если это итеративная разработка, а проекты это всегда итеративная разработка, то от чего зависит количество итераций?
Л. Начнем тогда с первого вопроса. Чем отличается архитектор частного технического решения от архитектора системы в целом? Как несложно догадаться, это зависит в первую очередь от точки зрения. Если то, что я создаю, является частным техническим решением в рамках системы верхнего уровня, как это в умных книжках называется "уровни системной организации". Есть уровень системной организации "надсистема" и есть уровень системной организации "подсистема".7
Т. Это ведь тот самый закон Конвея? Есть проекты, подпроекты, эта картинка есть в ИСО15288?
Л. Есть, вот прямо есть картинка, которая показывает концепты, термины, в которых можно об этом мыслить. Он выделяет несколько типов систем, по сути все системы можно поделить на системы по иерархическому принципу, это как раз надсистема-подсистема-целевая система и системы можно еще поделить по принципу окружения. Потому что у меня есть системы в операционном окружении из тех, с которыми я взаимодействую в эксплуатации, есть системы в обеспечении, обеспечивающие системы, enabling systems, которые "тащат" мою систему по жизненному циклу. По сути, еще интересно было бы подумать в сторону того, что система - это совокупность всех ее моделей, но это уже как раз точка зрения системного архитектора. Так что если у меня есть набор моделей, таких как физическая модель системы, ее воплощение, описание, документальное воплощение, когнитивное, восприятие этой системной модели в голове, поддержание целостности и коммуникаций и соответствия всех этих моделей друг-другу - это прерогатива и суть работы системного архитектора. Чем меньше у нас затраты на коммуникации на проекте, на согласование этих моделей в головах разных людей, чем меньше мы на это тратим времени, тем быстрее движется проект от черного ящика к полностью прозрачному ящику и тем быстрее мы доходим до конечной реализации.
Т. Мне это напоминает метафору кого-то из великих методологов, по-моему Коуберн про это говорил. "Архитектура - это когда команда условно говоря идет по болоту и вешки, которые они оставили, и есть архитектуры. Вопрос, понятны они только этой команде или эти вешки и карты понятны другим тоже, насколько вы документируете этот путь?
Л. Да, именно так. По сути, у архитектурной практики есть несколько задач. Первое - она всегда должна соответствовать стратегии развития продукта. У вас есть цель вашего предприятия, цель вашего существования как предприятия, вашей команды, если у вас архитектурная практика противоречит вашим целям, то логично, что продукт, который вы создаете, методы, которыми вы пользуетесь, скорее всего приведут вас в очень неприятное положение.
Т. То есть надо согласовывать между собой стратегию, проектные планы и методологию системной архитектуры?
Л. Более того, точность и структура вашей организации, матрицы ответственности и тем более стоимостное разбиение работ, cost breakdown structure, априори всегда либо менее точны либо равны по точности определенности ваших технических решений.
Т. Это да. Меня, как руководителя проекта, всегда веселило, когда от меня менеджмент требовал бюджетов более точных, чем у меня было техническое решение. Теперь возвращаемся к итерациям. От чего зависит количество итераций и при чем тут архитектор?
Л. От качества коммуникаций. Качество коммуникаций определяется тем, насколько быстро и эффективно, насколько терминологически согласованы у вас документы, которые вы обсуждаете. Насколько хорошо проработан язык проекта. Так называемый ubiquitous language или project language, словарь проекта и так далее. Это большой кусок работы архитектора, который он делит обычно с системным аналитиком. По сути ведение глоссария, само ведение - это роль системного аналитика, а вот способ наполнения глоссария, способ выявления концептов, сущностей и их определение - это методическая роль системного архитектора.
Т. А что мы подразумеваем под коммуникацией? Классический ППР или все-таки коммуникацию в прагматическом плане, что в ней должно быть что-то содержательное?
Л. Из моей практики видно, что если результатом коммуникации должны быть взятые на себя обязательства, планы или решения. В противном случае это не коммуникация, это что-то другое, это какое-то бесполезное времяпровождение, которое проект дальше по жизненному циклу не продвигает. Такое общение не ведет к успеху проекта.
Т. То есть коммуникация - это принятые решения и планы каждой из сторон, которая участвует в коммуникациях, по тому, как это решение будет реализовано?
Л. Да, это как раз про движение по жизненному циклу, уточнение "серого" ящика в сторону "прозрачного" и только когда такое уточнение необходимо, нужна коммуникация. Если у меня существует неопределенность, которую я не в состоянии снять сам, я спрашиваю других, что с этим делать. Вот у меня есть неопределенность, ее надо снимать.
Т. То есть системный архитектор - это такой mastermind, который соединяет разных людей и способен их скоммуницировать так, чтобы они приняли решение, которое взялись бы дальше исполнить?
Л. Да, в том числе. Это человек, который владеет своей экспертизой в какой-то предметной области очень глубоко, он погружен в "предметку" того контекста деятельности, которую он осуществляет, то есть, например, если он создает метеорологические системы, он должен иметь опыт работы с информационными системами, метеорологическими системами и службами, понимать процессы, которые в них происходят. Если такого опыта нет, то ему будет крайне сложно предоставлять качественные технические решения и интегрировать команду вокруг своих методов работы и описаний.
Т. Тогда сразу появляется вопрос, а с каких позиций в проекте можно вырасти в системного архитектора, а из каких нельзя?
Л. На практике выходит примерно следующее. Если у человека есть техническая экспертиза и он ее готов углублять до осознанного уровня применения, то вырастить можно практически из любого человека. Но если у человека есть только теоретическая база, например, экономическая, аналитическая, управленческая, то качественных системных архитекторов из таких людей, как правило, не выходит. Хорошие архитекторы выходит из ведущих разработчиков, из саппорта, из инженеров по эксплуатации, ну и так далее, то есть из тех людей, которые выполняли какие-то конкретные объемы работ, представляют конкретные стадии жизненного цикла, что должно быть на входе, что должно быть на выходе и какой контекст существует, в каких терминах можно общаться с командой.
Т. "Контекст" имеется в виду контекст конкретной организации? Или можно нанять такого человека с рынка, хорошего разработчика, и выращивать из него системного архитектора?
Л. Я думаю, что последнее. Можно найти на рынке людей, которые будут хорошо ориентироваться и хорошо входить в предметную область деятельности компании и выстраивать траекторию их личного роста внутри компании в сторону системного архитектора.
Т. Что-нибудь еще можешь сказать по этому поводу? Как собеседовать таких людей, где их искать?
Л. Искать в первую очередь стоит не через кадровые агентства и не на рынках, а внутри профессиональных сообществ. То есть мы говорим про какую-то сферу банковских услуг и мы знаем, что у нас в стране есть четыре десятка людей, которые занимаются архитектурой в банковском и финансовом секторе, они все друг-друга знают, поскольку банки - это не такая обширная сфера. Мы можем к ним прийти, и через этих людей, через площадки их профессионального общения имеет смысл искать кадры для подготовки системных архитекторов в сфере банковских услуг. Если мы говорим про айтишную сферу, про продукты масс-маркет, то тут ситуация чуть проще, можно таких ребят выращивать на стартапах. Они буду понимать предметную область продукта, который вы создаете, и предметную область услуги, которую вы оказываете своим продуктом. Из таких стартапов тоже могут выйти качественные системные архитекторы. Но еще раз повторюсь, что архитектор очень редко бывает сразу "с колес" готов к полноценной работе в текущем производственном процессе. Это обязательно человек, который должен понимать, как методически устроен ваш коллектив, какие там есть процессы коммуникации внутри, какие процессы коммуникации должны быть для создания определенной системы или класса систем, если вы создаете новый продукт и иметь сильную техническую экспертизу, чтобы не попадать впросак на простых вещах.
Т. Ясно. Это было кратко и содержательно, спасибо тебе.
Л. На здоровье.
Что почитать по теме?
Model‐Based System Architecture
Author(s): Tim Weilkiens Jesko G. Lamm Stephan Roth Markus Walker
First published:21 September 2015
https://onlinelibrary.wiley.com/doi/book/10.1002/9781119051930
Documenting Software Architectures: Views and Beyond, Second Edition
Felix Bachmann, Len Bass, Paul C. Clements, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith A. Stafford
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513862
System Architecture: Strategy and Product Development for Complex Systems
by Edward Crawley Bruce Cameron Daniel Selva
https://www.amazon.com/System-Architecture-Strategy-Product-Development/dp/0133975347
"Из моей практики видно, что если результатом коммуникации должны быть взятые на себя обязательства, планы или решения. В противном случае это не коммуникация, это что-то другое, это какое-то бесполезное времяпровождение, которое проект дальше по жизненному циклу не продвигает. Такое общение не ведет к успеху проекта".
Лучков Александр, практик-исследователь применимости системного подхода в области проектирования технических систем. Действующий участник российского отделения INCOSE.
Подкаст:
https://anchor.fm/alexander-turkhanov/episodes/ep-e6hkd0
https://podcasts.apple.com/
https://music.yandex.ru/album/8792620
Т. Всем привет. И сегодня мы с Александром Лучковым, системным архитектором. И тема нашего разговора - это как вообще системная архитектура помогает реализовать стратегию предприятия. И, знаете, я не так давно смотрел один фильм Кристофера Нолана, один из последних, "Дюнкерк". Это военная операция второй мировой войны, когда фашисты разгромили Францию на материке, разгромили Великобританию, и Великобритания вытаскивала свои войска с материка, 300,000 человек, к себе обратно на остров. И вот как этот замысел, большой, как он реализовывался в реальной жизни. Реальное месиво, ничего не понятно, что летает, что происходит, военные задания все рушатся, то есть ничего не работает, никакие планы не работают. И как центральным организующим элементом всего этого бардака там служил адмирал, который, собственно и удерживал выполнение замысла вот этой военной операции на земле. И в моем понимании системный архитектор - это тот человек, который во всем многообразии жизни в большом проекте как-то удерживает целостность и реализацию этого замысла. Вот что ты по этому поводу думаешь?
Л. По поводу системного архитектора можно растащить примерно следующие понятия для начала. Первое - это продукт, который вы поставляете в реальной жизни и его воплощение, физические штуки. Второе - знания об этом продукте. Третье - документация об этом продукте. Поскольку вот эти три штуки между собой редко синхронизированы, то нужен кто-то, кто будет за этим следить. Вот этот человек и есть системный архитектор. Если же говорить о том, какую же пользу он приносит организации, то следует упомянуть о законе Конвея, который был сформулирован в виде "структура организации точно копирует структуру создаваемого ею продукта", при этом он работает и в обратную сторону. То есть никакая организация не может создать продукт, который не соответствует ее структуре. Или, по крайней мере, она будет делать его очень неэффективно. Поэтому тот человек, который отвечает за структуру создаваемого продукта, его границы, описания и ограничения, которые на это накладываются, он, по сути, для организации является источником данных о необходимых компетенциях при проектировании и создании этого продукта, о необходимых затратах, планах работ ну и так далее. То есть, это человек, который по сути предоставляет организации основания для собственного самопроектирования.
Т. А чем тогда это отличается от руководителя проекта? Планы, прочее - это ведь все, чем занимается проектный менеджмент?
Л. Проектный менеджмент занимается планами на основании тех данных, которые системный архитектор предоставляет. Поскольку системный архитектор - это не студент со скамьи, это человек, выросший из какой-то глубокой технической экспертизы, у него есть опыт как работы в поле, так и в планировании деятельности, то его данные, его результаты труда, являются основаниями для того, чтобы проектный менеджер имел представления куда копать, куда направлять команду, как правильно приоретизировать распределение ресурсов.
Т. Ну не очень понятно. Вот смотри, ты занимаешься аэронавигационными системами. Ваш продукт - это какая-то аэронавигационная система бортовая или наземная.
Л. В нашем случае наземная или аэродромная.
Т. Наземная или аэродромная, окей. Чем занимается системный архитектор, где эта грань с проектным менеджером?
Л. Проектному менеджеру первое, что дает системный архитектор - это структуры продукта. То есть результат труда - это перечень кусков системы, которые надо сделать. Второе, что он дает - это перечень экспертизы, которую надо привлечь в проектированию и дальнейшей разработке. На каких этапах жизненного цикла какие эксперты должны привлекаться, какими компетенциями обладать, ну и как между собой, по идее, это должно взаимодействовать. Потому что структура продукта, опять же, отражает структуру коммуникаций внутри организации. Если у вас есть два куска системы, которые должны между собой общаться, логично, что два подразделения, которые их создают, должны между собой общаться, чтобы договориться об интерфейсах между этими кусками системы.
Т. То есть он вместе с руководителем проекта пишет эту концепцию эксплуатации, где есть в том числе разделение этих работ в проекте.
Л. Концепция эксплуатации появляется одновременно со следующими штуками. Есть такая замечательная модель, модель многих вершин, twin peaks model, она говорит о том, что у вас постановка задачи всегда появляется одновременно с неким видением, может быть ошибочным, ее воплощения и реализации. Поэтому план коммуникаций и структура продукта и постановка задачи и ограничения системы - это все аспекты одного большого процесса, в который вовлечены как минимум следующие люди. Это бизнес-аналитик, который со стороны заказчика или со стороны потребителя анализирует потребности и выкатывает требования к решению, которое они хотят к себе встроить. С другой стороны, это, конечно же, ребята, которые планируют проверку и приемку в эксплуатацию той продукции, которую вы будете делать. Третьи люди - это как раз проектные менеджеры, которые говорят, а вообще в состоянии ли мы это построить за те ресурсы, которые у нас есть. И четвертый чувак - это как раз системный архитектор, который говорит о способе, которым можно удовлетворить потребности вот этих всех разных, непохожих и зачастую противоположных людей.
Л. По сути, да. То есть он, конечно же общается со всеми остальными, которые там риск-инженеры, инженеры по требованиям, инженеры по испытаниям, но он поддерживает во-первых такую очень важную штуку как методология проектирования в целом, то есть какие картинки рисовать, какой у нас будет план документирования, какие проектные команды участвуют в согласовании каких моделей, какие интересы выражают эти модели ну и прочие вещи. И, соответственно, на основании тех моделей, документов и практик проектирования, которые он предоставляет, и ведется разработка, задается направление развития продукта.
Т. Окей, понятно. Ты обрисовал такую идеальную картинку, а как оно в реально жизни-то? Что не так в реальных проектах?
Л. В реальных проектах обычно есть слабое разделение зон ответственностей разных ролей. С одной стороны архитектурную практику, часть ее, может тащить руководитель проекта, тот, кто работает в должности руководителя проекта. Часть этой же архитектурной практики, определение ключевых решений, разбиение системы на компоненты, может тащить за собой ведущий разработчик, ну и так далее. Очень много людей, которые вступают в роль архитектора, играют роль архитектора, при этом не осознавая того, что это именно архитектурная практика согласно какому-то идеализированному представлению.
Т. Где про эти идеализированные представления можно прочитать?
Л. Идеализированные представления можно почитать в международных стандартах, это, например, ИСО15288, он же ГОСТ 75193, но я рекомендую обращаться к оригиналу. Сейчас действующий вариант от 2015 года, он достаточно качественно описывает архитектурную практику, то есть что сама практика из себя представляет. И если вы замечаете, что вы выполняете какую-то из деятельностей из состава этой практики, значит вы неосознанно или осознанно прыгнули в роль системного архитектора.
Т. Если ты неосознанно выполняешь эту роль системного архитектора, то к чему это приводит? Вкратце, какие последствия?
Л. Неосознанность роли приводит к пропуску существенных аспектов деятельности. Например, вы теряете заинтересованные стороны, вы теряете ключевые требования, вы упускаете из вида жизненный цикл и его этапы, вы упускаете в первую очередь качество вашего продукта. Самый основной риск - это то, что будут ошибочно выстроены коммуникации, ошибочно приняты решения, которые на поздних стадиях жизненного цикла приведут вас либо к провалу либо к банкротству, либо к другим потерям, финансовым, репутационным, зависит от того, чем вы готовы будете платить за ошибочные решения.
Т. Если вспоминать ИСО15288, то там же говорится, что есть черный ящик системы, есть прозрачный ящик системы, и архитектор - это ведь тот, кто работает с прозрачным ящиком? С черным ящиком работает как раз инженер по требованиям?
Л. Если мы рассматриваем ту самую модель многих вершин и итеративную разработку, поскольку у нас по сути весь проект - это уточнение и переход от неопределенности к полной определенности.
Т. То есть мы по V-модели идем вниз?
Л. А потом еще и вверх! От непонимания мы всегда двигаемся к пониманию. За созданное понимание, что оно в принципе создано, описано, утверждено и так далее, за это отвечает системный архитектор, за его исполнение, наполнение, за описание полупрозрачного или серого ящика, который всегда лежит на пути движения от черного ящика к белому ящику тоже он отвечает, в том числе за то, каким образом уточнять описание системы и создаваемого продукта. Методики проектирования, нужные картинки, иногда нужные документы, в том смысле какие документы нам нужно создать и как между собой они должны быть связаны, чтобы наш проект развивался, мы могли его уточнять дальше, передавать на производство, заказывать детальки у поставщиков, собирать на месте, а потом еще денег заработать на том, чтобы это потом еще и утилизировать.
Т. Когда ты так описываешь работу системного архитектора, может сложиться впечатление, что это какой-то методолог, но это же не совсем так?
Л. В частности, одна их функций системного архитектора методическая. Потому что он в том числе определяет набор моделей и средства моделирования. Например, мы делаем все в виде сплошного текста, мы делаем все в виде картинок и UML, или мы делаем все это на основе model-based systems engineering, моделеориентированной системной инженерии или просто на основе моделеориентированной разработки, MDD. Все эти частные подходы и компетенции в области выбора подхода к проектированию и лежат на исполнителе практики системной архитектуры, который, по сути, и есть системный архитектор.
Т. Если говорить про итеративность подходов, то возникает два вопроса - где разница между архитектором частного технического решения, solution architect, и системным архитектором, systems architect? Это первый вопрос. И второй вопрос - если это итеративная разработка, а проекты это всегда итеративная разработка, то от чего зависит количество итераций?
Л. Начнем тогда с первого вопроса. Чем отличается архитектор частного технического решения от архитектора системы в целом? Как несложно догадаться, это зависит в первую очередь от точки зрения. Если то, что я создаю, является частным техническим решением в рамках системы верхнего уровня, как это в умных книжках называется "уровни системной организации". Есть уровень системной организации "надсистема" и есть уровень системной организации "подсистема".7
Т. Это ведь тот самый закон Конвея? Есть проекты, подпроекты, эта картинка есть в ИСО15288?
Л. Есть, вот прямо есть картинка, которая показывает концепты, термины, в которых можно об этом мыслить. Он выделяет несколько типов систем, по сути все системы можно поделить на системы по иерархическому принципу, это как раз надсистема-подсистема-целевая система и системы можно еще поделить по принципу окружения. Потому что у меня есть системы в операционном окружении из тех, с которыми я взаимодействую в эксплуатации, есть системы в обеспечении, обеспечивающие системы, enabling systems, которые "тащат" мою систему по жизненному циклу. По сути, еще интересно было бы подумать в сторону того, что система - это совокупность всех ее моделей, но это уже как раз точка зрения системного архитектора. Так что если у меня есть набор моделей, таких как физическая модель системы, ее воплощение, описание, документальное воплощение, когнитивное, восприятие этой системной модели в голове, поддержание целостности и коммуникаций и соответствия всех этих моделей друг-другу - это прерогатива и суть работы системного архитектора. Чем меньше у нас затраты на коммуникации на проекте, на согласование этих моделей в головах разных людей, чем меньше мы на это тратим времени, тем быстрее движется проект от черного ящика к полностью прозрачному ящику и тем быстрее мы доходим до конечной реализации.
Т. Мне это напоминает метафору кого-то из великих методологов, по-моему Коуберн про это говорил. "Архитектура - это когда команда условно говоря идет по болоту и вешки, которые они оставили, и есть архитектуры. Вопрос, понятны они только этой команде или эти вешки и карты понятны другим тоже, насколько вы документируете этот путь?
Л. Да, именно так. По сути, у архитектурной практики есть несколько задач. Первое - она всегда должна соответствовать стратегии развития продукта. У вас есть цель вашего предприятия, цель вашего существования как предприятия, вашей команды, если у вас архитектурная практика противоречит вашим целям, то логично, что продукт, который вы создаете, методы, которыми вы пользуетесь, скорее всего приведут вас в очень неприятное положение.
Т. То есть надо согласовывать между собой стратегию, проектные планы и методологию системной архитектуры?
Л. Более того, точность и структура вашей организации, матрицы ответственности и тем более стоимостное разбиение работ, cost breakdown structure, априори всегда либо менее точны либо равны по точности определенности ваших технических решений.
Т. Это да. Меня, как руководителя проекта, всегда веселило, когда от меня менеджмент требовал бюджетов более точных, чем у меня было техническое решение. Теперь возвращаемся к итерациям. От чего зависит количество итераций и при чем тут архитектор?
Л. От качества коммуникаций. Качество коммуникаций определяется тем, насколько быстро и эффективно, насколько терминологически согласованы у вас документы, которые вы обсуждаете. Насколько хорошо проработан язык проекта. Так называемый ubiquitous language или project language, словарь проекта и так далее. Это большой кусок работы архитектора, который он делит обычно с системным аналитиком. По сути ведение глоссария, само ведение - это роль системного аналитика, а вот способ наполнения глоссария, способ выявления концептов, сущностей и их определение - это методическая роль системного архитектора.
Т. А что мы подразумеваем под коммуникацией? Классический ППР или все-таки коммуникацию в прагматическом плане, что в ней должно быть что-то содержательное?
Л. Из моей практики видно, что если результатом коммуникации должны быть взятые на себя обязательства, планы или решения. В противном случае это не коммуникация, это что-то другое, это какое-то бесполезное времяпровождение, которое проект дальше по жизненному циклу не продвигает. Такое общение не ведет к успеху проекта.
Т. То есть коммуникация - это принятые решения и планы каждой из сторон, которая участвует в коммуникациях, по тому, как это решение будет реализовано?
Л. Да, это как раз про движение по жизненному циклу, уточнение "серого" ящика в сторону "прозрачного" и только когда такое уточнение необходимо, нужна коммуникация. Если у меня существует неопределенность, которую я не в состоянии снять сам, я спрашиваю других, что с этим делать. Вот у меня есть неопределенность, ее надо снимать.
Т. То есть системный архитектор - это такой mastermind, который соединяет разных людей и способен их скоммуницировать так, чтобы они приняли решение, которое взялись бы дальше исполнить?
Л. Да, в том числе. Это человек, который владеет своей экспертизой в какой-то предметной области очень глубоко, он погружен в "предметку" того контекста деятельности, которую он осуществляет, то есть, например, если он создает метеорологические системы, он должен иметь опыт работы с информационными системами, метеорологическими системами и службами, понимать процессы, которые в них происходят. Если такого опыта нет, то ему будет крайне сложно предоставлять качественные технические решения и интегрировать команду вокруг своих методов работы и описаний.
Т. Тогда сразу появляется вопрос, а с каких позиций в проекте можно вырасти в системного архитектора, а из каких нельзя?
Л. На практике выходит примерно следующее. Если у человека есть техническая экспертиза и он ее готов углублять до осознанного уровня применения, то вырастить можно практически из любого человека. Но если у человека есть только теоретическая база, например, экономическая, аналитическая, управленческая, то качественных системных архитекторов из таких людей, как правило, не выходит. Хорошие архитекторы выходит из ведущих разработчиков, из саппорта, из инженеров по эксплуатации, ну и так далее, то есть из тех людей, которые выполняли какие-то конкретные объемы работ, представляют конкретные стадии жизненного цикла, что должно быть на входе, что должно быть на выходе и какой контекст существует, в каких терминах можно общаться с командой.
Т. "Контекст" имеется в виду контекст конкретной организации? Или можно нанять такого человека с рынка, хорошего разработчика, и выращивать из него системного архитектора?
Л. Я думаю, что последнее. Можно найти на рынке людей, которые будут хорошо ориентироваться и хорошо входить в предметную область деятельности компании и выстраивать траекторию их личного роста внутри компании в сторону системного архитектора.
Т. Что-нибудь еще можешь сказать по этому поводу? Как собеседовать таких людей, где их искать?
Л. Искать в первую очередь стоит не через кадровые агентства и не на рынках, а внутри профессиональных сообществ. То есть мы говорим про какую-то сферу банковских услуг и мы знаем, что у нас в стране есть четыре десятка людей, которые занимаются архитектурой в банковском и финансовом секторе, они все друг-друга знают, поскольку банки - это не такая обширная сфера. Мы можем к ним прийти, и через этих людей, через площадки их профессионального общения имеет смысл искать кадры для подготовки системных архитекторов в сфере банковских услуг. Если мы говорим про айтишную сферу, про продукты масс-маркет, то тут ситуация чуть проще, можно таких ребят выращивать на стартапах. Они буду понимать предметную область продукта, который вы создаете, и предметную область услуги, которую вы оказываете своим продуктом. Из таких стартапов тоже могут выйти качественные системные архитекторы. Но еще раз повторюсь, что архитектор очень редко бывает сразу "с колес" готов к полноценной работе в текущем производственном процессе. Это обязательно человек, который должен понимать, как методически устроен ваш коллектив, какие там есть процессы коммуникации внутри, какие процессы коммуникации должны быть для создания определенной системы или класса систем, если вы создаете новый продукт и иметь сильную техническую экспертизу, чтобы не попадать впросак на простых вещах.
Т. Ясно. Это было кратко и содержательно, спасибо тебе.
Л. На здоровье.
Что почитать по теме?
Model‐Based System Architecture
Author(s): Tim Weilkiens Jesko G. Lamm Stephan Roth Markus Walker
First published:21 September 2015
https://onlinelibrary.wiley.com/doi/book/10.1002/9781119051930
Documenting Software Architectures: Views and Beyond, Second Edition
Felix Bachmann, Len Bass, Paul C. Clements, David Garlan, James Ivers, Reed Little, Paulo Merson, Robert Nord, Judith A. Stafford
https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=513862
System Architecture: Strategy and Product Development for Complex Systems
by Edward Crawley Bruce Cameron Daniel Selva
https://www.amazon.com/System-Architecture-Strategy-Product-Development/dp/0133975347
Комментариев нет:
Отправить комментарий