что такое корпоративный архитектор
Корпоративный архитектор: похож на обычного, только строит не дом, а IT-город
Мало кто понимает, чем занимаются корпоративные архитекторы. Меня зовут Евгений Быстров, я корпоративный архитектор топливно-логистического контура компании «Газпром нефть», я вместе с коллегами занимаюсь построением систем для того, чтобы топливо было доставлено в срок и в полном объеме. Я ищу баланс между локальными задачами команд и стратегическими целями бизнеса.
Чтение займет 8 минут
Для кого: начинающие архитекторы
Текст: Иван Сурвилло
Я учился не на программиста, моя специальность – физика полупроводников. Но мне всегда нравилось программировать. У меня был старенький компьютер, самоучитель по паскалю. Когда мне надо было поступать в универ, я решил, что физика – перспективное направление, но и во время учебы в петербургском Политехе продолжал программировать. Видя мою увлеченность процессом, сестра посоветовала мне пройти курсы по программированию на 1С. Я пошел и уже через месяц заработал свои первые две тысячи рублей. Заказчику нужна была простенькая форма, типа накладной для доставки пиццы. В этот момент я понял, что так можно подрабатывать.
Позже я пришел в фирму, которая занимается проектной деятельностью, вырос с программиста до руководителя проектов и системного архитектора. В зависимости от масштабности проекта я мог быть либо руководителем, либо архитектором, либо и тем и другим.
Дальше был этап, когда я перешел в «Газпром нефть». Вместо нескольких проектов – у меня сначала стало несколько систем (в основном те, которые разработаны на 1С), которые живут в одном контуре. Дальше – больше, системы на разных платформах и с разными задачами: планирование, диспетчеризация, контроль, учет.
Как объяснить близким, кто такой корпоративный архитектор
Если честно,– чем дальше, тем сложнее объяснять близким, кем я работаю. Сначала – программист, тут понятно – на компьютере чего-то делаю, циферки считаются. Потом –руководитель проектов – «прораб» над программистами, все еще понятно. А архитектор.
Системный архитектор как архитектор дома: ты в конкретном здании должен рассчитать нагрузки, посчитать, какие должны быть этажи, какие материалы использовать, какие должны быть вентиляция, лифты.
Я – корпоративный архитектор, то есть архитектор уже не «дома», а «района» или «города». Я должен расположить «дома», «улицы», по которым будут передвигаться «машины», спроектировать детские сады и школы, предусмотреть, где проложить трубы для газа и воды. То есть, если перевести все на IT-термины, системы, интеграционные шины, потоки данных между системами, технические системы, оказывающие вспомогательные функции (например, мониторинг).
Продумывать все это непросто, но, в принципе, когда уже есть опыт работы на разных уровнях, решаемо. Ты же не в вакууме строишь идеальный город, а у тебя на входе всегда какие-то потребности, задачи, наброски инфраструктуры, от которых ты уже отталкиваешься.
О специфике работы
В строительстве IT-архитектуры есть две составляющие: формальная и не очень. Формальная составляющая специфична для «Газпром нефти» и других крупных компаний – у нас есть архитектурные комитеты и технические советы. Чтобы решение попало в продуктив, оно должно быть согласовано с ними. Часть работы архитектора заключается в том, чтобы выбрать такое решение, которое пройдет архитектурный комитет и технический совет. Есть много разных критериев: безопасности, стоимости, оптимальности выбора платформы с точки зрения всевозможных рисков, поддерживаемости.
Неформальная сторона в том, что нужно быть в контакте с проектной командой, направлять разработчиков или подрядчиков в нужную сторону, пытаться помочь всеми возможными способами сделать проект успешным (неважно, входит ли вопрос в понятие архитектуры или нет).
Например, есть платформа 1С, а есть SAP. У нас во многих областях они конкурируют или совместно используются (в том же расчете зарплаты или в складском учете). Когда появляется новый проект, выбираем, какая из этих платформ для решения задач подходит лучше, какое конкретное решение на платформе нужно выбрать и почему.
О разнице между программистом и архитектором
Есть мнение, что корпоративный архитектор не нужен, мол, все могут продумать программисты, которые будут этот проект писать. Но программисты заточены под конкретную платформу 1С, Рython или еще что-то. Программист решает прикладную задачу, которую ему дают. А архитектор выбирает совместно с бизнесом вектор развития системы в целом. В зависимости от вектора у тебя может быть та или иная платформа, те или иные программисты, те или иные задачи. Нужно понять, что хочет бизнес, и перевести это в концепцию, которую можно реализовать.
Программист сделал задачу за день, неделю, месяц – у него быстрый фидбэк, это морально проще. Результат моей работы отложен во времени.
О компромиссах в работе и чувстве неудовлетворенности
Последний компромисс у меня был, когда мы делали интеграцию между одной системой, в которой у нас коммерческие данные, с другой системой, в которой данные по планированию. Изначально понятно, что данные, которые должны быть в учетной системе, понадобятся многим смежным системам, но команда была сильно загружена и мы договорились, что сделаем все по более простой временной концепции, которую потом доработаем до оптимальной.
Если заплаточное решение устраивает бизнес, не противоречит никаким стратегиям и концепциям компании, не наносит вреда в долгосрочной перспективе, то можно оставить и так, хотя в душе остается чувство неудовлетворенности
О влиянии профессии на «обычную» жизнь
Я сравниваю программирование с волшебной палочкой. Я бы никогда не отказался от нее по доброй воле. Магия всегда должна оставаться, просто сейчас я не занимаюсь разработкой по работе, но могу что-то сделать дома для себя или в качестве хобби, чтобы навык оставался. Например, к дачному сезону я изучал разработку на контроллерах типа Arduino и ESP. Теперь у меня «умная дача»: беспроводные контроллеры отвечают за полив теплицы, в мае (когда еще были по ночам заморозки), они автоматически поддерживали в теплице температуру, необходимую для рассады, оросительная система для газона также настроена на автоматический полив. Я с телефона могу видеть текущие показания (температуру, влажность), включать и отключать полив/подогрев/подсветку, когда мне это нужно, или доверить все программе, которую я прошил в контроллеры.
Получается, что моя профессия влияет на мою обычную жизнь. Иногда в мелочах, иногда по-крупному. В мелочах ты видишь, как пробиваются чеки и знаешь, что часть чека можно оплатить картой, а часть наличкой. А кассир этого не знает, и ты можешь эту ситуацию решить. Начинаешь понимать, что, если интернет не работает, надо проверить на своей стороне, а потом уже к провайдеру идти. Если по-крупному, то понимаешь, что подход, в общем-то, применим и в других сферах – в том же строительстве или ремонте, например. То есть знаешь, как тебе распланировать изменения и с чем придется из-за этого мириться.
Большой гайд по профессии архитектора решений (+список полезных ссылок)
Еще лет 10 лет назад роль архитектора решений (Solution Architect) на проектах выполняли сами разработчики. Теперь это отдельная профессия, довольно востребованная и активно обсуждаемая. Вместе с коллегами-архитекторами подробно разбираемся во всех деталях и рассказываем, как стать архитектором в EPAM.
Начнем с азов: что означает слово «решение» в контексте IT?
Это продукт или комплекс продуктов, который решает конкретную техническую или бизнес-задачу. Решение нужно бизнесу, чтобы увеличить прибыль: оно либо повышает доходы, либо снижает издержки — к примеру, автоматизирует бизнес-процессы и тем самым снижает расходы на оплату труда. Решение встраивается в архитектуру предприятия и связывается с другими ее компонентами. Большинство проектов EPAM направлены на создание решений: разработка от начала и до конца или отдельных компонентов.
Выходит, на каждом проекте по разработке нужен архитектор?
Алексей Кожемякин (Director, Technology Solutions, EPAM Belarus):
«Как только инженер задумался о нуждах бизнеса — он ступил на путь Solution Architect».
Почему раньше обходились и без архитекторов?
Роль архитектора решений на проектах играла вся команда целиком, несколько ее членов или один разработчик с высокой квалификацией. Он мог быть сразу и разработчиком, и проектным менеджером, а заодно и архитектором. Со временем (и опытом) пришло понимание, что создание архитектуры слишком важная и объемная задача, чтобы заниматься ей по остаточному принципу.
В отличие от разработчика, архитектор мыслит абстракциями более высокого уровня. Он размышляет не о взаимодействии классов, а о взаимодействии компонентов решения – приложений, веб-сервисов и так далее. Хотя, если требуется, он должен без проблем «провалиться» в детали кода. Кроме этого, бизнес-сторона решения для архитектора важна так же, как и техническая. Разработчики часто фокусируются на технологиях и новых библиотеках, с которыми хочется познакомиться; архитектор же отталкивается от интересов и потребностей заказчика.
Так кто главнее: архитектор или разработчик?
Архитектура и разработка – разные и равноправные направления карьерного пути. Архитектор мыслит более абстрактно, но при этом реже прикасается к коду. К тому же не всегда продумывает все до мелких деталей. Часто команда разработки реализует архитектурную концепцию самостоятельно. А качественно реализовать дизайн решения – это так же важно, как и придумать этот дизайн.
Конкретнее: какими задачами занимается архитектор решений?
В первую очередь архитектор анализирует бизнес-цели заказчика, связанные с новым продуктом. Фокусируется на требованиях, которые повлияют на архитектуру, на программную часть решения и его компоненты. Затем проектирует решение и продумывает его дизайн. Архитектор определяет, из каких компонентов будет состоять продукт, нужно ли разрабатывать его составляющие с нуля или будет уместнее использовать готовые компоненты «из коробки».
Для некоторых частей решения SA делает proof-of-concept – небольшую экспериментально-исследовательскую задачу, чтобы понять, возможно ли реализовать тот или иной функционал.
Архитекторы участвуют в предпродажах, консультируют клиентов, проводят аудит архитектуры существующего решения – оценивают, насколько она эффективна для поставленных задач, можно ли ее оптимизировать, и если да, то как.
В EPAM, например, у архитекторов есть возможность часто менять проекты, что позволяет поработать в разных областях и сферах, напрямую общаться с людьми, непосредственно вовлеченными в основные бизнес- и технологические процессы в компании.
Владимир Казакевич (Senior Solution Architect, EPAM Belarus):
«Каждый понимает слово «бизнес» по-своему. И задача архитектора решений — вникнуть в бизнес заказчика настолько глубоко, насколько это возможно, а главное — результатом его работы должны быть решения, «заточенные» под конкретных заказчиков и их конкретные бизнес-проблемы».
А есть ли какие-то еще архитекторы?
Помимо архитекторов решений это:
Enterprise Architect – создает и поддерживают архитектуру целого предприятия, которая состоит из множества решений.
System Architect – выстраивает инфраструктурную сторону решения, фокусируясь на инфраструктурных облачных сервисах, на ПО, необходимом для поддержки решения после его развертывания.
Quality Architect – выстраивают стратегию тестирования и определяет подход к управлению качеством создаваемого продукта.
В EPAM, например, архитекторы решений пока в большинстве.
Кто может стать архитектором решений?
Роман Шрамков (Director, Technology Solutions, EPAM Ukraine):
«Для того, чтобы бизнес и менеджмент увидел возможности для применения технологий, нужен настоящий гик, который объяснит им какие в этом преимущества и как это можно сделать».
Помимо разработчиков, попробовать себя в архитектуре решений могут бизнес-аналитики, деливери-менеджеры, проектные менеджеры, ресурсные менеджеры, а также тестировщики-автоматизаторы: для них есть даже специальная поддисциплина — Solution Architecture in Test Automation.
Cтоит отметить, что ожидания от такого специалиста у компании и коллег действительно серьезные. Если ошибку в разработке отдельного компонента можно исправить, то неверное решение и плохая архитектура – могут обернуться огромными потерями для обеих сторон.
Дмитрий Гурский (Lead Solution Architect, EPAM Belarus):
«У того, кто хочет стать архитектором, прежде всего, должно быть желание что-то создавать, строить. И это не навык, который можно прокачать, это внутренняя потребность — либо она есть, либо нет».
Какие образовательные программы для будущих архитекторов есть в EPAM?
Так как Solution Architect, как отдельная должность, появилась на рынке сравнительно недавно, ее понимание в разных компаниях отличается. В EPAM создан центр компетенций по архитектуре, команда которого формирует единое представление об этой роли, основываясь на опыте работы с клиентами, их бизнес-задачах и ожиданиях, лучших практиках, внутренних процессах и системах.
Программа, которую разработали практикующие архитекторы и СTOO компании постоянно обновляется. С одной стороны она учитывает индивидуальный опыт сотрудника, а с другой позволяет выбрать образовательный модуль кастомно.
Для начала можно присоединиться к Architecture Excellence Initiative – глобальному архитектурному сообществу EPAM, чтобы быть в курсе последних новостей и тенденций в области архитектуры. Участники комьюнити еженедельно общаются с архитекторами из более чем 25 стран. Оперативный обмен кейсами, доступ к обширной библиотеке и вебинарам, собранной коллегами – это сюда.
Дальше – обучение в Solution Architecture School. Это уникальная программа, которую в компании создавали с нуля: групповые занятия с лекциями и практикой ведут действующие архитекторы компании. Здесь все как в обычной школе – домашние задания, включающие разработку дизайна, постоянное общение с преподавателями и защита контрольной выпускной работы.
Что делать, если пришел в EPAM уже архитектором?
Архитекторы решений, которые пришли в компанию, могут пройти программу Solution Architecture Basics: это своеобразный помощник архитектора, включающий базовые темы, информацию о возможностях профессионального и карьерного развития, полезные контакты и гайды по инфраструктуре. Все, что поможет быстрее адаптироваться в компании.
Архитекторам буду рады в Global Solution Architecture Team – команде экспертов, которые активно участвуют в развитии дисциплины: разрабатывают лучшие практики в компании, координируют глобальные образовательные программы для архитекторов, консультируют коллег и клиентов.
Ну, а если не хочется останавливаться на достигнутом, можно стать студентом Solution Architecture University — трёхуровневой программы, которая помогает опытным архитекторам синхронизировать знания и заговорить на едином языке. У студентов есть возможность пройти сертификации в Software Engineering Institute, IASA Global и других ассоциациях, с которыми сотрудничает EPAM.
Еще одна инициатива — Solution Architecture Mentoring — менторами в которой выступают опытные архитекторы, технические директора и CTO компании. Менти вовлечены в переговоры с клиентами, вместе с наставниками работают над реальными проектами и задачами. Программа помогает архитекторам «прокачаться» в профессии и даже вырасти до уровня CTO.
Что такое корпоративный архитектор
Корпоративный архитектор – это новая специальность IT сферы. Данный специалист занимается разработкой структуры системы корпоративного программного обеспечения. Он отвечает за ее проектирование и контролирует процесс реализации. Такой архитектор принимает решения по внешнему виду и внутренней структуре ПО, сверяется с заданиями проекта и имеющимися ресурсами.
Немного о профессии
Данная профессия появилась относительно недавно, несмотря на то, что теоретически идея и смысл корпоративной архитектуры появились несколько лет назад, когда случился переход к ориентированной на сервис архитектуре. Это дало возможность применить компоненты IT сразу в нескольких приложениях. Поэтому отрасль стала нуждаться в специалисте, который сможет присматривать за компьютерной средой в целом.
Нынешнее развитие информационных технологий является настолько стремительным, что в определенный момент развитие бизнеса перестает им соответствовать. Чтобы поддерживать данный баланс, нужен как раз архитектор, который будет продвинутым специалистом в области информационных технологий. Этот человек должен отлично разбираться также в нюансах определенного бизнеса. Корпоративному архитектору приходится принимать важные ответственные решения, которые связаны с информационными технологиями. При этом нужно учитывать, как они влияют на бизнес и развитие компании.
Таким образом, должность корпоративного архитектора можно назвать самой высокой ступенью карьеры программиста в области информационных технологий, поскольку в компании только этот специалист имеет комплексное видение всей программной системы. Именно архитектору принадлежит право принимать наиболее оптимальные решения относительно дробления системы на модули и поиску способов их взаимодействия, чтобы система в целом лучшим образом отвечала требованиям и пожеланиям заказчика и возможностям ее создателей.
Что делает архитектор?
С учетом специальных требований к тому или иному программному продукту, архитектор создает функциональную и техническую спецификацию системы, технологии и способы технической реализации. Приняв такие решения, команда программистов приступает к проектированию и работе над конкретными модулями.
Помимо всего прочего, архитектору необходимо обладать качествами дальновидного стратега, чтобы система, организованная им, в дальнейшем смогла подвергаться исправлениям, расширению, разработке новых версий.
К обязанностям архитектора в IT сфере относят:
• Создание структуры системы в зависимости от требований заказчика;
• Создание проекта архитектуры приложения, а также обеспечение ее эволюции;
• Выбор определенной технологии для каждого системного модуля;
• Создание рабочей версии;
• Работу над дизайном интерфейса;
• Выбор и утверждение фреймворков;
• Исследование и решение проблем производительности;
• Систематическое изучение кода и дизайна, внесение корректировок, если это нужно.
Архитектура ИТ решений. Часть 2. Архитекторы
С предыдущей частью статьи можно ознакомиться, перейдя по ссылке
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 канале
Об авторских тренингах на тему: «Архитектура ИТ решений» подробнее можно узнать на сайте компании ООО ИЦ Таврида