Architectura Ab Initio

25 комментариев
Architectura Ab Initio

Senior Solution Architect в EPAM и победитель премии Belarus IT Awards в номинации «Ambassador of Enterprise Backend» Иван Подобед пишет в своей колонке об основах и границах понятия ИТ-архитектуры. 

Читать далее

Не графоманства ради, но для вящего развлечения почтенной публики, хотелось мне представить свой ответ на вопрос «Кто есть ИT-архитектор?». Однако же в процессе написания пришло (внезапно) понимание того, что неплохо было бы начать кратенько с корней — что есть ИT-архитектура. Несовпадение с мнением уважаемой редакции, не менее уважаемой компании-работодателя и очень уважаемой аудитории ресурса допускается и даже весьма вероятно. Далее по тексту термин архитектура будет использоваться в узком смысле — как IT/Software-архитектура, если явно не указано другое.

Приступим. А зачем вообще нужна эта самая архитектура?

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

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

Как вы догадываетесь, замахнулся я довольно широко. Оправдано ли это? Посмотрим на определения. Начнем с варианта, предложенного одной международной инженерной организацией:

Architecture is a system fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution (IEEE 1471).

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

Фото: Kesara Rathnayake via Flickr.

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

Гибкие методологии тоже не панацея, ибо они скорее о том, что заказчик хочет, чем о том, что ему на самом деле нужно. Но это уже совсем другая история, и не мне её рассказывать. Задержусь лишь для того, чтобы оставить тут концепцию Architectural Runway как мост между Agile-принципами и архитектурой.

Степень проникновения нетехнических элементов (и превращения их в технические с помощью нехитрых приёмов) определяет основные уровни архитектуры.

  1. Техническая архитектура, оперирующая как раз на уровне кода, подключаемых пакетов, библиотек и фреймворков; бизнес проникает сюда обычно в стартапном режиме либо в виде спецификации требований (она же бывает и в виде бэклога).
     
  2. Архитектура решений (Solution architecture), работающая в границах одной или нескольких технических платформ; бизнес устанавливает цели и метрики проекта, а также входные ограничения (обычно в виде бюджета и сроков), приоритетные атрибуты качества и способы их достижения уже в зоне ответственности системы.
     
  3. Enterprise-архитектура, работающая с целями и стратегией бизнеса напрямую, помогая формировать техническую стратегию достижения бизнес целей и устанавливая входные данные для архитектуры программных решений.

Весь в надежде на продуктивное обсуждение и комментарии, морально готовлюсь к заходу уже на святое — на реальную область ответственности архитектора.

 

 

*Мнение колумнистов может не совпадать с позицией редакции.

Читайте также

14 лучших технологий уходящего десятилетия
14 лучших технологий уходящего десятилетия

14 лучших технологий уходящего десятилетия

Baidu опередила Google на мировом рынке смарт-колонок
Baidu опередила Google на мировом рынке смарт-колонок

Baidu опередила Google на мировом рынке смарт-колонок

«Многие называют нас сектой, но денег мы туда не несём». Иван Подобед — о системной инженерии
«Многие называют нас сектой, но денег мы туда не несём». Иван Подобед — о системной инженерии

«Многие называют нас сектой, но денег мы туда не несём». Иван Подобед — о системной инженерии

29 комментариев
Ubisoft бесплатно раздаёт Assassin’s Creed Unity, где одна из локаций — виртуальная копия Нотр-Дам-де-Пари
Ubisoft бесплатно раздаёт Assassin’s Creed Unity, где одна из локаций — виртуальная копия Нотр-Дам-де-Пари

Ubisoft бесплатно раздаёт Assassin’s Creed Unity, где одна из локаций — виртуальная копия Нотр-Дам-де-Пари

Обсуждение

3

Вы так чётенько пишете, что я могу только:
1. Похвалить картинку.
2. Погрустить за "софтваре архитекторов", которых вы, похоже, не очень любите.
3. Попросить писать еще.

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
2

спасибо, приятно хоть ненадолго представить себя чётенким пацанчиком :) хотя
1. картинка не моя, спасибо редакции девбай
2. я сам софтваре архитектор, и таки да, я себя не очень люблю :/
3. принято, напрягусь

