айти архитектор что это
Кто такой архитектор в ИТ и как им стать
Сам код не пишет, а другие — пишут.
Если нужно построить здание, компания нанимает архитектора. Он придумает, как здание будет выглядеть, из чего состоять и как им будут пользоваться. В разработке тоже есть архитекторы, и делают они примерно то же самое: решают, как в целом будет работать программа и какие технологии будут использоваться.
Что делает архитектор
Задача архитектора в ИТ — продумать и принять ключевые решения по проекту:
👉 Архитектор не лезет в код, а работает с проектом на верхнем уровне — идей, смыслов и стратегических решений. Например, одна из задач архитектора — выбрать такой набор языков и библиотек, чтобы он не устарел, пока пилится продукт, и эти языки поддерживались ещё несколько лет после выпуска проекта.
С этой точки зрения будет глупо выбрать основным языком Python 2.x, потому что официальная поддержка уже прекращена. Даже если в компании есть команда гениальных программистов именно на Python 2.x, то проект всё равно лучше делать на третьей версии.
Архитектор и программисты
Хоть сам архитектор не пишет код (или делает это в исключительных случаях), но его работа влияет на всех остальных членов команды:
Какие бывают архитекторы ПО
Среди архитекторов в ИТ тоже есть свои специализаци и направления.
Например, если компании нужно выбрать язык, технологии и фреймворки, чтобы написать самую быструю программу, то зовут software-архитектора. Ещё он нужен, когда в программе планируется много разных модулей и их нужно грамотно соединить друг с другом.
Если задача — интегрировать программу в другую большую систему или развивать уже готовый продукт, то здесь будет больше полезен solution-архитектор. Он прикинет все возможные варианты, просчитает их плюсы и минусы и найдёт оптимальное решение.
Отдельное направление — архитектор баз данных. Он требуется, когда в проекте планируется сложная база с кучей связей, и от того, как она будет спроектирована, зависит быстродействие и надёжность. Такие архитекторы изучают требования к данным, к их обработке и исходя из этого строят идеальную схему базы под этот конкретный проект.
Зарплата архитектора
По данным Хабр Карьеры, средняя зарплата архитектора ПО —
275 000 рублей в месяц.
Интересно, что джуниоров среди архитекторов нет — вакансии начинаются от мидла, но в основном требуются сеньоры.
Как им стать
Обычно архитекторами становятся сеньоры, которые давно и хорошо знают свою область, технологический стек и различные стандарты сборки для разных проектов. Им уже неинтересно просто программировать — у них достаточно знаний, чтобы заранее предвидеть возможные проблемы в разработке всех частей программы и сразу их учесть в решении.
Поэтому ответ на вопрос «Как стать архитектором» будет такой: изучайте свою и соседние специальности настолько хорошо, насколько это возможно, участвуйте во многих проектах и нарабатывайте опыт.
👉 Архитектор = сеньор + опыт + умение видеть картину в целом.
Кто такой системный архитектор
— Почему я здесь?
— Твоя жизнь — это сумма остатков неуравновешенного уравнения, свойственного программированию Матрицы. Ты — возможный результат аномалии, которую, несмотря на мои искренние усилия, мне не удалось устранить из того, что в противном случае было бы гармонией математической точности.
Мир развивается. Прогресс не стоит на месте. То, что когда-то казалось фантастикой, сейчас становится обыденностью. Всё стремится к технологической сингулярности, совершенству и удобству — минимум действий, максимум возможностей. Это неспроста, ведь вычислительные платформы усложняются и множатся, возникают новые инструменты для преодоления тех или иных проблем и задач. И так сложилось, что сегодня любое крупное или не очень цифровое решение является сложной структурой, которая разработана под конкретные запросы и требования заказчика. Потому, чтобы не было проблем, а проект отработан четко, нужны люди с соответствующей квалификацией. А значит, сегодня мы поговорим за профессию 21 века — системного архитектора. Работа, связанная с проектированием IT-инфраструктуры информационных систем, высоко ценится на рынке труда. Ведь условия в нашем быстро меняющемся мире таковы, что цифровые нововведения становятся все более и более распространенными, они внедряются не только на корпоративном уровне, но и банально, даже в обычном быту. Следовательно, появляется необходимость в специалистах, которые могут проанализировать все процессы использования цифровых технологий на разных уровнях и создать единую архитектуру организации.
А в чём заключается работа IT-архитектора?
Множество вещей предстоит сделать системному архитектору во время работы над проектом, но большинство из них определяются надобностью в данный момент, сложностью самого проекта и, конечно же, квалификацией самого архитектора, но даже из довольно массивного перечня задач можно выделить основные:
Олег Филимошин — архитектор Timeweb Cloud
По своей сути, выражаясь художественно, системные архитекторы — это первокрасные кардиологи-хирурги от мира IT, проводя высококлассные операции на «сердце» IT-инфраструктуры. Потому, крупный бизнес, чья инфраструктура построена на взаимодействии между технологическими элементами, не выжила бы в столь суровом мире цифровых технологий.
Какие знания будут полезны системному архитектору?
Требования к кандидатам на должность инженера проекта довольно высокие, что уже можно понять по сфере деятельности данной профессии. Есть ряд обязательных и желательных навыков, которыми должен обладать человек, претендующий на это место. Рассмотрим самые важные аспекты.
Одного знания языков программирования недостаточно, поскольку главное требование —иметь практический опыт, то есть напрямую участвовать в разработке. В вакансиях вы часто увидите такие требования:
К часто требуемым навыкам еще можно отнести качества общего характера, то есть умение отстаивать свою точку зрения, настаивать на решениях, защищать позицию и искать компромиссы между сторонами.
Каким образом можно попасть на должность системного архитектора?
Добро пожаловать в профессию
Высшее образование в нынешнее время не во всех ситуациях является определяющим требованием, но специальное техническое точно может оказаться полезным. Больше всего внимание обращают именно на практические умения и понимание работы в целом. Очень часто компании выбирают на эту должность именно тех сотрудников, которые имеют опыт работы с подобными проектами. Или вовсе повышают сотрудников, которые уже работает в данной компании, так как им проще будет руководить, опираясь на уже имеющиеся знания о проекте.
Существует ли на этой должности «карьерная лестница»?
В рамках самой работы главным инженером проекта может только возрастать объёмность и сложность проектов, а соответственно и оплата. Но сама по себе подобная работа позволяет набрать достаточно опыта в любом направлении, которое будет интересно, за счёт того, что приходится следить и организовывать совместную работу многих отделов проекта, попутно в ней участвуя. Набрав нужных знаний и получив достаточно навыков можно выбрать любое направление в IT сфере и развиваться в нём дальше.
Сколько зарабатывают системные архитекторы?
Это вопрос, который наверняка волнует любого человека, ведь сама по себе работа весьма непростая, а значит и заработная плата должна быть соизмеримой. На следующем скриншоте вы видите выдачу четырех последних загруженных вакансий на Headhunter по Москве. Если же самому заглянуть на сайт, то вряд ли вы найдёте зарплату меньше 150 тыс. р., а основная масса компаний предлагает зарплату в районе 300-400 тысяч. Немногие вакансии в IT сфере могут так же хорошо оплачиваться, как системный архитектор.
Сравнить, допустим, можно с PHP-разработчиком, чья оплата труда в среднм составляет 150-200 тыс. рублей. Как другой пример можно взять должность технического директора,
также посмотрев вакансии по Москве, чья зарплата начинается от 5 тыс. долларов, но которая относится к высшему менджменту и требует участия во всех до единого технических процессах.
Откликаются на эти вакансии не так много соискателей, в некоторых случаях можно вполне себе оказаться первым, и всё потому, что у многие разработчики не имеют достаточного опыта и навыков, чтобы к тому же быть ещё и человеком, понимающем в бизнесе. Опытных архитекторов тоже не хватает, для того, чтобы была сильная конкуренция на данную вакансию.
Вместо заключения
Системный архитектор — это один из самых важных участников IT-инфраструктуры, отвечающий за большое количество технических процессов. Без его организационной работы зачастую не представляется возможным довести проект за конца.
Для этой работы вы должны уметь работать в рамках всех других должностей. Тяжёлые проекты позволяют быстрее построить свою карьеру, но зачастую излишне напряжённая работа приводит к выгоранию.
Если устали работать руками, «нажимая кнопки» и готовы взвалить на себя ответственность за себя и того парня, то это то, что вам нужно. Это работа неплохо нагружает «технический склад ума», а также позволяет проявить творческий подход к проекту, общаясь с профессионалами и большими начальниками, а то и мир спасая от какого-нибудь техно-краха. Если всё это вам близко и подходит, дерзайте. Проявляйте инициативу, развивайте кругозор и интересуйтесь «железом» во всех его проявлениях и смыслах. Ведь за вычислительными системами — весь современный мир и будущее!
«Вместо заключения» — Задачи и понимание должности системного архитектора отличается от компании к компании. Узнать, какие задачи выполняет архитектор в Timeweb и чем это отличается от CTO и тимлида можно в новом выпуске подкаста:
Как работают IT-архитекторы – наши примеры и задачи
Архитектор – незаменимый специалист при создании или аудите сложных IT-решений. Его задачи – заложить фундамент проекта, обеспечить гибкость и снизить риски, а в конечном итоге – обеспечить бизнесу быструю разработку и независимость в дальнейшем выборе подрядчиков.
Архитекторы особенно нужны в крупных IT-компаниях, которые ведут много проектов и для каждого выбирают оптимальный технологический стек, с учетом долгосрочной перспективы развития, плюсов и минусов каждого варианта.
Мы в SimbirSoft развиваем собственный архитектурный комитет – в нем уже 54 опытных разработчика. Делимся опытом, чем у нас занимаются архитекторы и на каких проектах они нужны.
Задачи IT-архитектора
Архитектура – это технологическая база IT-продукта. IT-архитектор, или системный архитектор – это, прежде всего, опытный разработчик. Он знает, когда полезно использовать определенную технологию, а самое главное – когда этого не нужно делать и какие есть риски.
Возможность адаптации продукта к новым требованиям бизнеса, даже если в начале процесса проектирования они не были известны в полном объеме.
Например, при создании коробочного решения для страховых компаний мы изначально заложили 4 основных вида полисов, при этом предусмотрели возможность быстро добавить и любые другие необходимые полисы.
Адаптация к ограничениям системы и соответствие техническим и операционным требованиям: по технологическому стеку, работе с персональными данными, Big Data, большим количеством интеграций.
Обеспечение при проработке архитектуры оптимальных значений атрибутов качества продукта.
Рассмотрим несколько ситуаций, в которых необходима проработка IT-архитектуры.
Когда нужен IT-архитектор
По мере развития продукта зачастую возникают новые требования, а старых решений уже не хватает.
Бывает и так, что небольшая инхаус-команда работает в рамках одного технологического стека, но для решения бизнес-задач предстоит интегрировать или разработать новую функциональность и при этом подобрать оптимальные технологии реализации. Для этого разработчикам может потребоваться помощь, поскольку сейчас технологии меняются каждые полгода, сложно быть одновременно в курсе всего и иметь экспертизу во всех языках и направлениях.
В таких ситуациях обычно обращаются к опытной команде архитекторов, которая «горит» своим делом, накопила разносторонний опыт и продолжает развивать компетенции в различных технологиях.
Как правило, бизнес заказывает разработку архитектуры в IT-компании в следующих случаях:
Как выбрать архитектуру
При выборе архитектурного решения учитывают множество факторов, в том числе ожидаемые сроки и стоимость разработки, поддержки, развития продукта. При этом нужно учитывать плюсы и минусы каждого варианта.
Коробочное или кастомное решение?
Кастомная разработка с нуля требует времени и тщательного планирования. «Коробки» – например, такие как «1С: Бухгалтерия» – подходят для компаний с простыми и стандартными бизнес-процессами, но их возможности развития ограничены. При необходимости дальнейшей кастомизации коробка может обойтись даже дороже, чем разработка с нуля, сразу заточенная под нужды компании.
Монолитная или микросервисная архитектура?
Риски: при увеличении функциональности приложения и количества активных пользователей монолит может перестать справляться с нагрузкой, и срок доставки новых фич будет долгим.
Риски: сложность разработки влечет за собой дополнительные требования к квалификации сотрудников. Для микросервисов наличие CI/CD – обязательное условие. Время на разработку будет выше, чем при работе с монолитом (при условии, что архитектурная структура монолита позволяет быстро вносить изменения).
Пример реализации
Один из наших клиентов-банков использовал коробочную систему дистанционного банковского обслуживания (ДБО). Добавить новые функции (и даже передвинуть кнопки) можно было только с помощью вендора. А значит, во-первых, релизы выходили редко (один раз в квартал), во-вторых, вся экспертиза была сосредоточена у вендора, а не в банке. Кроме того, из-за сложной балансировки клиентов монолитной архитектуры приложение работало со сбоями. Из-за этого банк обратился к нам для проработки нового решения.
Решением стала разработка новой микросервисной архитектуры ДБО, в которой каждый микросервис имеет отдельную базу данных, обеспечивая доступность приложения в любой момент. Результаты – в 5 раз меньше сбоев уже на старте, возможность выпускать несколько релизов каждую неделю. При этом сохранение экспертизы на своей стороне позволило банку дальше развивать продукт самостоятельно или с привлечением любого подрядчика.
Как работает архитектурный комитет
У разных IT-компаний свои способы работы с архитектурой. В небольших монопродуктовых командах у специалистов есть возможность напрямую посоветоваться с коллегами, опытными в тех или иных технологиях. А когда проектов много, появляется необходимость накапливать экспертизу, поскольку при переключении сотрудников с проекта на проект теряется ценный технический контекст. Выстраивая этот процесс, мы снижаем риск ошибок и неоптимальных решений.
У нас в разработке параллельно десятки проектов, и мы стремимся поддерживать внутреннее комьюнити экспертов и обмен опытом. Для этого мы создали архитектурный комитет – отдельную группу со своим руководителем.
Архитектурный комитет – это команда, в которую входят наиболее опытные разработчики Backend, Frontend, Mobile. Сейчас у нас 54 таких специалиста, их число постепенно растет.
Мы уже писали на Хабре, как мы разбираем входящие запросы и оцениваем сроки разработки. Расскажем, как в этом участвуют архитекторы.
Этапы работы
В ходе видеопрезентации заказчику архитектор рассказывает о результате своей работы, а заказчик в реальном времени задает все интересующие его вопросы.
Следуя описанной выше схеме работы, в каждом решении мы учитываем опыт, накопленный архитектурным комитетом при реализации предыдущих проектов.
Несколько участников архитектурного комитета SimbirSoft
Вывод
С помощью архитектурного комитета мы проработали уже более сотни проектов. По нашим наблюдениям, такой подход к архитектуре обеспечивает IT-компании и заказчику несколько важных преимуществ:
ИТ-архитектор. Как стать тем, на кого не учат?
Привет, Хабр! Меня зовут Сергей Терехин, и я — системный архитектор. Даже искушенные в ИТ люди не всегда знают специфику моей работы. Расскажу, как меня угораздило стать системным архитектором, чем занимаюсь, а также про прелести, боли и перспективы этой профессии.
Системный архитектор — это скорее роль, чем конкретная должность. Этой профессии не учит ни один вуз. А парадокс в том, что эти самые мифические системные архитекторы крайне востребованы и без их участия нормально не смог бы функционировать ни один крупный бизнес, базирующийся на ИТ.
Если вы считаете, что мир кровавого Enterprise загибается и однажды все корпоративное ИТ будет из облака, в вас поднимается волна возмущения и руки тянутся к помидорам, чтобы запустить в автора… Подождите. В реальности монстры российского бизнеса пока предпочитают строить свои ИТ иначе. И роль системного архитектора при таком подходе к инфраструктуре очень велика. Эти люди анализируют задачи, которые бизнес ставит перед ИТ, что именно нужно сделать и как лучше достичь поставленных целей. Они выбирают инструменты, оптимально подходящие в той или иной ситуации, придумывают архитектуру будущего вычислительного комплекса в целом, а иногда и каждого отдельного модуля в нем. И самое главное — системные архитекторы видят общую стратегию внедрения инфраструктуры и следят, чтобы все части выбранного решения укладывались в эту общую канву.
Так чем же они, то есть мы, по факту занимаемся?
Три вида архитекторов
Проще всего это понять, разобравшись, какие бывают архитекторы в ИТ.
Есть наиболее распространённое и понятное определение «архитектора решений» или «solution-архитектора» — это специалист, который понимает, как устроена и должна работать определенная прикладная система (веб-сервис, социальная сеть, ERP-система и пр). Он держит команды разработки в рамках техзадания и помогает создавать решения, фокусируясь на бизнес-задаче, а не просто на функциональных требованиях к исполняемому коду. Любое приложение должно на чем-то работать, а данные, которым оно оперирует, храниться долго и без потерь. Solution-архитектор может только сформулировать, какие ресурсы требуются и как быстро должен подниматься упавший сервис. Кто же сделает это реальностью?
Именно здесь подключается «системный архитектор». Он как раз гуру в создании ИТ-инфраструктуры, включая ЦОДы, железо, сети, различных системы хранения и серверные платформы. Его основная задача — подготовить инфраструктуру к тем требованиям, которые диктуют ей приложения. В сферу ответственности системного архитектора может входить множество систем, которые так или иначе относятся к инфраструктурному уровню, обеспечивая необходимую производительность, надежность и доступность. Но сути это не меняет — системный архитектор придумывает, как будет выглядеть ИТ-инфраструктура в целом и что она должна «уметь».
В идеале синергия системного и solution-архитекторов должна давать компании тот самый импульс для развития. В действительности между ними — бездна. Архитекторы решений не знают, как функционирует инфраструктура, а системные архитекторы часто не заинтересованы вникать в работу ПО. Именно поэтому над ними появляется «enterprise-архитектор» — супермен, способный соединить два сегмента архитектуры. Это не какой-нибудь отдельный «биологический» вид, а скорее новая эволюционная форма развития системного и solution-архитектора. Обычно он соединяет два берега над той самой бездной.
Мой личный опыт
Лично я начинал с простого инженера. Еще будучи студентом, работал эникейщиком, потом руководил маленьким отделом из трех человек в компании в Приморье. После перебрался в Питер и там впервые столкнулся с полноценной ИТ-инфраструктурой, став руководителем группы эксплуатации серверов и систем хранения. Через какое-то время меня притянула Москва. За несколько лет я стал руководителем дирекции ИТ-инфраструктуры, где кроме должности и нового масштаба задач мне вручили набор административных и, как я потом уже понял, архитекторских задач. Разбираться с этим приходилось на ходу, а многое просто брать и делать своими руками. Часто впервые.
По факту я уже тогда был системным архитектором, но без титула; выполнял определенные функции не для заказчиков, а для работодателя, конструируя системы виртуализации, проектируя доменные леса с нуля, перестраивая сети хранения в новую топологию. Оказавшись в компании «Инфосистемы Джет», я наконец-то официально стал носить гордое звание системного архитектора.
Футболисты и шахматисты
Наша компания ведет много крупных и сложных проектов, и поэтому у нас в штате я далеко не единственный системный архитектор. Оказывается, достичь этой позиции можно разными путями. Например, я — «футболист». Всю свою карьеру я «играл на поле»: бегал по ЦОДам, физически имел дело с оборудованием, знал его особенности, решал проблемы в реальном окружении. Но бывают прекрасные архитекторы «шахматисты». Они развиваются из глубоких теоретиков, которые изначально занимались только проектированием и не имеют богатого «полевого» опыта.
У каждого карьерного пути свои плюсы и минусы. Однажды я участвовал во встрече, где мои коллеги архитекторы готовили таблицу сравнения по двум системам резервного копирования. Мне это было странно, потому что, как практик, я прекрасно знал, насколько одно решение лучше другого. Да что там — на голову выше! Практика дает хорошую опору в принятии решений. В то же время, теоретики более беспристрастно оценивают все возможные опции, особенно когда все запутано и откровенно плохо. Так что разница между практиками и теоретиками не сказывается на качестве принятых решений.
В конечном счете сегодня я, как системный архитектор, отношусь как раз к теоретикам. После «полевой» работы ИТ-инфраструктуре средних размеров, я перешел в высшую лигу, но не «футбольную», а «шахматную». Какое-то время к этому пришлось привыкать: менять характер своего мышления и много работать с людьми.
Какие навыки нужны ИТ-архитектору?
Умение абстрагироваться
ИТ-архитекторы разрабатывают сложные решения под уникальные задачи бизнеса. На рынке нет типовых кейсов, которые можно использовать всегда и везде. Как в шахматах всего из 32 фигур может получиться 10 120 шахматных партий, так и одинаковый набор решений и продуктов можно объединить в различные ИТ-системы, иметь разную структуру и в итоге получить уникальный функционал. ИТ-архитектору важно развивать гибкость мышления, чтобы взглянуть на проект под другим углом, суметь разбить его на логические части и найти наиболее подходящее решение.
Архитектура ИТ решений. Часть 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 канале
Об авторских тренингах на тему: «Архитектура ИТ решений» подробнее можно узнать на сайте компании ООО ИЦ Таврида