С предыдущей частью статьи можно ознакомиться, перейдя по ссылке
Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это?
Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня.
Кстати существует профессиональный стандарт квалификационных требований системных архитекторов (5), на основании которых архитектору может быть присвоен один из шести квалификационных уровней. Будем использовать этот стандарт в ходе нашего рассмотрения темы, чтобы не упустить ничего важного в работе ИТ архитектора.
Традиционно начнем с определения:
ИТ-архитектор — это специалист, который решает, как в конечном итоге будет выглядеть информационная система организации в целом и в деталях. Основная цель ИТ-архитектора в компании заключается в том, чтобы обеспечить решение задач бизнеса при помощи информационных технологий. Причем, он должен не только сформировать решение, но и контролировать правильность его реализации. Также эти специалисты занимаются разработкой, созданием и поддержанием структуры программного обеспечения, сети, сервера, отдельного модуля в программе. Они прорабатывают архитектурные шаблоны, сценарии взаимодействия компонентов, выбирают средства исполнения, определяют формат хранения и передачи данных. (6)
Из определения следует, что деятельность ИТ архитекторов охватывает очень большой круг вопросов и компетенций. А поэтому есть необходимость делить ее по специализациям, например, соответствующим разделам архитектуры, рассмотренными нами в предыдущем разделе: Enterprise — Архитектор, Solution — Архитектор, Technical — Архитектор.
Чаще на практике можно встретить деление на: Бизнес — архитекторов и Технических архитекторов. При этом:
Бизнес-архитектор описывает предприятие с позиции логических терминов, таких как взаимодействующие бизнес-процессы и бизнес-правила, необходимая информация, структура и потоки информации.
Архитектор информационных технологий описывает предприятие с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, защита и безопасность.
Итак, каков же набор профессиональных активностей должен вменяться в обязанности ИТ архитектора?
Для всех специализаций актуальны следующие тренды:
Читая статьи архитекторов о самих себе, в каждом абзаце чувствуется особая значимость этой позиции, принадлежность к высшей касте ИТ специалистов, не двусмысленно дающая понять, что их – архитекторов, на земле не так уж и много. Видимо и стать архитектором можно только обладая целым набором способностей, знаний и навыков. Чаще всего в литературе выделяют следующие:
Итак, что же делает архитектора такой важной и эксклюзивной персоной в организации?
Мы только вкратце затронули основные нормы, которым должен соответствовать специалист, чтобы сгодиться в ИТ архитекторы. Теперь определим место ИТ архитектора в ИТ мире, под ласковым ИТ солнцем. Схематично, в упрощенном виде на рисунке 5 изображено представление возможного устройства взаимодействия ИТ архитектора с другими участниками процесса производства программных продуктов.
Рисунок 5. Структура взаимодействия ИТ архитектора
Как видно из рисунка, ИТ-архитектор действительно является центровой фигурой, в ходе создания информационной системы. Именно от его героических усилий глобально зависит успешность проекта, как в угоду заказчика, так и в интересах исполнителей. А теперь обо всем по порядку.
Чаще всего процесс производства программных продуктов начинается с зарождения у заказчика потребности в том или ином поступательном движении к собственному развитию. При этом, как правило, у него уже существует некая архитектура предприятия. Ведь выполняются какие-то процессы, существует организационная структура, регламенты взаимодействия. Наконец, наверняка должны быть вычислительные устройства, соединенные в сеть и какое-то программное обеспечение. Поэтому первое, чем должен озаботиться ИТ архитектор – это описание текущей архитектуры, базового ее состояния. И уже отталкиваясь от сего понимания, определив узкие места и дискомфортное, с точки зрения предприятия обустройство ее жизнедеятельности, проектировать новую, желаемую модель архитектуры, которую называют целевой. В вышеупомянутом документе с квалификационными требованиями, эта активность регламентирована как: «Сбор и анализ требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения» (5).
И в этом контексте необходимо четко осознавать, что редкий заказчик долетит в своем воображении хотя бы до середины реки своих реальных потребностей и сможет толково сформулировать, что же ему действительно надобно. В лучшем случае можно услышать, что он хочет. А это, с тем что ему нужно, как говорится, две большие разницы. Чаще всего на практике желания заказчика толмачат бизнес аналитики. Но даже при таком положении дел, архитектору надлежит контролировать этот процесс и, с высоты своего опыта и навыков, помогать выполнить эту задачу максимально качественно. Все ж таки на основании этих материалов и должна зародиться ИТ стратегия предприятия в части бизнес-архитектуры, системной архитектуры и мероприятий, позволяющих осуществить качественный скачек от базовой к целевой архитектуре.
Это пожалуй самый замечательный период, наполненный творчеством и открытиями. Заказчик сидит с открытым ртом и ловит каждую фразу фантастических историй о своей, теперь уже неизбежно беззаботной жизни. В округленных глазах читается лишь один немой вопрос: «А что так можно было?».
Для удобства восприятия и обсуждения, стратегия делится на сегменты, приоритезируется и обсчитывается на предмет трудозатрат, с прецизионностью «что-то около того». Этот документ становится предметом обсуждения и торга межу заказчиком (потребителем новаций), подрядчиками (исполнителями работ) и возможно, спонсорами, от которых требуется оплатить все эти изыски. Для проведения подобных работ ИТ архитектор должен уметь понимать бизнес и говорить с ним на одном (их родном) языке, максимально убедительно презентуя свои решения. В квалификационных требованиях, по этому поводу предписано: «Участие во взаимодействии с заказчиком по обсуждению проектных решений. Участие во взаимодействии с заказчиком по вопросам бюджетных расходов и сдачи проекта» (5).
Если концепция архитектуры и стратегия перехода к ней получили признание всех заинтересованных лиц и прошли горнило финансово-договорных испытаний, для дальнейшего производства информационной системы, необходимо разработать техническую документацию, включая Техническое задание. С этой задачей архитекторам чаще всего помогают справиться помощники, в виде: бизнес и системных аналитиков, технических писателей и прочих соучастников. Архитектор, в зависимости от своих предпочтений, возможностей и личной внутренней «коллективной интеллигентности», может в разной степени принимать персональное участие в данном процессе. Но основная его забота и ответственность — соблюсти строгое следование разработанной архитектуре и, в случае острой необходимости, зафиксировать изменения в ней. В квалификационных требованиях, это отмечено как: «Разработка требований различных типов к программному изделию. Обеспечение корректности и оптимальности архитектуры проекта. Участие в документировании проекта» (5).
В равной мере, на совести архитектора лежит еще и контроль полноты и комплектности артефактов, генерируемых проектной командой. Ведь они послужат основой для выполнения дальнейших работ по разработке собственно самого программного продукта, а также его тестированния, внедрения, поддержки и т.п. Все артефакты должны соответствовать стандартам фреймверка, выбранного в интересах предприятия, и призванного обеспечить полномасштабную поддержу описания архитектуры см. раздел II.2. Ведь как мы отметили в предыдущей части, именно наличие одних архитектурных артефактов в череде проектирования, предоставляет возможность для создания на их базе — следующих в цепочке артефактов. Этот технологический конвейер, должен шаг за шагом заполнять все пустоты в каркасе представления архитектуры предприятия. Об этом в квалификационных требованиях, естественно тоже упомянуто: «Контроль проектной и технической документации. Разработка концепции реализации системы программного изделия по спецификациям» (5).
Еще один важный аспект трудовой повинности архитектора – это определение экономической и деловой целесообразности внедрения целевой архитектуры. И в этом деле его главная опора и поддержка — руководитель проекта, а также руководители ключевых подразделений, участвующих в процессе разработки и внедрения информационной системы. Именно с их помощью архитектор должен определить возможность выполнения проекта в принципе, и в заданных рамках трудовых, финансовых и прочих затрат в частности. В квалификационных требованиях, указано: «Участие в планировании проекта, Участие в управлении проектом. Координация сбора и анализа требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения» (5).
Ну и конечно одной из центральной функций архитектора является контроль качества производства самого целевого продукта и его соответствия — концепции архитектуры. В квалификационных требованиях: «Контроль исполнения архитектурных решений. Анализ качества продукта и его соответствия требованиям и спецификациям» (5).
Контроль должен охватить все мероприятия, направленные на достижение выработанной стратегии ИТ модернизации предприятия. Включая, например, указанную в квалификационных требованиях: «Организацию и планирование тестирования» (5).
Это также означает, что работа архитектора не заканчивается с выпуском крайнего релиза, передаваемого заказчику. Напротив, это всего лишь знаменует завершение более менее спокойной жизни, творческого и захватывающего периода, и переход к новому в эмоциональном плане этапу работ. Закончен конфетно-букетный период общения с заказчиком, наступает момент истины. Маски сорваны, у всех открываются глаза на всамделишное лицо, так искусно и лицемерно скрываемое доселе. Заказчик чувствует себя обманутым. Ему бессовестно подсовывают совсем не то, что пообещали. Мало того, это «не то» еще и сбоит, зависает, ведет себя как вредитель, пряча все время куда-то самые важные данные. Это с одной стороны баррикад. А с другой — безрукие, неадекватные пользователи, все время жмут не на те кнопки, как-то отыскивают такие закоулки программных возможностей, которые в принципе невозможны, и от которых она просто беспомощно впадает в ступор.
К чему я это все? А к еще одной важной функции архитектора — оптимизации решения, исправления недоработок, устранению недокументированных функций системы, открытых любознательными пользователями и т.п. Естественно, чем качественнее была спроектирована, реализована и внедрена информационная система, тем меньше масштабы подобных бедствий и быстрее можно перейти к последующему этапу ее жизни. В квалификационных требованиях, этому соответствует: «Участие в оптимизации и исправлении реализованного программного обеспечения. Участие в сопровождении программного продукта. Обучение и содействие повышению квалификации персонала» (5).
По мере стабилизации работы информационной системы, накал потихоньку снижается. Отчаяние сменяется неизбежностью того, что одни выкинули деньги на ветер, а другие потеряли в пустую время, силы и репутацию. Но отступать поздно, да и потраченного так жалко. Неизбежность перерастает в равнодушие, и это заставляет противоборствующих ослабить хватку и поднять забрала. А под ними становится заметно движение губ. Очевидно, что они хотят что-то сказать. Оппоненты начинают прислушиваются друг к другу. Начинается взаимное движение на встречу. Нет, отношения все еще напряженные, осадчик то остался. Роль архитекторов и на этапе конфронтации тяжело переоценить, поскольку они отчетливее всех представляют себе, где произошел раскол в понимании, по какой причине, и именно от них ждут решения, ведущего к позитивным изменениям. Такая эмоциональная нагрузка требует от сотрудников, соответствующей физической и психологической стойкости. Проявления дипломатичности, сдержанности, если хотите — мудрости.
И вот через некоторое время, программный комплекс уже работает как часы, а в памяти пользователей стираются былые сложности. Даже сбои в системе теперь порождают не раздражение и скандалы пользователей и их начальства, а всеобщую мобилизацию, основанную на понимании сложности продукта, бизнес правил, взаимосвязи множества компонентов системы, а главное — неминуемого и неотвратимого разрешения любых проблем. И теперь разработчики системы уже точно не враги, их даже рекомендуют другим организациям, как классных специалистов, способных в кратчайшие сроки безо всяких проблем, автоматизировать процессы любой сложности.
Из вышесказанного понятно, насколько важна качественная работа специалистов архитектурного цеха на всех этапах производства информационных систем.
Не лишне упомянуть, что во всех рассмотренных аспектах работы архитектора от него требуется постоянный, плотный контакт с командой. Причем большая часть общения происходит не на уровне «начальник – подчиненный», а на уровне «партнеры по команде». Поскольку взаимодействие в проекте, чаще всего, основано на матричной структуре управления, и у большинства исполнителей есть свои линейные руководители. В этих реалиях архитектору важно суметь выстроить свой непререкаемый авторитет в команде и найти подходы к ее ключевым игрокам на разных уровнях и ярусах организации.
Вспомнился случай мастеркласса, когда в процесс ожесточенной баталии между специалистами заказчика ИТ продукта и командой исполнителей, вмешался архитектор решения, человек совсем не воинственного вида. Своими четкими, уместными уточнениями и разъяснениями, не повышая голоса, он перехватил инициативу в дискуссии и заставил всех внимать каждому своему слову. Никого не хочу обидеть, но выглядело это, как общение удава Ка с бандерлогами, в известном мультфильме. В результате вопросы были решены, заказчик удовлетворен, а команда прочувствовала свою защищенность, ощутив себя как за «каменной стеной».
Подытожим рассмотренный материал.
III Определение понятия архитектор
Врач может похоронить свою ошибку,
архитектор – разве что обсадить стены плющом.
Фрэнк Ллойд Райт.
Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это?
Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня.
Кстати существует профессиональный стандарт квалификационных требований системных архитекторов (5), на основании которых архитектору может быть присвоен один из шести квалификационных уровней. Будем использовать этот стандарт в ходе нашего рассмотрения темы, чтобы не упустить ничего важного в работе ИТ архитектора.
1. Обзор обязанностей и ответственности ИТ архитектора
Традиционно начнем с определения:
ИТ-архитектор — это специалист, который решает, как в конечном итоге будет выглядеть информационная система организации в целом и в деталях. Основная цель ИТ-архитектора в компании заключается в том, чтобы обеспечить решение задач бизнеса при помощи информационных технологий. Причем, он должен не только сформировать решение, но и контролировать правильность его реализации. Также эти специалисты занимаются разработкой, созданием и поддержанием структуры программного обеспечения, сети, сервера, отдельного модуля в программе. Они прорабатывают архитектурные шаблоны, сценарии взаимодействия компонентов, выбирают средства исполнения, определяют формат хранения и передачи данных. (6)
Из определения следует, что деятельность ИТ архитекторов охватывает очень большой круг вопросов и компетенций. А поэтому есть необходимость делить ее по специализациям, например, соответствующим разделам архитектуры, рассмотренными нами в предыдущем разделе: Enterprise — Архитектор, Solution — Архитектор, Technical — Архитектор.
Чаще на практике можно встретить деление на: Бизнес — архитекторов и Технических архитекторов. При этом:
Бизнес-архитектор описывает предприятие с позиции логических терминов, таких как взаимодействующие бизнес-процессы и бизнес-правила, необходимая информация, структура и потоки информации.
Архитектор информационных технологий описывает предприятие с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, защита и безопасность.
Итак, каков же набор профессиональных активностей должен вменяться в обязанности ИТ архитектора?
Для всех специализаций актуальны следующие тренды:
- Анализ и оценка существующего состояния дел;
- Проектирование решений для создания сложных информационно- программных комплексов, от высокоуровневых представлений до детальных. Оценка выполнимости и ресурсоемкости решений;
- Фиксация своих решений в виде различных артефактов и документов, доступных для понимания заинтересованными лицами;
- Ответственность за целесообразность и эффективность принятых решений;
- Контроль качества и полноты воплощения в жизнь своих решений;
- Поддержание своих решения в актуальном состоянии, при подверженности их внешнему влиянию;
Читая статьи архитекторов о самих себе, в каждом абзаце чувствуется особая значимость этой позиции, принадлежность к высшей касте ИТ специалистов, не двусмысленно дающая понять, что их – архитекторов, на земле не так уж и много. Видимо и стать архитектором можно только обладая целым набором способностей, знаний и навыков. Чаще всего в литературе выделяют следующие:
- Широкий кругозор, который необходимо постоянно поддерживать. Включая не только технологическую сторону, но и социальные моменты, аспекты экономической целесообразности и т.п.;
- Умение работать в коллективе, завоевывать авторитет, управлять командой, проявлять дипломатичность;
- Развитое чувство ответственности;
- Способность и потребность к самообразованию;
- Умение четко, доступно и аргументировано доносить свою точку зрения;
- Чувство пропорции;
- Умение чувствовать тенденции: изменений, развития, востребованности и т.п.;
Итак, что же делает архитектора такой важной и эксклюзивной персоной в организации?
2. Место ИТ Архитектора в процессе производства информационных систем
Мы только вкратце затронули основные нормы, которым должен соответствовать специалист, чтобы сгодиться в ИТ архитекторы. Теперь определим место ИТ архитектора в ИТ мире, под ласковым ИТ солнцем. Схематично, в упрощенном виде на рисунке 5 изображено представление возможного устройства взаимодействия ИТ архитектора с другими участниками процесса производства программных продуктов.
Рисунок 5. Структура взаимодействия ИТ архитектора
Как видно из рисунка, ИТ-архитектор действительно является центровой фигурой, в ходе создания информационной системы. Именно от его героических усилий глобально зависит успешность проекта, как в угоду заказчика, так и в интересах исполнителей. А теперь обо всем по порядку.
Чаще всего процесс производства программных продуктов начинается с зарождения у заказчика потребности в том или ином поступательном движении к собственному развитию. При этом, как правило, у него уже существует некая архитектура предприятия. Ведь выполняются какие-то процессы, существует организационная структура, регламенты взаимодействия. Наконец, наверняка должны быть вычислительные устройства, соединенные в сеть и какое-то программное обеспечение. Поэтому первое, чем должен озаботиться ИТ архитектор – это описание текущей архитектуры, базового ее состояния. И уже отталкиваясь от сего понимания, определив узкие места и дискомфортное, с точки зрения предприятия обустройство ее жизнедеятельности, проектировать новую, желаемую модель архитектуры, которую называют целевой. В вышеупомянутом документе с квалификационными требованиями, эта активность регламентирована как: «Сбор и анализ требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения» (5).
И в этом контексте необходимо четко осознавать, что редкий заказчик долетит в своем воображении хотя бы до середины реки своих реальных потребностей и сможет толково сформулировать, что же ему действительно надобно. В лучшем случае можно услышать, что он хочет. А это, с тем что ему нужно, как говорится, две большие разницы. Чаще всего на практике желания заказчика толмачат бизнес аналитики. Но даже при таком положении дел, архитектору надлежит контролировать этот процесс и, с высоты своего опыта и навыков, помогать выполнить эту задачу максимально качественно. Все ж таки на основании этих материалов и должна зародиться ИТ стратегия предприятия в части бизнес-архитектуры, системной архитектуры и мероприятий, позволяющих осуществить качественный скачек от базовой к целевой архитектуре.
Это пожалуй самый замечательный период, наполненный творчеством и открытиями. Заказчик сидит с открытым ртом и ловит каждую фразу фантастических историй о своей, теперь уже неизбежно беззаботной жизни. В округленных глазах читается лишь один немой вопрос: «А что так можно было?».
Для удобства восприятия и обсуждения, стратегия делится на сегменты, приоритезируется и обсчитывается на предмет трудозатрат, с прецизионностью «что-то около того». Этот документ становится предметом обсуждения и торга межу заказчиком (потребителем новаций), подрядчиками (исполнителями работ) и возможно, спонсорами, от которых требуется оплатить все эти изыски. Для проведения подобных работ ИТ архитектор должен уметь понимать бизнес и говорить с ним на одном (их родном) языке, максимально убедительно презентуя свои решения. В квалификационных требованиях, по этому поводу предписано: «Участие во взаимодействии с заказчиком по обсуждению проектных решений. Участие во взаимодействии с заказчиком по вопросам бюджетных расходов и сдачи проекта» (5).
Если концепция архитектуры и стратегия перехода к ней получили признание всех заинтересованных лиц и прошли горнило финансово-договорных испытаний, для дальнейшего производства информационной системы, необходимо разработать техническую документацию, включая Техническое задание. С этой задачей архитекторам чаще всего помогают справиться помощники, в виде: бизнес и системных аналитиков, технических писателей и прочих соучастников. Архитектор, в зависимости от своих предпочтений, возможностей и личной внутренней «коллективной интеллигентности», может в разной степени принимать персональное участие в данном процессе. Но основная его забота и ответственность — соблюсти строгое следование разработанной архитектуре и, в случае острой необходимости, зафиксировать изменения в ней. В квалификационных требованиях, это отмечено как: «Разработка требований различных типов к программному изделию. Обеспечение корректности и оптимальности архитектуры проекта. Участие в документировании проекта» (5).
В равной мере, на совести архитектора лежит еще и контроль полноты и комплектности артефактов, генерируемых проектной командой. Ведь они послужат основой для выполнения дальнейших работ по разработке собственно самого программного продукта, а также его тестированния, внедрения, поддержки и т.п. Все артефакты должны соответствовать стандартам фреймверка, выбранного в интересах предприятия, и призванного обеспечить полномасштабную поддержу описания архитектуры см. раздел II.2. Ведь как мы отметили в предыдущей части, именно наличие одних архитектурных артефактов в череде проектирования, предоставляет возможность для создания на их базе — следующих в цепочке артефактов. Этот технологический конвейер, должен шаг за шагом заполнять все пустоты в каркасе представления архитектуры предприятия. Об этом в квалификационных требованиях, естественно тоже упомянуто: «Контроль проектной и технической документации. Разработка концепции реализации системы программного изделия по спецификациям» (5).
Еще один важный аспект трудовой повинности архитектора – это определение экономической и деловой целесообразности внедрения целевой архитектуры. И в этом деле его главная опора и поддержка — руководитель проекта, а также руководители ключевых подразделений, участвующих в процессе разработки и внедрения информационной системы. Именно с их помощью архитектор должен определить возможность выполнения проекта в принципе, и в заданных рамках трудовых, финансовых и прочих затрат в частности. В квалификационных требованиях, указано: «Участие в планировании проекта, Участие в управлении проектом. Координация сбора и анализа требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения» (5).
Ну и конечно одной из центральной функций архитектора является контроль качества производства самого целевого продукта и его соответствия — концепции архитектуры. В квалификационных требованиях: «Контроль исполнения архитектурных решений. Анализ качества продукта и его соответствия требованиям и спецификациям» (5).
Контроль должен охватить все мероприятия, направленные на достижение выработанной стратегии ИТ модернизации предприятия. Включая, например, указанную в квалификационных требованиях: «Организацию и планирование тестирования» (5).
Это также означает, что работа архитектора не заканчивается с выпуском крайнего релиза, передаваемого заказчику. Напротив, это всего лишь знаменует завершение более менее спокойной жизни, творческого и захватывающего периода, и переход к новому в эмоциональном плане этапу работ. Закончен конфетно-букетный период общения с заказчиком, наступает момент истины. Маски сорваны, у всех открываются глаза на всамделишное лицо, так искусно и лицемерно скрываемое доселе. Заказчик чувствует себя обманутым. Ему бессовестно подсовывают совсем не то, что пообещали. Мало того, это «не то» еще и сбоит, зависает, ведет себя как вредитель, пряча все время куда-то самые важные данные. Это с одной стороны баррикад. А с другой — безрукие, неадекватные пользователи, все время жмут не на те кнопки, как-то отыскивают такие закоулки программных возможностей, которые в принципе невозможны, и от которых она просто беспомощно впадает в ступор.
К чему я это все? А к еще одной важной функции архитектора — оптимизации решения, исправления недоработок, устранению недокументированных функций системы, открытых любознательными пользователями и т.п. Естественно, чем качественнее была спроектирована, реализована и внедрена информационная система, тем меньше масштабы подобных бедствий и быстрее можно перейти к последующему этапу ее жизни. В квалификационных требованиях, этому соответствует: «Участие в оптимизации и исправлении реализованного программного обеспечения. Участие в сопровождении программного продукта. Обучение и содействие повышению квалификации персонала» (5).
По мере стабилизации работы информационной системы, накал потихоньку снижается. Отчаяние сменяется неизбежностью того, что одни выкинули деньги на ветер, а другие потеряли в пустую время, силы и репутацию. Но отступать поздно, да и потраченного так жалко. Неизбежность перерастает в равнодушие, и это заставляет противоборствующих ослабить хватку и поднять забрала. А под ними становится заметно движение губ. Очевидно, что они хотят что-то сказать. Оппоненты начинают прислушиваются друг к другу. Начинается взаимное движение на встречу. Нет, отношения все еще напряженные, осадчик то остался. Роль архитекторов и на этапе конфронтации тяжело переоценить, поскольку они отчетливее всех представляют себе, где произошел раскол в понимании, по какой причине, и именно от них ждут решения, ведущего к позитивным изменениям. Такая эмоциональная нагрузка требует от сотрудников, соответствующей физической и психологической стойкости. Проявления дипломатичности, сдержанности, если хотите — мудрости.
И вот через некоторое время, программный комплекс уже работает как часы, а в памяти пользователей стираются былые сложности. Даже сбои в системе теперь порождают не раздражение и скандалы пользователей и их начальства, а всеобщую мобилизацию, основанную на понимании сложности продукта, бизнес правил, взаимосвязи множества компонентов системы, а главное — неминуемого и неотвратимого разрешения любых проблем. И теперь разработчики системы уже точно не враги, их даже рекомендуют другим организациям, как классных специалистов, способных в кратчайшие сроки безо всяких проблем, автоматизировать процессы любой сложности.
Из вышесказанного понятно, насколько важна качественная работа специалистов архитектурного цеха на всех этапах производства информационных систем.
Не лишне упомянуть, что во всех рассмотренных аспектах работы архитектора от него требуется постоянный, плотный контакт с командой. Причем большая часть общения происходит не на уровне «начальник – подчиненный», а на уровне «партнеры по команде». Поскольку взаимодействие в проекте, чаще всего, основано на матричной структуре управления, и у большинства исполнителей есть свои линейные руководители. В этих реалиях архитектору важно суметь выстроить свой непререкаемый авторитет в команде и найти подходы к ее ключевым игрокам на разных уровнях и ярусах организации.
Вспомнился случай мастеркласса, когда в процесс ожесточенной баталии между специалистами заказчика ИТ продукта и командой исполнителей, вмешался архитектор решения, человек совсем не воинственного вида. Своими четкими, уместными уточнениями и разъяснениями, не повышая голоса, он перехватил инициативу в дискуссии и заставил всех внимать каждому своему слову. Никого не хочу обидеть, но выглядело это, как общение удава Ка с бандерлогами, в известном мультфильме. В результате вопросы были решены, заказчик удовлетворен, а команда прочувствовала свою защищенность, ощутив себя как за «каменной стеной».
3. Резюме раздела
Подытожим рассмотренный материал.
- В связи с широчайшим кругом функциональных обязанностей, ИТ архитекторы делятся по специализациям. Каждая специализация охватывает конкретный круг вопросов, требующих владения определенными компетенциями, навыками и знаниями.
- Успешно выполнять функции архитектора может только специалист, обладающий определенным набором способностей и поведенческих моделей, с явно выраженным потенциалом развития.
- Архитектор должен обладать целым рядом компетенций, позволяющих ему–оценивать текущее состояние дел на предприятии, определять проблемы и узкие места, разрабатывать целевую архитектуру и формировать стратегию перехода к ней.
- Одним из архиполезных навыков архитектора является умение квалифицированно и эффективно общаться с разными группами заинтересованных лиц, учитывая их квалификацию, сферу деятельности и даже социальный статус.
- Архитектор должен уметь качественно оценивать деловые и экономические аспекты, предлагаемых им стратегий.
- Одной из важнейших функций архитектора является контроль, за качественным описанием архитектуры, соблюдением архитектурных решением в процессе производства информационной системы, качеством и точностью выполнения мероприятий по воплощению разработанной стратегии.
Список литературы
1. Википедия. Архитектура программного обеспечения. [электронный ресурс] — Режим доступа: ru.wikipedia.org/wiki/Архитектура_программного_обеспечения, свободный. — Загл. с экрана.
2. Свободная энциклопедия Википедия. Архитектура системы. Режим доступа: ru.wikipedia.org/wiki/Архитектура_системы, свободный. — Загл. с экрана.
3. Ю.М, Мадорская. Схема Захмана при разработке требований к ИС. б.м.: Практика проектирования систем.-2015. [электронный ресурс]. Режим доступа: reqcenter.pro/zachman-framework, свободный. — Загл. с экрана.
4. Рубенчик, Андрей. Моделирование архитектуры предприятия. Обзор языка ArchiMate. Корпоративный менеджмент. [электронный ресурс]. Режим доступа: www.cfin.ru/itm/standards/ArchiMate.shtml, свободный. — Загл. с экрана.
5. коллектив, Авторский. Квалификационные требования в области информационных технологий «СИСТЕМНЫЙ АРХИТЕКТОР». Режим доступа rosexpertpravo.ru/law/Index2/1/4293830/4293830557.htm, свободный. — Загл. с экрана.
6. БудуГуру, Сайт. ИТ-архитектор. Режим доступа buduguru.org/profession/2, свободный. — Загл. с экрана.
2. Свободная энциклопедия Википедия. Архитектура системы. Режим доступа: ru.wikipedia.org/wiki/Архитектура_системы, свободный. — Загл. с экрана.
3. Ю.М, Мадорская. Схема Захмана при разработке требований к ИС. б.м.: Практика проектирования систем.-2015. [электронный ресурс]. Режим доступа: reqcenter.pro/zachman-framework, свободный. — Загл. с экрана.
4. Рубенчик, Андрей. Моделирование архитектуры предприятия. Обзор языка ArchiMate. Корпоративный менеджмент. [электронный ресурс]. Режим доступа: www.cfin.ru/itm/standards/ArchiMate.shtml, свободный. — Загл. с экрана.
5. коллектив, Авторский. Квалификационные требования в области информационных технологий «СИСТЕМНЫЙ АРХИТЕКТОР». Режим доступа rosexpertpravo.ru/law/Index2/1/4293830/4293830557.htm, свободный. — Загл. с экрана.
6. БудуГуру, Сайт. ИТ-архитектор. Режим доступа buduguru.org/profession/2, свободный. — Загл. с экрана.
Комментарии (61)
Mountaineer
25.01.2018 15:531. Википедия. Архитектура программного обеспечения. [электронный ресурс] — Режим доступа: ru.wikipedia.org/wiki/Архитектура_программного_обеспечения, свободный. — Загл. с экрана.
2. Свободная энциклопедия Википедия. Архитектура системы. Режим доступа: ru.wikipedia.org/wiki/Архитектура_системы, свободный. — Загл. с экрана.
4. Рубенчик, Андрей. Моделирование архитектуры предприятия. Обзор языка ArchiMate. Корпоративный менеджмент. [электронный ресурс]. Режим доступа: www.cfin.ru/itm/standards/ArchiMate.shtml, свободный. — Загл. с экрана.
5. коллектив, Авторский. Квалификационные требования в области информационных технологий «СИСТЕМНЫЙ АРХИТЕКТОР». Режим доступа rosexpertpravo.ru/law/Index2/1/4293830/4293830557.htm, свободный. — Загл. с экрана.
Ни одна из етих ссылок со списка литературы ничено не содержыт (404 или пустая страница).ARadzishevskiy Автор
25.01.2018 15:55это ссылки преобразованные Хабром (по факту в тексте написано например, «https:// ru.wikipedia.org/wiki/»). щелкайте на ссылку в тексте — перейдете на страницу.
mad_nazgul
26.01.2018 10:54Что вы спорите?!
Архитектур всего лишь четыре
1) Однозвенная
2) Двузвенная
3) Трехзвенная
4) Микросервисная
Архитектор просто бросает четырехгранный кубик и выбирает, что взбредет в голову!
<:o)ARadzishevskiy Автор
26.01.2018 11:04А архитектуру бизнес-процессов организации к какому из перечисленных делений можно причислить?
И как примерно выглядит четырехгранный кубик?mad_nazgul
26.01.2018 11:46Не существует архитектуры бизнес процессов.
Есть просто бизнес-процессы.
Есть общие бизнес-процессы для всех предприятий, а есть уникальные для конкретного предприятия.
Шутка из русскоязычного DND.
В оригинале «кость» :-)ARadzishevskiy Автор
26.01.2018 11:52Не существует архитектуры бизнес процессов.
Очень конструктивная позиция — То о чем не знаю — не существует.
Бизнес — архитектура предприятия (EBA-EnterpriseBusinessArchitecture) – это целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес — целями. В ходе построения бизнес — архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структураmad_nazgul
26.01.2018 12:48Бизнес-архитектура предприятия != архитектура бизнес-процессов
Бизнес процесс он либо есть, либо его нет.
Если он есть, то он работает by default.
Сложность только в его описании/моделировании.
Какая архитектура у бизнес-процесса выставления счета фактуры? :-)ARadzishevskiy Автор
26.01.2018 13:10Какая архитектура у бизнес-процесса
Неточности пораждают ошибки и непонимание. Я писал об архитектуре бизнес-процессов (множественное число). То есть совокупность чего, в некой организационной среде, может складываться в разные архитектурные решения.
Встречный вопрос из той же разряда: какая архитектура из 4_ех перечисленных представляет реализацию в коде «бизнес-процесс выставления счета фактуры»?
Сложность только в его описании/моделировании.
Вот для борьбы с этой сложностью, а точнее со сложностью описания и моделирования совокупности процессов в различных моделях организации предприятия и т.д. и принято использование ИТ Архитекторов (в данном аспекте бизнес архитекторов)mad_nazgul
26.01.2018 13:33Вот об этом и речь.
У бизнес-процессов нет архитектуры, есть «реализация».
С термином «архитектура предприятия» согласен.
Но по мне он спорный.
Насчет какая из четырех архитектур представляет бизнес-процесс — все.
Любая из мной перечисленных архитектур может реализовывать данный бизнес процесс.
Это все равно что спросить — в каком архитектурном стиле можно построить сарай для коров.
Ответ — в любом.
Барроко, Готика, Романский, Ампир т.д.
Зависит от личных предпочтений заказчика и архитектора. :-)ARadzishevskiy Автор
26.01.2018 13:50У бизнес-процессов нет архитектуры, есть «реализация».
читайте внимательно определения:
В ходе построения бизнес — архитектуры определяются необходимые бизнес-процессы
То есть бизнес процессы определены в соответствии с бизнес архитектурой. При этом у бизнес процессов — есть архитектура в соответствии с которой они определены? При этом у этих «необходимых бизнес-процессов» может никогда не быть реализации.mad_nazgul
26.01.2018 14:30Бизнес процесс это конкретные действия.
Они уже реализованы.
Если они нигде не реализованы в живую — то их нет.
Что значит «При этом у бизнес процессов — есть архитектура в соответствии с которой они определены»
Бизнес процесс либо есть, либо нет.
Если он есть, то какую бы архитектуру бы не выбрали, он должен быть.
Т.е. бизнес-процессы не должны определять архитектуру.
Грубо говоря нам не важно в каком архитектурном стиле построен сарай.
Главное, чтобы коровам там было сухо, тепло и комфортно.ARadzishevskiy Автор
26.01.2018 14:58Бизнес процесс это конкретные действия.
А алгоритм, это конкретные действия? А если он не реализован, его нет?
ARadzishevskiy Автор
26.01.2018 15:09Грубо говоря нам не важно в каком архитектурном стиле построен сарай.
Главное, чтобы коровам там было сухо, тепло и комфортно
Опять вопрос вывернут наизнанку. Вопрос чтобы архитектурное решение было выбрано и спроектировано. Иначе сарай мало того что не будет сухой и теплы, он вообще скорее всего рухнет
ARadzishevskiy Автор
26.01.2018 15:11Бизнес процесс либо есть, либо нет.
Если он есть, то какую бы архитектуру бы не выбрали, он должен быть.
Опять все вывернуто на изнанку. Бизнес процесс не просто должен быть, он должен быть реализован именно в контексте выбранной архитектуры.
ggo
27.01.2018 18:21У бизнес-процессов есть архитектура ;)
И запросто может быть архитектура несуществующих процессов. Точно также, как может быть архитектура несуществующих зданий или несуществующих информационных систем. ;)
gimatdinov
27.01.2018 09:37Врач может похоронить свою ошибку,
архитектор – разве что обсадить стены плющом.
Фрэнк Ллойд Райт.
В который раз я вижу, как путают понятия архитектор зданий и ИТ-архитектор.
Архитектор зданий выполняет архитектурное проектирование (планировочные и интерьерные решения), которое не предполагает инженерного проектирования (расчет балок и нагрузки и т.д.).
А указанный Вами афоризм «архитектор – разве что обсадить стены плющом» говорит только о том, что «плохой вид спасут декорации». Это никоим образом не относится к ИТ-архитекторам.
Грубо говоря, аналог «строительного архитектора» в ИТ это: ? бизнес-аналитика + ? дизайнера.
В связи с широчайшим кругом функциональных обязанностей, ИТ архитекторы делятся по специализациям. Каждая специализация охватывает конкретный круг вопросов, требующих владения определенными компетенциями, навыками и знаниями.
Нет, термин «специализации» тут не применим, в тексте статьи Вы «притянули за уши» специализацию к видам архитекторов. Задача архитектора – проектирование архитектуры в виде комплексного решения. Этот комплекс ограничивается контекстом: информационная система, предприятие, безопасность (как комплексное решение) и т.д. Соответственно есть архитекторы информационных систем, архитекторы предприятия и т.д.
Ко всему тексту статьи у меня есть замечания, но приводить их смысла нет, по тем же причинам, что и для статьи «Архитектура ИТ решений. Часть 1. Архитектура предприятия».ggo
27.01.2018 18:12+1Архитекторы из архитектурных бюро с вами несогласны ;)
Да, непосредственно сами расчеты балок архитектор может и не делает, но точно контролирует, и точно отвечает за общий результат.
И в этом «строительный» архитектор ничем не отличается от ит-архитектора. Второй может не считает конкретные мегабайты конкретного оборудования, но тоже контролирует и тоже отвечает за общий результат.
зы
не путать с плохими архитекторами и плохими примерами. таковые присутствуют по всех отраслях.
gimatdinov
27.01.2018 21:42… но точно контролирует, и точно отвечает за общий результат.
И в этом «строительный» архитектор ничем не отличается от ит-архитектора.
Контролирует он только соответствие своим представлениям, и вообще не он главный и не основной.
И дело его: экстерьер, интерьер и расчет освещенности. Вот и всё. Основная ответственность на инженере-конструкторе (обучается "Промышленному и гражданскому строительству").
А архитектор учится "Архитектурному проектированию".
Еще бываю инженеры-архитекторы (иногда так называются) (обучаются "Проектированию зданий"), но они в первую инженеры, только потом архитекторы.
Если хотите, можете сходить в свое архитектурное бюро, они Вам подтвердят. :)gimatdinov
27.01.2018 22:44Планировка еще у архитектора, но я в предыдущем комментарии сказал, а тут забыл.
gimatdinov
27.01.2018 23:29Еще для понимания.
Говорить, что работа ИТ-архитектор похожа на работу Архитектор зданий, это уподобиться автору этой статьи «Основы бизнес процессов — тезисы вебинара», который без понимания технологий строительства в самом начале статьи разместил картинку, где рабочий укладывает керамические блоки на цементный раствор. Если Вы не разбираетесь в строительстве, то для Вас это, может быть, смотрится нормально. А то, кто понимает, посмотрит и скажет «нехорошее слово», которое, если смягчить, будет переводиться как «некомпетентность». Поэтому, рекомендую, если у Вас нет архитектурно-строительного образования, то не надо впутывать архитектора зданий в свои рассуждения об ИТ. Иначе, это будут похоже на анекдот «Отдай мою собаку!».
ggo
29.01.2018 10:46На каких специальностях учат ИТ-Архитекторов?
Получается чувак, который спроектировал Бурж-Халифа (он еще много чего другого спроектировал), просто определил экстерьер, интерьер, планировку, освещенность рассчитал, потом получил бабло и отвалил насовсем? Дальше уже без него достраивали? И если бы что-то пошло не так, то он просто сказал, «ну ребята, я просто экстерьер, интерьер нарисовал, а что там с расчетом нагрузки я хз, идите с… разбирайтесь». и это всех бы устроило?
И архитектурный надзор — термин вымышленный, и ни кем не применяемый?
DexterHD
Мне вот почему то всегда казалось что задача любого программиста как профессионала «Обеспечить решение задач бизнеса при помощи информационных технологий». И любой программист, если он профессионал должен быть архитектором.
Окончательно в этом я убедился, после того как посмотрел несколько выступлений Роберта («Uncle Bob») Мартина, принимая во внимание его опыт и авторитет, а так же то что IT отрасль в США опережает нашу на 10 лет.
Крайне рекомендую посмотреть его выступление «The Future of Programming», где он дает экскурс в историю и поясняет, как вообще развивалось программирование и как со временем терялась квалификация программистов, откуда взялись все эти отдельные специальности, такие как архитекторы, It-менеджеры, Agile-коучи, системные аналитики и прочие. Так же он раскрывает причины которые привели к появлению Waterfall модели и в чем истинная суть Agile. И еще много интересных моментов.
lair
Это цель (стратегия). Но конкретный программист реализующий конкретный кубик вполне может решать (тактическую) задачу "написать такой-то отчет".
Вы же отдаете себе отчет, что это невыполнимое требование?
DexterHD
Программисты старой гвардии почему то так не считают. И я так не думаю, хоть я и достаточно молод и начал свой путь всего лишь в начале 2000-ных. Для меня это требование всегда было выполнимым и обязательным. С самой первой своей программы которую я написал за деньги. Я был и исполнителем и архитектором и всеми вместе и решил человеку проблему. За 500 рублей. :) Но решил. От начала и до конца. От идеи и до программы.
Не выполнимо другое, написать код большой системы в одиночку. Но имея команду программистов каждый из которых понимает как решить проблему бизнеса вероятность прийти к успеху в этом деле стремится к 1, чего не скажешь о проекте в котором есть один архитектор и куча «исполнителей». Часто такие проекты в итоге терпят фиаско.
Даже в моей пока еще не длинной карьере был один такой проект. Пилили его 3 года но он так и умер не дойдя до MVP. А все потому, что проблемы бизнеса пытались понять от силы 2 программиста из команды в 20+ человек. Остальные считали что их работа — код писать.
lair
"Старая гвардия" — это какого года призыва?
Как раз пока ты пишешь программу один от начала и до конца, архитектором быть легко. Сложно быть архитектором, когда ты не можешь реализовать систему от начала и до конца.
Ээээ… нет. Потому что нет никакой гарантии, что они понимают это одинаково, и поэтому можно получить в системе n несогласованных решений.
… но при этом ему совершенно не обязательно понимать все остальные отчеты (и части системы), не правда ли?
DexterHD
70-ых годов в среднем.
Этой проблемы не было когда программисты выходили из бизнеса и из тех отраслей для которой они решали проблему. А сейчас чтобы решить эту проблему опытные люди придумали Agile (Который к слову разного рода менеджеры не имеющие отношения к IT извратили и превратили в индустрию по выкачиванию денег).
Если этот отчет, сферический конь в вакууме, не обязательно. Если этот отчет важен для бизнеса, он так или иначе отражает очень много бизнес-сущностей и бизнес процессов и да, их надо бы знать, чтобы понимать вообще как этот отчет сделать.
А как стать архитектором сложных систем, которые не можешь написать, если ни когда не решал архитектурные задачи для тех систем которые можно написать в одного? И не понимаешь что ты решаешь проблемы людей а не просто пишешь код?
lair
Да ладно. Вы думаете, что в бизнесе разные люди не могут видеть разных способов решения одной и той же проблемы? Да легко.
Зачем? Достаточно понимать ту конкретную задачу (плюс ее входы), которую решает этот отчет.
А я где-то говорил такое? Я всего лишь говорю, что способность спроектировать маленькую систему не означает способности быть архитектором большой.
ARadzishevskiy Автор
А почему Вы думаете, что в этом проекте нужен был (и был) архитектор??? Простого проектирования, в таких случаях вполне достаточно.И его действительно должен уметь производить программист, если он профессионал.
DexterHD
Где я сказал что там нужен был архитектор? Я вообще говорю о том что такой роли отдельной быть не должно. Понятное дело что огромные системы могут проектировать только очень опытные программисты. Но маленькие системы должны уметь проектировать даже джуны. Все он джунов до CTO должны понимать проблемы бизнеса и так или иначе уметь решать их с помощью кода.
lair
Вы против специализации?
ARadzishevskiy Автор
вот тут
если он был не нужен, то зачем он там был?
ARadzishevskiy Автор
Не буду с ходу отрицать вашу мысль. Попробую еще раз убедить.
следует утверждение: «Любой архитектор — должен быть программистом — профессионалом». Думаю найдется очень много ИТ архитекторов, которые на текущем отрезки свой жизни, уже давно не практикуют кодирование, а есть и те кто вовсе не занимался «высоким» кодированием.1) приведу ассоциацию. Перефразируя Вас, можно предположить, что любой хороший строитель, должен быть архитектором. И соответственно уметь проектировать архитектуру зданий, микрорайонов, городов.
2) исходя из Вашего постулата:
3) аргумент «должен быть» очень абстрактный. По факту, ИТ сообщество, (в том числе ИТ сообщество США не исключение) на основании опыта работ в ИТ индустрии, внедрило стандарты разделяющие ИТ инженеров, на специализации. Вероятно, это вызвано огромным количеством разнообразных направлений работ в процессе производства программных продуктов, требующих очень разных навыков, умений, черт характера и т.п. В общем-то именно об этом статья. Чтобы еще убедительнее донести эту мысль, планирую написать статью «Процесс производства программных продуктов».
Я бы согласился с такой формулировкой: «Большинство программистов, если сильно захотят, могут стать архитекторами». Архитекторы и программисты выполняют разные функции в проектах. Можно ли совместить? В маленьких проектах можно.
DexterHD
Я все это вообще к тому что не по тому срезу мы делим. Т.е. не на архитекторов и кодеров надо делить а на Desktop разработчиков и Mobile разработчиков к примеру.
У программистов есть куча разных специализаций. Эти специализации как правило делят программистов по разнообразным стекам технологий. Для глубокого решения каких то конкретных проблем с использованием данных технологий. Но вот архитектура систем это тот общий базис который всех нас делает профессионалами.
А сейчас у нас в IT получается так:
Только профессиональный терапевт, глав.врач с большим опытом в хирургии и других областях понимает, как ставить диагноз, как лечить пациента и к кому его направлять. Но без него даже понять что с человеком не сможет ни кто
С другой стороны есть хирурги которые знают как резать. Но они не пытаются для начала отправить пациента на обследование и назначить анализы, они даже не знает об этом. Они готовы с ходу резать, остальное их не интересует в принципе.
Архитектура кварталов и городов это к Дизайнерам :). Давайте остановимся на зданиях. Что касается строителей, то да, любой хороший строитель должен быть архитектором в той или иной степени. Думаю вы согласитесь что он должен понимать как в целом строится здание, что оно начинается с фундамента и заканчивается крышей, что в нем есть куча разных систем. Так же любой строитель, если он хороший должен понимать, маяк он строит или колодец.
И это плохо, потому что какой же он архитектор если он понятия не имеет как потом это реализовывать? IT-менеджер, да, архитектор, нет. Если он вообще не программирует как он может создавать программные системы? Пусть идет занимается тем чем должен, решает проблемы программистов, думает над процессами, решает кадровые вопросы. Но как можно подпускать к системам человека который вообще ни строчки кода не пишет и уж тем более если он вообще ни когда его не писал и даже базовых принципов не понимает. Архитектура систем — она всегда 1 к 1 так или иначе превращается в код. Иначе это не архитектура а ни кому не нужные квадратики на которые спустя несколько месяцев разработки никто не смотрит.
И да, я не считаю вашу статью плохой. Вы описали существующее положение вещей. Я просто думаю что существующее положение и деление оно не совсем правильное.
lair
Архитекторы (те, которые архитектурных ансамблей) смотрят на вас с непониманием.
Но зачем?
Понимать — да. Суметь самостоятельно рассчитать — нет. Понимать все системы — тоже нет.
DexterHD
Чтобы вместо маяка не построить колодец, и наоборот.
А потом и имеем в итоге, что монтажники положили высоковольтные кабеля на той же кабельной трассе что и низковольтные сигнальные. Ну а че **** с этой схемой, так же ближе и быстрее. Взял одним пучком и потянул. И пофигу что помехи от выскоковольтных кабелей полностью заглушат сигналы.
lair
Если он будет строить по выданному ему плану, он не построит колодец вместо маяка.
DexterHD
Анекдот есть как раз на эту тему. Достаточно просто перевернуть план вверх ногами и получится отличный колодец с фонарем на дне.
lair
Анекдоты — это, конечно, круто, но если люди не умеют читать чертежи, им лучше не строить по чертежам.
DexterHD
Перефразирую: Если люди не понимают проблемы бизнеса, им лучше не пытаться писать программы решающие проблемы этого бизнеса.
И кстати чертежи как правило отражают результат 1 к 1. Большинство современных схем архитектур нарисованных т.н. архитекторами ПО вообще не соответствуют действительности и тому коду что получается на выходе.
На эту тему кстати тоже проведено куча исследований и работы. Посмотрите например «Simon Brown — Architecture vs Code». Человек много лет посвятил себя проблемам при описании архитектур программных систем. Одна из его моделей достаточно просто позволяет описывать архитектуры таким образом чтобы они отражали и бизнес и код.
lair
Ну да, с этим никто и не пытается спорить. Вот только к архитектуре это отношения не имеет.
DexterHD
… до тех пор пока вы не решаете с помощью IT проблемы бизнеса. А как только начнете решать, с этого момента Архитектура так или иначе будет включать в себя бизнес-сущности, бизнес-правила и бизнес-процессы, а потом все это в том или ином виде так или иначе ляжет в код.
lair
Архитектура, несомненно, будет включать в себя бизнес-сущности. Но это не значит, что каждый, кто решает задачу бизнеса, должен уметь эту архитектуру построить и обосновать.
DexterHD
Мы говорим не про каждого а про IT-специалистов, про программистов которые будут эти бизнес-сущности программировать. Про обоснование вообще не понимаю, перед кем обосновать?
lair
А какая разница? Вот программируешь ты бизнес-сущность "кредитная карта", зачем тебе знание того, что в компании есть enterprise service bus, на другом конце которого сидит система управления складами?
Перед стейкхолдерами, конечно же.
lair
… занятно, кстати. А почему вы не считаете, что каждый строитель должен понимать те проблемы, которые решает строимое им здание?
DexterHD
Должен, но мне если честно не нравится сравнение рядовых программистов с рядовыми штукатурами. Это неверная аналогия в принципе. Под строителями я бы предпочел понимать всех тех кто закончил строительный вуз. Их всех там учат к слову понимать эти все проблемы в том или ином виде.
lair
Почему бы? И те, и другие просто выполняют работу, которая решает задачу бизнеса. Тот же дядюшка Боб об этом пишет.
То есть программисты должны выходить из бизнеса, а строители — заканчивать строительный ВУЗ? Наблюдается неравноправие.
DexterHD
Он должен понимать что водоэмульсионка которую ему вручили как то не очень подходит для покраски стены в порту и надо бы наверное взять водоотталкивающую краску. К слову до этого архитектор при этом просто нарисовал красную стену…
А еще он пишет что все программисты должны понимать проблемы бизнеса. И рассказывает об этом с регулярным постоянством.
Не должны, а выходили на истоках индустрии
lair
Вы не ответили на мой вопрос.
И да, предположим, он понимает, что водоэмульсионка подходит "не очень". Что дальше?
С этим, вроде бы, никто не спорил.
DexterHD
Должен. Но не почему она выше или ниже, он должен понимать ее назначение. Понимая его он будет понимать почему 15 а не 8 и еще много чего другого, как то какую краску выбрать, брать ли стремянку и т.д.
Работа коту под хвост будет. Краска облезет, модуль будет иметь кривой API, программа не будет решать задачи бизнеса.
lair
То есть он должен знать как минимум основы карты ветров в регионе и статистику по высоте волн? Серьезно?
Нет, делать-то ему что?
DexterHD
Чтобы знать её назначение нужна эта информация?
С чем?
Я понимаю, это уже откровенный троллинг, так что извиняйте, кормить вас не буду.
lair
Конечно. Иначе он не поймет, что восьмиметровую стену волна захлестывает, а 15 — нет.
Со своим пониманием, что "водоэмульсионка не очень".
ARadzishevskiy Автор
Как не смешно, но по вашему получается: «Не того человека назвали архитектором». Давайте еще раз по порядку:
Разработчики так или примерно так и делятся. А архитекторы делятся на свои виды (в статье про это написано).
Очень фривольное трактовка навыков и знаний архитекторов — строителей. Их гораздо больше чем просто представление о… Кстати кварталами и городами занимаются не дизайнеры, а как раз архитекторы. И во главе их, как правило, например, в каждом городе стоит главный архитектор города.
Опять непонимание. Читайте требования к ИТ архитекторам ( в том числе возьмите стандарты, разработанные в США). Это в первую очередь управленец, во вторую проектировщик. Проектировщик не должен реализовывать, он должен проектировать. Строить модели, алгоритмы и прочие проектные решения. А реализуют разработчики. Архитекторы больших систем, могут не знать на начальных стадиях: ни языков на которых будут кодировать (их может быть множество в одном проекте), ни платформ, ни систем хранения, ни систем безопасности и т.п. Их, как правило, выбирают на основании начальных этапов проектирования в больших проектах.
DexterHD
Те архитекторы о которых вы говорите вымерли в США еще 20 лет назад по итогу. И ни кому эти люди не нужны, со своим знанием UML и больше ни чего. А архитектурой крупных программных систем как правило там занимаются как раз таки те умудренные опытом люди вышедшие из программистов начинавшие карьеры в 70-ых годах и так или иначе пишущие переодически код до сих пор.
Я пытаюсь сказать, что Архитектор — это ДОЛЖНОСТЬ а не СПЕЦИАЛИЗАЦИЯ. И встать на эту должность может рано или поздно любой программист, если будет развиваться. А вот не программист стать архитектором не сможет НИКОГДА.
ARadzishevskiy Автор
Откуда такая информация? Это что получается UML мертв? а BPMN еще жив или его тоже в топку? А как тогда проектировать? или сразу кодить, а потом по факту разберемся?
ИТ Архитекторов не программистов, есть огромное множество. В частности среди Бизнес Архитекторов. Одна из их основных задач — проектирование бизнес процессов. Кодирования в его функциональных обязанностях вообще нет, хотя они могут использовать языки моделирования
ARadzishevskiy Автор
Вот тут Вы сильно ошибаетесь. Я бы сформулировал это так:
Архитектор — это функциональная роль в процессе производства информационных систем, для которой в этом процессе определен набор выполняемых функций (обязанностей) и определена зона ответственности.
В определенных условиях (обычно это масштабы проекта и сложность), обязанности и ответственность этой функциональной роли могут быть распределены между другими участниками команды, без выделения отдельной персоны(он) на роль Архитектора.
ggo
Это в общем справедливо. Но есть и обратная сторона, стоимость такого подхода и масштабируемость. Очевидно, найти пару десятков супер-работников (разработчики-архитекторы в ИТ, строители-архитекторы на стройке, солдаты-маршалы на войне, продавцы-ceo в бизнесе и т.д.) задача как сложная, так и в какой-то мере бессмысленная.
Но идею, что любой, кто пишет код, должен очень хорошо дружить с головой, целиком и полностью разделяю. Увы и ах, реальность — она про другое.