0

Не графоманства ради, но для вящего развлечения почтенной публики, хотелось мне представить свой ответ на вопрос «Кто есть ИT-архитектор?».

И кто? :)

Ну как то ожидал чуть большего от статьи, нежели вариации из трех вариантов границ натянутых на "Architecture is a system fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution".

Ну просто можно было бы (в силу разнообразия IT) не просто выделить какие три направления, а например (и может даже веселее), выделив два... скажем Solution Architect и Enterprise Architect, столкнуть адептов формулировок, задав вопрос "кто круче?". Потому какой толк обсуждать святое (обязанности), ведь вы сами легко и непринужденно выделили три типа архитекторов у каждого из которых свой круг ответственности, а при желании типов то выделить можно и больше и у каждого среди обязанностей будут свои, уникальные в своей области.

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
2

вай, кому-то таки интересен ответ? )) он будет, как и обещано в статье, в следующей части, ибо вытекает он как ни странно из определения и из того, что я на него натянул.
и не могу не согласиться насчет типов архитекторов, к ним вернусь
*оглядываясь и понижая голос* их десятки, этих типов! *нервно оглядываясь, убегает*

3

Иван, если это возможно, постарайтесь осветить тему как стать хорошим ИТ-архитектором (софтваре). Что почитать/посмотреть? Метрики по которым можно оценить качество архитектуры. Понятно, что на эту тему писано-переписано, но может у вас есть свой секрет, свой набор литературы. Поделитесь своими практиками, секретами, да и вообще как вы пришли в архитекторы, что приходилось решать, чем гордитесь и т.п. Скажем так было бы интереснее узнать success story человека которого "можно потрогать" чем абстрактные размышления на тему ху из ху.

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
1

ух, если честно, не очень люблю учить таким неоднозначным вещам как "необходимые шаги становления хорошего софтваре архитектора" :( боюсь, что только очень общие рекомендации - в работе не забывать об учебе, приучить себя находить причины всего (почему выбрана технология? почему принято именно такое техническое решение? какие альтернативные варианты были?), общаться широко с разными грамотными людьми (даже с теми, которых нельзя потрогать ибо далеко)
метрики определения качества архитектуры предельно просты - берем цели проекта, бизнес-метрики и входные ограничения, из них определяем и приоритизируем атрибуты качества (quality attributes: http://www.sei.cmu.edu/architecture/start/reasoning.cfm, https://msdn.microsoft.com/en-us/library/ee658094.aspx ), проверяем, насколько проектируемая система удовлетворяет приоритетным требуемым атрибутам качества.
из набора литературы особенно люблю вот это: https://manohars.files.wordpress.com/2009/11/97-things-every-software-architect-should-know.pdf

-1

Я конечно понимаю там Epam позиционирует себя как отличная компания для построения карьеры и т.д., но с первого взгляда дак в EPAM уже больше людей с тайтлом "Солюшн Архитектор" чем в остальных компаниях вместе взятых по РБ. Причём некоторым даже удается получить этот тайтл через 5-6 лет опыта из которых 30-40% времени прошло во время учёбы в университете.. смотрю LinkedIn. Это EPAM удаётся снимать"сливки" со всего технического потенциала РБ ? Или просто кол-во менеджеров с различными приставками достигло критической массы и пришлось начать широко раздавать др. тайтлы ? дабы карьерный рост продолжался ? Вопрос частично риторический, частично провакационый ;) Но в любом случае былобы интересно увидеть серию статей от многочисленных архитекторов EPAM, в которых бы они хоть немного рассказали о своём опыте, какие системы проектировали с какими проблемами сталкивались и как решали... или это секрет ? потому что многие из этих Архитекторов на LinkedIn предпочитают вообще не расписсывать над какими проектами работали и что делали .. просто дата 20XX - 20YY Developer/Senior../Manger/Architect .. тут такая интрига, что даже никто не обидиться если статьи будут слегка отдавать душком рекламы EPAM ... )) Пожалуйста ..))

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
2

