С предыдущей частью статьи можно ознакомиться, перейдя по ссылке
Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это?
Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня.
Кстати существует профессиональный стандарт квалификационных требований системных архитекторов (5), на основании которых архитектору может быть присвоен один из шести квалификационных уровней. Будем использовать этот стандарт в ходе нашего рассмотрения темы, чтобы не упустить ничего важного в работе ИТ архитектора.
Традиционно начнем с определения:
Из определения следует, что деятельность ИТ архитекторов охватывает очень большой круг вопросов и компетенций. А поэтому есть необходимость делить ее по специализациям, например, соответствующим разделам архитектуры, рассмотренными нами в предыдущем разделе: Enterprise — Архитектор, Solution — Архитектор, Technical — Архитектор.
Чаще на практике можно встретить деление на: Бизнес — архитекторов и Технических архитекторов. При этом:
Бизнес-архитектор описывает предприятие с позиции логических терминов, таких как взаимодействующие бизнес-процессы и бизнес-правила, необходимая информация, структура и потоки информации.
Архитектор информационных технологий описывает предприятие с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, защита и безопасность.
Итак, каков же набор профессиональных активностей должен вменяться в обязанности ИТ архитектора?
Для всех специализаций актуальны следующие тренды:
Читая статьи архитекторов о самих себе, в каждом абзаце чувствуется особая значимость этой позиции, принадлежность к высшей касте ИТ специалистов, не двусмысленно дающая понять, что их – архитекторов, на земле не так уж и много. Видимо и стать архитектором можно только обладая целым набором способностей, знаний и навыков. Чаще всего в литературе выделяют следующие:
Итак, что же делает архитектора такой важной и эксклюзивной персоной в организации?
Мы только вкратце затронули основные нормы, которым должен соответствовать специалист, чтобы сгодиться в ИТ архитекторы. Теперь определим место ИТ архитектора в ИТ мире, под ласковым ИТ солнцем. Схематично, в упрощенном виде на рисунке 5 изображено представление возможного устройства взаимодействия ИТ архитектора с другими участниками процесса производства программных продуктов. Объективности ради, свою точку зрения на сам процесс производства информационных систем, я подробно изложил В статье
Рисунок 5. Структура взаимодействия ИТ архитектора
Как видно из рисунка, ИТ-архитектор действительно является центровой фигурой, в ходе создания информационной системы. Именно от его героических усилий глобально зависит успешность проекта, как в угоду заказчика, так и в интересах исполнителей. А теперь обо всем по порядку.
Чаще всего процесс производства программных продуктов начинается с зарождения у заказчика потребности в том или ином поступательном движении к собственному развитию. При этом, как правило, у него уже существует некая архитектура предприятия. Ведь выполняются какие-то процессы, существует организационная структура, регламенты взаимодействия. Наконец, наверняка должны быть вычислительные устройства, соединенные в сеть и какое-то программное обеспечение. Поэтому первое, чем должен озаботиться ИТ архитектор – это описание текущей архитектуры, базового ее состояния. И уже отталкиваясь от сего понимания, определив узкие места и дискомфортное, с точки зрения предприятия обустройство ее жизнедеятельности, проектировать новую, желаемую модель архитектуры, которую называют целевой. В вышеупомянутом документе с квалификационными требованиями, эта активность регламентирована как: «Сбор и анализ требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения» (5).
И в этом контексте необходимо четко осознавать, что редкий заказчик долетит в своем воображении хотя бы до середины реки своих реальных потребностей и сможет толково сформулировать, что же ему действительно надобно. В лучшем случае можно услышать, что он хочет. А это, с тем что ему нужно, как говорится, две большие разницы. Чаще всего на практике желания заказчика толмачат бизнес аналитики. Но даже при таком положении дел, архитектору надлежит контролировать этот процесс и, с высоты своего опыта и навыков, помогать выполнить эту задачу максимально качественно. Все ж таки на основании этих материалов и должна зародиться ИТ стратегия предприятия в части бизнес-архитектуры, системной архитектуры и мероприятий, позволяющих осуществить качественный скачек от базовой к целевой архитектуре.
Это пожалуй самый замечательный период, наполненный творчеством и открытиями. Заказчик сидит с открытым ртом и ловит каждую фразу фантастических историй о своей, теперь уже неизбежно беззаботной жизни. В округленных глазах читается лишь один немой вопрос: «А что так можно было?».
Для удобства восприятия и обсуждения, стратегия делится на сегменты, приоритезируется и обсчитывается на предмет трудозатрат, с прецизионностью «что-то около того». Этот документ становится предметом обсуждения и торга межу заказчиком (потребителем новаций), подрядчиками (исполнителями работ) и возможно, спонсорами, от которых требуется оплатить все эти изыски. Для проведения подобных работ ИТ архитектор должен уметь понимать бизнес и говорить с ним на одном (их родном) языке, максимально убедительно презентуя свои решения. В квалификационных требованиях, по этому поводу предписано: «Участие во взаимодействии с заказчиком по обсуждению проектных решений. Участие во взаимодействии с заказчиком по вопросам бюджетных расходов и сдачи проекта» (5).
Если концепция архитектуры и стратегия перехода к ней получили признание всех заинтересованных лиц и прошли горнило финансово-договорных испытаний, для дальнейшего производства информационной системы, необходимо разработать техническую документацию, включая Техническое задание. С этой задачей архитекторам чаще всего помогают справиться помощники, в виде: бизнес и системных аналитиков, технических писателей и прочих соучастников. Архитектор, в зависимости от своих предпочтений, возможностей и личной внутренней «коллективной интеллигентности», может в разной степени принимать персональное участие в данном процессе. Но основная его забота и ответственность — соблюсти строгое следование разработанной архитектуре и, в случае острой необходимости, зафиксировать изменения в ней. В квалификационных требованиях, это отмечено как: «Разработка требований различных типов к программному изделию. Обеспечение корректности и оптимальности архитектуры проекта. Участие в документировании проекта» (5).
В равной мере, на совести архитектора лежит еще и контроль полноты и комплектности артефактов, генерируемых проектной командой. Ведь они послужат основой для выполнения дальнейших работ по разработке собственно самого программного продукта, а также его тестированния, внедрения, поддержки и т.п. Все артефакты должны соответствовать стандартам фреймверка, выбранного в интересах предприятия, и призванного обеспечить полномасштабную поддержу описания архитектуры см. раздел II.2. Ведь как мы отметили в предыдущей части, именно наличие одних архитектурных артефактов в череде проектирования, предоставляет возможность для создания на их базе — следующих в цепочке артефактов. Этот технологический конвейер, должен шаг за шагом заполнять все пустоты в каркасе представления архитектуры предприятия. Об этом в квалификационных требованиях, естественно тоже упомянуто: «Контроль проектной и технической документации. Разработка концепции реализации системы программного изделия по спецификациям» (5).
Еще один важный аспект трудовой повинности архитектора – это определение экономической и деловой целесообразности внедрения целевой архитектуры. И в этом деле его главная опора и поддержка — руководитель проекта, а также руководители ключевых подразделений, участвующих в процессе разработки и внедрения информационной системы. Именно с их помощью архитектор должен определить возможность выполнения проекта в принципе, и в заданных рамках трудовых, финансовых и прочих затрат в частности. В квалификационных требованиях, указано: «Участие в планировании проекта, Участие в управлении проектом. Координация сбора и анализа требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения» (5).
Ну и конечно одной из центральной функций архитектора является контроль качества производства самого целевого продукта и его соответствия — концепции архитектуры. В квалификационных требованиях: «Контроль исполнения архитектурных решений. Анализ качества продукта и его соответствия требованиям и спецификациям» (5).
Контроль должен охватить все мероприятия, направленные на достижение выработанной стратегии ИТ модернизации предприятия. Включая, например, указанную в квалификационных требованиях: «Организацию и планирование тестирования» (5).
Это также означает, что работа архитектора не заканчивается с выпуском крайнего релиза, передаваемого заказчику. Напротив, это всего лишь знаменует завершение более менее спокойной жизни, творческого и захватывающего периода, и переход к новому в эмоциональном плане этапу работ. Закончен конфетно-букетный период общения с заказчиком, наступает момент истины. Маски сорваны, у всех открываются глаза на всамделишное лицо, так искусно и лицемерно скрываемое доселе. Заказчик чувствует себя обманутым. Ему бессовестно подсовывают совсем не то, что пообещали. Мало того, это «не то» еще и сбоит, зависает, ведет себя как вредитель, пряча все время куда-то самые важные данные. Это с одной стороны баррикад. А с другой — безрукие, неадекватные пользователи, все время жмут не на те кнопки, как-то отыскивают такие закоулки программных возможностей, которые в принципе невозможны, и от которых она просто беспомощно впадает в ступор.
К чему я это все? А к еще одной важной функции архитектора — оптимизации решения, исправления недоработок, устранению недокументированных функций системы, открытых любознательными пользователями и т.п. Естественно, чем качественнее была спроектирована, реализована и внедрена информационная система, тем меньше масштабы подобных бедствий и быстрее можно перейти к последующему этапу ее жизни. В квалификационных требованиях, этому соответствует: «Участие в оптимизации и исправлении реализованного программного обеспечения. Участие в сопровождении программного продукта. Обучение и содействие повышению квалификации персонала» (5).
По мере стабилизации работы информационной системы, накал потихоньку снижается. Отчаяние сменяется неизбежностью того, что одни выкинули деньги на ветер, а другие потеряли в пустую время, силы и репутацию. Но отступать поздно, да и потраченного так жалко. Неизбежность перерастает в равнодушие, и это заставляет противоборствующих ослабить хватку и поднять забрала. А под ними становится заметно движение губ. Очевидно, что они хотят что-то сказать. Оппоненты начинают прислушиваются друг к другу. Начинается взаимное движение на встречу. Нет, отношения все еще напряженные, осадчик то остался. Роль архитекторов и на этапе конфронтации тяжело переоценить, поскольку они отчетливее всех представляют себе, где произошел раскол в понимании, по какой причине, и именно от них ждут решения, ведущего к позитивным изменениям. Такая эмоциональная нагрузка требует от сотрудников, соответствующей физической и психологической стойкости. Проявления дипломатичности, сдержанности, если хотите — мудрости.
И вот через некоторое время, программный комплекс уже работает как часы, а в памяти пользователей стираются былые сложности. Даже сбои в системе теперь порождают не раздражение и скандалы пользователей и их начальства, а всеобщую мобилизацию, основанную на понимании сложности продукта, бизнес правил, взаимосвязи множества компонентов системы, а главное — неминуемого и неотвратимого разрешения любых проблем. И теперь разработчики системы уже точно не враги, их даже рекомендуют другим организациям, как классных специалистов, способных в кратчайшие сроки безо всяких проблем, автоматизировать процессы любой сложности.
Из вышесказанного понятно, насколько важна качественная работа специалистов архитектурного цеха на всех этапах производства информационных систем.
Не лишне упомянуть, что во всех рассмотренных аспектах работы архитектора от него требуется постоянный, плотный контакт с командой. Причем большая часть общения происходит не на уровне «начальник – подчиненный», а на уровне «партнеры по команде». Поскольку взаимодействие в проекте, чаще всего, основано на матричной структуре управления, и у большинства исполнителей есть свои линейные руководители. В этих реалиях архитектору важно суметь выстроить свой непререкаемый авторитет в команде и найти подходы к ее ключевым игрокам на разных уровнях и ярусах организации.
Вспомнился случай мастеркласса, когда в процесс ожесточенной баталии между специалистами заказчика ИТ продукта и командой исполнителей, вмешался архитектор решения, человек совсем не воинственного вида. Своими четкими, уместными уточнениями и разъяснениями, не повышая голоса, он перехватил инициативу в дискуссии и заставил всех внимать каждому своему слову. Никого не хочу обидеть, но выглядело это, как общение удава Ка с бандерлогами, в известном мультфильме. В результате вопросы были решены, заказчик удовлетворен, а команда прочувствовала свою защищенность, ощутив себя как за «каменной стеной».
Подытожим рассмотренный материал.
Более подробно ознакомиться с материалом можно на: Youtub канале
Об авторских тренингах на тему: «Архитектура ИТ решений» подробнее можно узнать на сайте компании ООО ИЦ Таврида
III Определение понятия архитектор
Врач может похоронить свою ошибку,
архитектор – разве что обсадить стены плющом.
Фрэнк Ллойд Райт.
Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это?
Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня.
Кстати существует профессиональный стандарт квалификационных требований системных архитекторов (5), на основании которых архитектору может быть присвоен один из шести квалификационных уровней. Будем использовать этот стандарт в ходе нашего рассмотрения темы, чтобы не упустить ничего важного в работе ИТ архитектора.
1. Обзор обязанностей и ответственности ИТ архитектора
Традиционно начнем с определения:
ИТ-архитектор — это специалист, который решает, как в конечном итоге будет выглядеть информационная система организации в целом и в деталях. Основная цель ИТ-архитектора в компании заключается в том, чтобы обеспечить решение задач бизнеса при помощи информационных технологий. Причем, он должен не только сформировать решение, но и контролировать правильность его реализации. Также эти специалисты занимаются разработкой, созданием и поддержанием структуры программного обеспечения, сети, сервера, отдельного модуля в программе. Они прорабатывают архитектурные шаблоны, сценарии взаимодействия компонентов, выбирают средства исполнения, определяют формат хранения и передачи данных. (6)
Из определения следует, что деятельность ИТ архитекторов охватывает очень большой круг вопросов и компетенций. А поэтому есть необходимость делить ее по специализациям, например, соответствующим разделам архитектуры, рассмотренными нами в предыдущем разделе: Enterprise — Архитектор, Solution — Архитектор, Technical — Архитектор.
Чаще на практике можно встретить деление на: Бизнес — архитекторов и Технических архитекторов. При этом:
Бизнес-архитектор описывает предприятие с позиции логических терминов, таких как взаимодействующие бизнес-процессы и бизнес-правила, необходимая информация, структура и потоки информации.
Архитектор информационных технологий описывает предприятие с позиции технических понятий, таких как аппаратные и компьютерные средства, программное обеспечение, защита и безопасность.
Итак, каков же набор профессиональных активностей должен вменяться в обязанности ИТ архитектора?
Для всех специализаций актуальны следующие тренды:
- Анализ и оценка существующего состояния дел;
- Проектирование решений для создания сложных информационно- программных комплексов, от высокоуровневых представлений до детальных. Оценка выполнимости и ресурсоемкости решений;
- Фиксация своих решений в виде различных артефактов и документов, доступных для понимания заинтересованными лицами;
- Ответственность за целесообразность и эффективность принятых решений;
- Контроль качества и полноты воплощения в жизнь своих решений;
- Поддержание своих решения в актуальном состоянии, при подверженности их внешнему влиянию;
Читая статьи архитекторов о самих себе, в каждом абзаце чувствуется особая значимость этой позиции, принадлежность к высшей касте ИТ специалистов, не двусмысленно дающая понять, что их – архитекторов, на земле не так уж и много. Видимо и стать архитектором можно только обладая целым набором способностей, знаний и навыков. Чаще всего в литературе выделяют следующие:
- Широкий кругозор, который необходимо постоянно поддерживать. Включая не только технологическую сторону, но и социальные моменты, аспекты экономической целесообразности и т.п.;
- Умение работать в коллективе, завоевывать авторитет, управлять командой, проявлять дипломатичность;
- Развитое чувство ответственности;
- Способность и потребность к самообразованию;
- Умение четко, доступно и аргументировано доносить свою точку зрения;
- Чувство пропорции;
- Умение чувствовать тенденции: изменений, развития, востребованности и т.п.;
Итак, что же делает архитектора такой важной и эксклюзивной персоной в организации?
2. Место ИТ Архитектора в процессе производства информационных систем
Мы только вкратце затронули основные нормы, которым должен соответствовать специалист, чтобы сгодиться в ИТ архитекторы. Теперь определим место ИТ архитектора в ИТ мире, под ласковым ИТ солнцем. Схематично, в упрощенном виде на рисунке 5 изображено представление возможного устройства взаимодействия ИТ архитектора с другими участниками процесса производства программных продуктов. Объективности ради, свою точку зрения на сам процесс производства информационных систем, я подробно изложил В статье
Рисунок 5. Структура взаимодействия ИТ архитектора
Как видно из рисунка, ИТ-архитектор действительно является центровой фигурой, в ходе создания информационной системы. Именно от его героических усилий глобально зависит успешность проекта, как в угоду заказчика, так и в интересах исполнителей. А теперь обо всем по порядку.
Чаще всего процесс производства программных продуктов начинается с зарождения у заказчика потребности в том или ином поступательном движении к собственному развитию. При этом, как правило, у него уже существует некая архитектура предприятия. Ведь выполняются какие-то процессы, существует организационная структура, регламенты взаимодействия. Наконец, наверняка должны быть вычислительные устройства, соединенные в сеть и какое-то программное обеспечение. Поэтому первое, чем должен озаботиться ИТ архитектор – это описание текущей архитектуры, базового ее состояния. И уже отталкиваясь от сего понимания, определив узкие места и дискомфортное, с точки зрения предприятия обустройство ее жизнедеятельности, проектировать новую, желаемую модель архитектуры, которую называют целевой. В вышеупомянутом документе с квалификационными требованиями, эта активность регламентирована как: «Сбор и анализ требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения» (5).
И в этом контексте необходимо четко осознавать, что редкий заказчик долетит в своем воображении хотя бы до середины реки своих реальных потребностей и сможет толково сформулировать, что же ему действительно надобно. В лучшем случае можно услышать, что он хочет. А это, с тем что ему нужно, как говорится, две большие разницы. Чаще всего на практике желания заказчика толмачат бизнес аналитики. Но даже при таком положении дел, архитектору надлежит контролировать этот процесс и, с высоты своего опыта и навыков, помогать выполнить эту задачу максимально качественно. Все ж таки на основании этих материалов и должна зародиться ИТ стратегия предприятия в части бизнес-архитектуры, системной архитектуры и мероприятий, позволяющих осуществить качественный скачек от базовой к целевой архитектуре.
Это пожалуй самый замечательный период, наполненный творчеством и открытиями. Заказчик сидит с открытым ртом и ловит каждую фразу фантастических историй о своей, теперь уже неизбежно беззаботной жизни. В округленных глазах читается лишь один немой вопрос: «А что так можно было?».
Для удобства восприятия и обсуждения, стратегия делится на сегменты, приоритезируется и обсчитывается на предмет трудозатрат, с прецизионностью «что-то около того». Этот документ становится предметом обсуждения и торга межу заказчиком (потребителем новаций), подрядчиками (исполнителями работ) и возможно, спонсорами, от которых требуется оплатить все эти изыски. Для проведения подобных работ ИТ архитектор должен уметь понимать бизнес и говорить с ним на одном (их родном) языке, максимально убедительно презентуя свои решения. В квалификационных требованиях, по этому поводу предписано: «Участие во взаимодействии с заказчиком по обсуждению проектных решений. Участие во взаимодействии с заказчиком по вопросам бюджетных расходов и сдачи проекта» (5).
Если концепция архитектуры и стратегия перехода к ней получили признание всех заинтересованных лиц и прошли горнило финансово-договорных испытаний, для дальнейшего производства информационной системы, необходимо разработать техническую документацию, включая Техническое задание. С этой задачей архитекторам чаще всего помогают справиться помощники, в виде: бизнес и системных аналитиков, технических писателей и прочих соучастников. Архитектор, в зависимости от своих предпочтений, возможностей и личной внутренней «коллективной интеллигентности», может в разной степени принимать персональное участие в данном процессе. Но основная его забота и ответственность — соблюсти строгое следование разработанной архитектуре и, в случае острой необходимости, зафиксировать изменения в ней. В квалификационных требованиях, это отмечено как: «Разработка требований различных типов к программному изделию. Обеспечение корректности и оптимальности архитектуры проекта. Участие в документировании проекта» (5).
В равной мере, на совести архитектора лежит еще и контроль полноты и комплектности артефактов, генерируемых проектной командой. Ведь они послужат основой для выполнения дальнейших работ по разработке собственно самого программного продукта, а также его тестированния, внедрения, поддержки и т.п. Все артефакты должны соответствовать стандартам фреймверка, выбранного в интересах предприятия, и призванного обеспечить полномасштабную поддержу описания архитектуры см. раздел II.2. Ведь как мы отметили в предыдущей части, именно наличие одних архитектурных артефактов в череде проектирования, предоставляет возможность для создания на их базе — следующих в цепочке артефактов. Этот технологический конвейер, должен шаг за шагом заполнять все пустоты в каркасе представления архитектуры предприятия. Об этом в квалификационных требованиях, естественно тоже упомянуто: «Контроль проектной и технической документации. Разработка концепции реализации системы программного изделия по спецификациям» (5).
Еще один важный аспект трудовой повинности архитектора – это определение экономической и деловой целесообразности внедрения целевой архитектуры. И в этом деле его главная опора и поддержка — руководитель проекта, а также руководители ключевых подразделений, участвующих в процессе разработки и внедрения информационной системы. Именно с их помощью архитектор должен определить возможность выполнения проекта в принципе, и в заданных рамках трудовых, финансовых и прочих затрат в частности. В квалификационных требованиях, указано: «Участие в планировании проекта, Участие в управлении проектом. Координация сбора и анализа требований к разрабатываемой компоненте, оценка осуществимости и выработка критериев их выполнения» (5).
Ну и конечно одной из центральной функций архитектора является контроль качества производства самого целевого продукта и его соответствия — концепции архитектуры. В квалификационных требованиях: «Контроль исполнения архитектурных решений. Анализ качества продукта и его соответствия требованиям и спецификациям» (5).
Контроль должен охватить все мероприятия, направленные на достижение выработанной стратегии ИТ модернизации предприятия. Включая, например, указанную в квалификационных требованиях: «Организацию и планирование тестирования» (5).
Это также означает, что работа архитектора не заканчивается с выпуском крайнего релиза, передаваемого заказчику. Напротив, это всего лишь знаменует завершение более менее спокойной жизни, творческого и захватывающего периода, и переход к новому в эмоциональном плане этапу работ. Закончен конфетно-букетный период общения с заказчиком, наступает момент истины. Маски сорваны, у всех открываются глаза на всамделишное лицо, так искусно и лицемерно скрываемое доселе. Заказчик чувствует себя обманутым. Ему бессовестно подсовывают совсем не то, что пообещали. Мало того, это «не то» еще и сбоит, зависает, ведет себя как вредитель, пряча все время куда-то самые важные данные. Это с одной стороны баррикад. А с другой — безрукие, неадекватные пользователи, все время жмут не на те кнопки, как-то отыскивают такие закоулки программных возможностей, которые в принципе невозможны, и от которых она просто беспомощно впадает в ступор.
К чему я это все? А к еще одной важной функции архитектора — оптимизации решения, исправления недоработок, устранению недокументированных функций системы, открытых любознательными пользователями и т.п. Естественно, чем качественнее была спроектирована, реализована и внедрена информационная система, тем меньше масштабы подобных бедствий и быстрее можно перейти к последующему этапу ее жизни. В квалификационных требованиях, этому соответствует: «Участие в оптимизации и исправлении реализованного программного обеспечения. Участие в сопровождении программного продукта. Обучение и содействие повышению квалификации персонала» (5).
По мере стабилизации работы информационной системы, накал потихоньку снижается. Отчаяние сменяется неизбежностью того, что одни выкинули деньги на ветер, а другие потеряли в пустую время, силы и репутацию. Но отступать поздно, да и потраченного так жалко. Неизбежность перерастает в равнодушие, и это заставляет противоборствующих ослабить хватку и поднять забрала. А под ними становится заметно движение губ. Очевидно, что они хотят что-то сказать. Оппоненты начинают прислушиваются друг к другу. Начинается взаимное движение на встречу. Нет, отношения все еще напряженные, осадчик то остался. Роль архитекторов и на этапе конфронтации тяжело переоценить, поскольку они отчетливее всех представляют себе, где произошел раскол в понимании, по какой причине, и именно от них ждут решения, ведущего к позитивным изменениям. Такая эмоциональная нагрузка требует от сотрудников, соответствующей физической и психологической стойкости. Проявления дипломатичности, сдержанности, если хотите — мудрости.
И вот через некоторое время, программный комплекс уже работает как часы, а в памяти пользователей стираются былые сложности. Даже сбои в системе теперь порождают не раздражение и скандалы пользователей и их начальства, а всеобщую мобилизацию, основанную на понимании сложности продукта, бизнес правил, взаимосвязи множества компонентов системы, а главное — неминуемого и неотвратимого разрешения любых проблем. И теперь разработчики системы уже точно не враги, их даже рекомендуют другим организациям, как классных специалистов, способных в кратчайшие сроки безо всяких проблем, автоматизировать процессы любой сложности.
Из вышесказанного понятно, насколько важна качественная работа специалистов архитектурного цеха на всех этапах производства информационных систем.
Не лишне упомянуть, что во всех рассмотренных аспектах работы архитектора от него требуется постоянный, плотный контакт с командой. Причем большая часть общения происходит не на уровне «начальник – подчиненный», а на уровне «партнеры по команде». Поскольку взаимодействие в проекте, чаще всего, основано на матричной структуре управления, и у большинства исполнителей есть свои линейные руководители. В этих реалиях архитектору важно суметь выстроить свой непререкаемый авторитет в команде и найти подходы к ее ключевым игрокам на разных уровнях и ярусах организации.
Вспомнился случай мастеркласса, когда в процесс ожесточенной баталии между специалистами заказчика ИТ продукта и командой исполнителей, вмешался архитектор решения, человек совсем не воинственного вида. Своими четкими, уместными уточнениями и разъяснениями, не повышая голоса, он перехватил инициативу в дискуссии и заставил всех внимать каждому своему слову. Никого не хочу обидеть, но выглядело это, как общение удава Ка с бандерлогами, в известном мультфильме. В результате вопросы были решены, заказчик удовлетворен, а команда прочувствовала свою защищенность, ощутив себя как за «каменной стеной».
3. Резюме раздела
Подытожим рассмотренный материал.
- В связи с широчайшим кругом функциональных обязанностей, ИТ архитекторы делятся по специализациям. Каждая специализация охватывает конкретный круг вопросов, требующих владения определенными компетенциями, навыками и знаниями.
- Успешно выполнять функции архитектора может только специалист, обладающий определенным набором способностей и поведенческих моделей, с явно выраженным потенциалом развития.
- Архитектор должен обладать целым рядом компетенций, позволяющих ему–оценивать текущее состояние дел на предприятии, определять проблемы и узкие места, разрабатывать целевую архитектуру и формировать стратегию перехода к ней.
- Одним из архиполезных навыков архитектора является умение квалифицированно и эффективно общаться с разными группами заинтересованных лиц, учитывая их квалификацию, сферу деятельности и даже социальный статус.
- Архитектор должен уметь качественно оценивать деловые и экономические аспекты, предлагаемых им стратегий.
- Одной из важнейших функций архитектора является контроль, за качественным описанием архитектуры, соблюдением архитектурных решением в процессе производства информационной системы, качеством и точностью выполнения мероприятий по воплощению разработанной стратегии.
Более подробно ознакомиться с материалом можно на: Youtub канале
Об авторских тренингах на тему: «Архитектура ИТ решений» подробнее можно узнать на сайте компании ООО ИЦ Таврида
Список литературы
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, свободный. — Загл. с экрана.
