Процесс. От лат. prōcēssus «продвижение вперёд», далее из procedere «выходить; продвигаться», далее из pro «вперёд, для, за, вместо» + cedere «идти, ступать», восходит к праиндоевр. *ked- «идти, перемещаться». Русск. процесс — начиная с Петра I; заимств. через нем. Рrоzеss.
1) последовательная смена явлений, состояний в развитии чего-нибудь.
2) Совокупность последовательных действий для достижения какого-либо результата (напр., производственный процесс).
Устойчивая и целенаправленная совокупность взаимосвязанных действий, которые по определённой технологии преобразуют входы в выходы для получения заранее определённых продуктов, результатов или услуг, представляющих ценность для потребителя.
Итак, у процессов есть входы и выходы. Рассмотрим для примера простой процесс продажи товаров в магазине. На входе этого процесса будет корзина покупок, а результатом будет сама покупка. Такое описание процесса не зависит от того, в каком магазине я буду закупаться, всегда у меня будет корзина покупок на входе, которая после оплаты становится покупкой, которую я могу забрать себе домой. Но, допустим, я заказываю товары по телефону в онлайн магазине, и хочу не забыть про весь свой список покупок, для этого я составляю перечень покупок, а после покупки отмечу те позиции, которые я купил, чтобы проверить, не забыл ли чего важного. Тогда моя корзина покупок будет уже выражена списком позиций магазина, а покупка выражена отметками по этому списку. Входы и выходы процесса поменялись. А если я зайду на сайт онлайн-магазина с личным кабинетом, то на входе процесса у меня будет заявка на покупку в личном кабинете, а на выходе подтвержденная заявка на покупку в личном кабинете. Входы и выходы процесса опять поменялись.
Если же я решу купить с того же магазина товары оптом, то на входе у меня будет заполненная ТОРГ-12, а на выходе подписанная ТОРГ-12, и сам процесс изменится, это скорее уже будет продажа товара со склада.
Во всех случаях можно описать происходящее первым шаблоном "Продажа товара в магазине", на входе корзина покупок, на выходе покупка, но формы входов и выходов будут все больше и больше конкретизироваться - от абстрактной информации до документов строгой формы, которые можно обрабатывать машинным способом. В первом случае мы имеем дело со общими понятиями о том, как происходит торговля, в последнем говорим о конкретных технологиях оформления акта покупки-продажи. Или, еще говорят об онтологии предметной области и технологии предметной области. Онтологию важно знать для понимания того, что происходит, что вы видите и к чему вас это обязывает, технологию важно знать, чтобы автоматизировать и выстроить процесс.
Можно рассмотреть процессы в паре, так, чтобы они образовывали транзакцию. Транзакция - это действие, которое либо может произойти от начала до конца, либо, если оно не может завершиться, возвращается к начальному состоянию. Такой возврат называется "откатом транзакции". В торговле такое может произойти если у покупателя не хватает денег либо если она заметила дефект товара на кассе. Тогда покупатель возвращает товар на полку, и транзакция прерывается. В бизнесе есть лишь небольшой набор таких ключевых транзакций, которые описывают бизнес-модель предприятия. Такая модель называется процессной архитектурой либо бизнес-архитектурой, первым про нее написал Dietz в книге Enterprise Ontology. Такая модель, описывающая ключевые транзакции для какой-то бизнес-модели, строится на базе онтологии, а не технологии. Она очень стабильная, компактная и слабо меняется даже при капитальных реорганизациях, смене ERP и руководства. Видеть эти ключевые транзакции очень полезно, т.к. в них заключается суть бизнеса, которая обычно скрыта за фасадом личных отношений, политики, сложной оргструктурой и запутанным ИТ-ландшафтом, и аналитик, который видит эти транзакции, может вовремя задать ключевые вопросы нужным людям. И может быть, эти вопросы и ответы станут началом дискуссии, которая ответит на ключевой вопрос современности: "А чем мы вообще занимаемся?"
Процесс - это непрерывная последовательность действий. Процессы не привязаны к функциональным/предметным областям (доменам знаний). Процессы преобразуют входы в результаты (выходы), то есть объект процесса сохраняет идентичность на всем протяжении процесса, меняя при этом свойства.
Практика = технология + дисциплина. Практика требует применения предметного мышления для определения последовательности действий. Практика всегда привязана к функциональной/предметной области.
Другими словами:
Процесс - воспроизводимый по результатам шаблон действий. Процесс необходим для структурирования обязательств и взаимодействия. "Я действовал как договорились" - это про процесс.
Практика - воспроизводимый по прогнозам шаблон мыслей. Практика необходима для структурирования фактов. "Я так вижу" - это про практику.
Примеры процессов:
1. Сборка и компиляция программного кода. Объект - исполняемый код, от состояния замысленного "должно работать" до состояния "работает на целевой конфигурации". При этом в процессе может быть задействовано несколько предметных областей - среды разработки, операционные системы, драйвера, автоматизированное тестирование.
2. Выпуск книги. Объект - книжное издание, от состояния маркетингово замысла "должно продаваться" до состояния "выложено на полку и рекламируется целевой аудитории". В процессе задействовано несколько предметных областей - создание сюжетов, верстка, реклама.
3. Реализация инвестиционных проектов. Объект - инвестпроект, от состояния "замыслен" до состояния "реализован". В процессе задействовано несколько предметных областей - финансовая оценка, календарно-сетевое планирование, бюджетирование и финконтроль, управление инвестициями.
Процессы могут прерываться, если последовательность шагов не дает необходимого результата или результат процесса становится не нужным.
Процесс выдает заранее заявленный перед его началом результат.
У процесса есть границы - начало и окончание, границы процесса обычно обозначаются событиями.
Практики просто исполняются, там нет границ и последовательностей действий, нет заявленного заранее результата. В буквальном смысле включаем голову и делаем лучшее, что можем.
Примеры практик:
1. Отладка и оптимизация программного кода. Объект на входе определить нельзя, потому что заранее непонятно, что может не работать или плохо работать в программе. Входа как такого нет, потому что отлаживать можно программу, которая выдает невоспроизводимую, но критичную ошибку. Выход, результат, предсказать нельзя, он варьируется.
2. Лечение пациентов. Объект на входе определить нельзя, потому что непонятно, какая болезнь, есть ли болезнь вообще, и можно ли ее вылечить.
3. Маркетинг. Тоже штука непредсказуемая и планировать какие-то цепочки действий наперед сложно.
И процессы и практики можно вызвать, запустить из других процессов или практик. Обычно процессы управленческие запускают основные и обеспечивающие процессы, а процессы верхнего уровня запускают процессы нижнего уровня, но не наоборот. Поэтому для процессов необходимо прописывать, кто имеет право их запускать, какая орг.единица может получить этот сервис, и сколько этот сервис стоит (потому что известна последовательность действий и можно посчитать). Практиками обычно управляют с помощью ограничений таймбоксами и бюджетом - на отладку и тестирование отводится 3 дня, а потом выпускаем что получилось.
Есть тонкая грань между процессами, которые работают с абстрактными объектами типа "инвестиционный проект" и практиками. Всегда есть соблазн сделать обощение и сказать, что практика дечения пациентов - это процесс, где на входе недиагностированный пациент, а на выходе вылеченный человек, и что этот процесс состоит из условно "Диагностики", "Подбора лечения", "Лечения", "Подтверждения выздоровления". Как разделить процессы с абстрактными объектами и практики? Отличий два:
1. У процессов есть сервис, который предоставляется в точке контакта с клиентом процесса. У сервиса есть контракт - стоимость его оказания, результат и условия.
2. У процессов есть границы. Есть начало процесса, четко определенные входы и событие, по которому процесс запускается, и окончание, четко определенные выходы, событие, по которому он завершается.
Красным выделена орг.единица, которая оказывает сервис процесса, синим процесс верхнего уровня, который работает с более абстрактным объектом "паспорт гражданина РФ", голубым текстовыделителем выделены процессы более низкого уровня, которые описывают конкретные сценарии с более частными объектами "данные паспорта РФ", "фотография в паспорте РФ".
Подробности процесса скрыты от клиента, там есть процессы низких уровней - межведомственные запросы, оформления документов и т.п. Этот процесс задействует несколько предметных областей. Но входы и выходы торчат наружу и доступны клиенту процесса. У этого процесса есть контракт - не все могут заказать себе паспорт, а только граждане РФ, у которых нет ограничений на получение паспорта. У контракта есть условия - госпошлина и сроки выдачи и замены документа.
Если в процессе выдачи выявляется что-то, что вызывает прерывание процесса, то включается какая-то практика, в ходе которой разбирается, что же не так и что делать дальше. У этой практики нет границ, нет гарантий. И если процессом занимается орг.единица, то практикой занимается роль. И эту роль могут исполнять разные орг.единицы, люди разных должностей, разных ведомств. Например, если паспорт нельзя выдать из-за того, что нарушено иммиграционное законодательство, то практикой разбирательства будут заниматься чиновники разных ведомств, адвокат и правозащитник. Это все разные орг.звенья, но одна роль "юрист".
Процессами занимается процессный менеджмент, практиками занимается кейс-менеджмент.
По большому счету, можно помедитировать на горбатую диаграмм, чтобы понять разницу между процессами и практиками.
По мере публикации все большего количества книг и оформления все большего количества паспортов, команда накапливает опыт, который можно формализовать моделями процессов и практик. Такой набор оформленных процессов и практик называется методом. Метод нужен для того, чтобы команда могла что-то обосновано обещать своему заказчику. Про методы можете послушать хороший доклад Каждой фазе проекта – своя методология. Как и зачем (Филипп Дельгядо, SECR-2018).
Скоординированные усилия команды с наложенными внешними ограничениями по времени, деньгам, уровню риска и с требованиями к качеству результата называются проектом. Проектом выполняется с применением метода.
Если команда работает без четко определенного результата, просто ведет деятельность и зарабатывает на этом деньги, то это называется направлением деятельности (line of business). Направление деятельности тоже использует метод.
Если у команды есть метод и команда обеспечена ресурсами, достаточными для исполнения этого метода, так, что она может дать исполнимые обещания и принять на себя обязательства, то говорят о том, что у команды есть организационная способность или организационные способности.
Итого, процессы - это цепочки действий с границами и заранее заявленным результатом. Процессы могут быть мультидисциплинарны, пересекать множество предметных областей. У процессов есть сервисы, которые оказывают в точках контакта с клиентами процесса, у этих сервисов есть контракт. На процессы назначаются орг.единицы. Практики монодисциплинарны, там надо думать по какой-то дисциплине (строительство, юриспруденция, врачебное дело, программирование), и понимать логику того, что делаешь. Процессы не требуют понимания сути происходящего, см., например, работу колл-центров. На практики назначаются роли.
Процессы и практики объединяются в метод, с помощью метода исполняются проекты.
Почему бизнес-аналитик или проектный менеджер вряд ли вырастет в системного архитектора, что такое "серый ящик", чем 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