троллинг средней толщины, я сам умею и потоньше :) в линкедине нам заказчиков в принципе упоминать запрещено без явного разрешения с их стороны - и немногие заморачиваются этими разрешениями, гораздо проще вообще ничего не писать.
SA тайтл с 5 годами опыта? вряд ли, позвольте вам не поверить.
сливки технического потенциала РБ мы явно не собрали - ведь тебя-то мы пока не видим в наших стройных рядах ;)
а рассказы о своем опыте не очень популярны у нас, это я все зачем-то пишу - нормальным людям этот геморрой не нужен совсем, напишешь тут, а тебя потом еще и троллить пытаются :)

0

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

..я написал 5-6 (к сожалению как я уже упоминал выше, из за особенностей заполнения профайлов не всегда даже понятно в каких годах это был разработчик,а в какких SA) мне можете не верить, соберите статистику у HR , я надеюсь сотрудники честно профайлы заполняют)

Вообще в одном с вами согласен, чем больше пишешь тем больше вопросов возникает))

0

статья абстрактная, надо конкретные примеры проектов и приемов

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
3

действительно, статья абстрактная. в том числе и потому, что я ее такой задумал :)
запишу себе в секретную книжку - люди хотят примеры проектов и приемов.
посмотрим, что можно сделать; следите за новостями :)

0

"ибо они скорее о том, что заказчик хочет, чем о том, что ему на самом деле нужно.Но это уже совсем другая история, и не мне её рассказывать."

Почему другая история? Как понять что заказчик не знает что он хочет.? на конкретных примерах без персоналий было бы очень полезно. Опыт - сын ошибок трудных(с) :)

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
1

хм, я наверное непонятно написал; в статье имелось ввиду, что заказчик всегдя знает, чего он хочет (в каждый конкретный момент :)), но не всегда это то, что ему на самом деле надо. Пример - заказчик хочет красивый веб-интерфейс для генерации и заполнения маркетинговых форм на лету, с автоподстановкой, поиском, адаптивной версткой и т.д. А если провести цикл ентерпрайз архитектурного проекта, вполне может оказаться, что заказчику нужно расширение его интерфейса его PIM-системы (Product Information Management) для старта маркетинговых компаний на основе продуктовой и DAM информации, с расширенной системой отчетов, а формы давно пора выкинуть.
А почему это другая история - я не позиционирую себя как эксперта гибких методологий; пусть истинные гуру про это пишут :)

0

Может и enterprise архитектором быть лучше, но не всем позволяют им быть и вмешиваться в дела заказчика. Нужно и этот момент пояснить.

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
1

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

alex-poklonsky
alex-poklonsky Senior Solution Architect в EPAM
1

По теме вопроса заданного в начале статьи. Раз уж дошло до ссылок на неувядающий (по крайней мере для нас, дотнетчиков) P&P Application Architecture Guide то позволю себе процитировать пару мыслей из довольно актуальной (2014-2015г.) книги Dino Esposito Architecting Applications for the Enterprise 2nd edition. Отношение к автору неоднозначное, однако, он часто пишет дельные вещи: (дальше цельная цитата с парочкой комментариев посередине)
In the United States, an enterprise architect (EA) has almost nothing to do with application development because the person in that role focuses for, say, 90 percent of the time on IT-related business strategy, orchestration, and infrastructure. In an extreme synthesis, EA is the figure that weds business and IT. A candidate for this role is expected to know very little about software architecture subjects and probably nothing about things like layered architecture or DDD
In many companies, the role responsible for hard decisions, and in charge of proposing approaches and technologies, is not even labeled as an “architect” but gets the title of lead developer or something similar.

Теперь самое интересное :)
So you can find labels such as enterprise architect, infrastructure architect (IA), technology-specific architect (TSA), and even solution architect (SA). All these distinctions are kind of misleading because they attempt to break into parts what is ultimately an atomic, yet complex, role. In our opinion, it creates unnecessary categorization and lays the groundwork for confusing, who-does-what scenarios

Ну и заканчивается отсылом к ISO/IEC 25010 и ISO/IEC 9126:
In this book, we go with the ISO/IEC definition of an architect, which is the “person, team, or organization responsible for the system’s architecture” When mapping this concept to the widest possible range of companies, it turns out that what we call architect is a software (or solution) architect or even a lead developer

По-моему, хорошая попытка объять необъятное и прямо ответить на вопрос заданный в начале статьи, хотя и немного противоречиво

alex-poklonsky
alex-poklonsky Senior Solution Architect в EPAM
1

ISO/IEC 42010 пропустил - глубокая ночь, извиняйте :) с большего именно к нему-то отсыл и был

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
1

ночью увидел с телефона комментарий, обрадовался - думаю есть еще люди, которые темой похоже серьезно интересовались. а счас присмотрелся - сотрудник Епам, опять :(
по теме:
начал товарищ Эспозито хорошо, о связи EA и application dev, и также грамотно упомянув EA как мост между бизнесом и IT. но то, что эта роль и не должна быть в теме софтваре архитектуры, включая слои и ДДД - вероятно некоторое преувеличение :)
Дино как крепкий спец на стыке технической архитектуры и архитектуры решений похоже спроецировал свой личный опыт; ведь если посмотреть в TOGAF (один из самых популярных EA фреймворков), там фаза С (information architecture) подразумевает использование Reference Models, а они все довольно слоеные ;) и в целом эта фаза построена на расширенной версии domain driven design - оно все как раз на тему соотнести бизнес функции и возможности (domain) на информационную архитектуру (design) - хотя конечно не 1:1 как в книгах по DDD

насчет скрытых тайтлов согласен на все 100% (n many companies, the role responsible for hard decisions, and in charge of proposing approaches and technologies, is not even labeled as an “architect” but gets the title of lead developer or something similar) - только обычно ЕА маскируют тайтлами а-ля IT Strategist, IT Analyst или даже Department /Division Manager и тд

также товарищ Эспозито искрене возмущается количеству типов архитекторов, ведь это типо atomic role. но если вспомнить, откуда растут ноги у функционального деления на специализации, ответ придет сам собой - это реакция на растущую сложность. и опять обе стороны правы - архитектор действительно довольно атомарная роль (ибо принятие решений и ответственность за них не должна по-хорошему разделяться). но в огромных масштабах современных корпораций так не получится. я такого насмотрелся, там чтобы в одном из многих направлений бизнеса, и внутри нее в одной из технических горизонталей, могут такие потоки изменений идти со стороны бизнеса, индустрии и технологий, что атомарный архитектор порвется очень быстро.
И одна из задач ЕА в том числе и учесть все это при establishing Enterprise Architecture capability (TOGAF preliminary phase). суперклассика - архитекторы архитекторят архитектурные сервисы организации (помечу себе- запубликовать специальные поговорки для архитекторов)

к последней чати коммента я явным образом вернусь во второй части =)

alex-poklonsky
alex-poklonsky Senior Solution Architect в EPAM
1

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

Аспекты публичности, с сожалению, накладывают определенные ограничения на стиль и содержание мыслей и апелляцию к личному опыту, которые можно высказать (особенно это касается EA и пользы, которую приносят некоторые вещи, именованные как EA фреемворки). При этом я вовсе не говорю, что пользы нет. Важно не обмануть себя в ожиданиях и не заблудиться в фантазиях на тему реального value

Establishing Enterprise Architecture Capability. Звучит очень…солидно ! :) В контексте pre-sale фраза/предложение такого плана может вообще неожиданно оказаться ключевой концепцией. Но дальше все может оказаться не так радужно и, как один из вариантов, превратиться в банальное HiPPO (http://bit.ly/1Vc4heg) или важную составляющую в благородном деле освоения бюджета. Часто ловил себя на мысли, что в реальности, когда слышишь о концепциях подобного именования, то по прошествии некоторого времени начинаешь вопрошать: если оно все такое result-oriented, как декларируется, то какой же все-таки result? Или все же не result-oriented? Не всегда, но часто.

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

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

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

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
1

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

alex-poklonsky
alex-poklonsky Senior Solution Architect в EPAM
1

Про уровни абстракции – это интересно. Но, скорее, посыл был как раз в самом начале. Например, если под видами абстракций понимались другие виды архиектур, описанные в статье в дополнение к технической (хотя для меня более привычно/проще понятие system architecture где system = information system), то вопрос ложится скорее не в плоскость эффективности, а уместности. Если подумать дальше – очень важен контекст, скоуп. Тк понятие IT/Software архитектура, обозначенное в самом начале статьи, очень размытое и широкое

Поясню. Если на самом деле взять такую амбициозную цель, как описание видов архитектур в айти, то (среди прочено) придется раскрывать вопросы следующего плана:
Есть компании ISV, PDS и Business Integration Partners – трансформируются ли и как именно виды IT/Software архитектур при переходе от одной компании к другой? А что если взять какой-нибудь не-IT сектор? Допустим, Banking

Если говорить про абстракции, то нужно как-то раскрыть что над чем является абстракцией и в каком контексте. Например, возьмем Solution Architecture для решения, которое не включает в себя никакой технической архитектуры (допустим, set-up какого-нибудь процесса в IT, напрямую влияющего на разработку software). Валидна ли такая трактовка Solution Architecture? А если валидна, то абстракцией над чем она является?

Приведу еще пример относительно скоупа. Является ли модель монетизации IT/Software стартапа примером Solution Architecture? Enterprise Architecture? Относительно материала статьи, говорящего про IT/Software в целом, вопрос такого плана придется адресовать:)

В статье был неплохой заход на «подставив нужные границы», но тема границ, в которых были определены обозначенные далее «уровни архитектуры», не раскрыта..

Но даже если подставить нужные границы, допустим PDS (что, наверное, для нас проще) или ISV – то на ум сразу приходит мысль о не всегда четких границах между теми самыми PDS и ISV. Что и ведет к изначальной мысли про принцип Гейзенберга :)

Возможно, я сильно придираюсь :) Но, когда читаешь про все Software/IT в целом, у меня всегда возникает вопрос "а как там в контексте темы обстоят дела с разработкой софта под медицинские аппараты? а для NASA? ведь это тоже software"

В общем, надеюсь, мысль про скоуп понятна. Все это личное мнение, естественно

3

Вопрос из разряда "кому позволено, а кому не позволено носить красные шаровары".
А так же "когда человек действительно заслуживает носить красные шаровары с лампасами".

Сама идея выделенного человека АРХИТЕКТОРА со списком функциональных обязанностей отражает только построение процесса в самой компании и её структуру - иерархию; а так же смысл существования такой компании - поддерживать иерархию и систему ценностей предписывающую кому можно, а кому нельзя, а если можно то когда носить красные революционные шаровары.

Архитектура это не только о техническом решении. Суть работы архитектора не в том, чтобы создавать абстрактное техническое решение и чем абстрактнее или чем сложнее абстракция - тем круче архитектура и архитектор.
Суть работы архитектора - коммуникативная. Он создаёт не техническое решение в виде документации. Он создаёт консенсус различных групп людей относительно технического решения. Формирует общее согласованное видение технического решения. Его задача - поиск баланса интересов вовлечённых лиц и контроль за процессом создания технического решения с целью поддержания валидности этого общего видения. На архитектуру системы, как и на архитектуру здания сооружения влияет огромное число факторов -
кто строит(образованные, наёмные, рабы, военные),
из чего строят (глина, палки, бетон, мрамор),
на чём строят (болото, скала, песок, шельф),
с помощью чего строят (кирки, лопаты, 3d- принтеры итд),
за чьи деньги (с фондового рынка, из пожертвований, от монарха, от церкви итд),
для кого строят (людей, машин, образованных, глупых итд) ,
на сколько строят (на раз, на год, на века),
за сколько строят (сотни лет, месяц, завтра релиз; мешки денег, крошки и зёрнышки).
и тд и тп
Задача архитектора состоит в том, чтобы учесть, сбалансировать, придти к согласию и общему видения создаваемого технического решения. Конкретные действия которые он будет принимать, конкретные архитектурные артефакты (чертежи, описания, модели и тд и тп), которые он будет создавать зависят от того, каковы параметры среды в которой он действует (кто строители, кто заказчики, кто потребители, каковы ресурсы, каковы средства и тд и тп).
В одних компаниях и одних бизнес-доменах архитектура формализуется такими-то способами и такими-то артефактами, понятными всем заинтересованным. В других компаниях и других доменах - всё по-другому.
Само собой вопрос "кто такой настоящий архитектор в CMMI компании" волнует сотрудников пожалуй только CMMI компаний и ответ пожалуй лучше искать среди отраслевых единомышленников.

1

Грубо говоря - у египтян, строивших пирамиды в эпоху фараонов и при их современном уровне развития архитектором считался один человек с его специфичными атрибутами и шаблонами действия.
У строителей костёлов архитектор действовал, возможно, по-другому и создавал другие артефакты.
Советские архитекторы создававших максимально универсальные и дешёвые панельки действовали в другой среде, другими инструментами с другими процессами.
Архитектор музея Гуггенхайма в Бильбао и коттеджа в Тарасово и национальной библиотеки делают, по сути, одно и то же. Отличается только среда в которой они действуют. Отличаются характеристики заинтересованных лиц и процессов, а не сама архитектурная работа. Нельзя говорить что абстрагировав работу архитектора до абстрактного описания артефактов и характеристик артефактов мы сможем сфомулировать body of knowledge по которому мы сможем тренировать людей одинаково успешно выдающих хорошие архитектуры для музеев, коттеджей и библиотек. Заслуживающая внимания архитектура может быть и у коттеджа и у библиотеки и музея.
Но в зависимости от среды, из которой приходит оценивающий архитектуру, будет меняться и оценка архитектуры.
Кто-то пришёл из среды где всё меряется бюджетом - тогда круче архитектура и архитектор с самым большим бюджетом.
Кто-то пришёл из среды где ценится минимализм - тогда круче архитектура достигающая максимум при строительстве из г-на и палок.
Кто-то пришёл из среды ставящей акцент на количество абстракций, абстрактную сложность и техническую точность и согласованность - тогда круче архитектура с большим количеством прямых углов и окружностей под циркуль.
Но это вопрос к системе координат и к среде в которой действует архитектор, а не к сути его работы.

Ivan Padabed
Ivan Padabed Technical Fellow в Awem Games
1

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

В остальном конечно все правда, хотя писать про настоящего архитектора в CMMI компании я не планировал, извините, если разочаровал ;)

1

Спасибо за хорошую тему)
Я год назад на SEF студентам вещал, что есть такое "системная архитектура".
http://www.slideshare.net/yehorchurilov/ss-42456991

На мой скромный имхо, чтобы позицию software/IT/system architect определить наиболее быстро и понятно для не особо искушённого менеджера/разработчика/учащегося, стоит начинать именно со сложности, и стоимости проекта, как функции сложности. В презентации табличка со слайда 13 как раз про это.

Чтобы успокоить многия страхи, нужно указывать, что не все проекты требуют архитектурной работы, именно потому что для проектов ниже некоторого уровня сложности суммарная экономия времени и средств будет малозаметна. Понимание того, что разрабатывается нужно всегда, а вот архитектурирование, как производственная практика - нет. Архитектурирование - это про экономию средств на крупных/сложных проектах - этот тезис вроде как привлекательный и в целом принят индустрией. (Хотя, и тут можно выстрелить себе в ногу, несомненно)

Если говорить про область ответственности архитектора, то вкратце я бы определил это как "управление проектным знанием о целостности разрабатываемой системы". И коммуникация этого знания в команде, как выше справедливо заметили. Определения из IEEE 1471, .42010, NASA Systems Enginering Handbook и прочих BoK-ов не обращаются к архитектуре именно как к управляемому знанию (со своим жизненным циклом). ИМХО, очень зря.

"Целостность" от слова "цель" в том числе - это в этом много смысла. Странно было у вас прочитать, что "Особенно интересно получается, когда в границы системы удаётся захватить нетехнические элементы, — такие, как бизнес-цели, стратегии и процессы." звучит, будто это некий редкий случай. Этот контекст задаёт границы системы и явно определяет её цели и целостность, и без этого никуда. То бишь, в компетенции архитектора должен входить некоторый кругозор, понимание домена и бизнеса. В общем случае архитектурирование - это не просто собирание известных технических подсистем и известных компонентов из известных фреймворков в неизвестную целевую техническую систему. К построению целевой системы (e.g. корпоративного сервиса), добавляются проектирование обеспечивающих систем (процессы пользования ей) и сопряжение с системным окружением в течении всего ЖЦ. Это уже другой масштаб. Правда, это может запросто выскочить из рамок "ИТ"-архитектора.