IT–архитектура и IT–архитекторы

IT–архитектура это способ борьбы с возрастающей сложностью ИТ–решений. Когда программ много, когда они связаны друг с другом, когда они должны работать согласованно — тогда и возникает потребность в человеке, который бы это обеспечил.

В простых словах это можно объяснить так: Есть задача. Скажем, сварить борщ. Архитектор решает как и из чего этот борщ нужно сварить. Какие будем применять ингредиенты, как будем их обрабатывать, в какой последовательности.
Если дело в борще, то тут все более или менее понятно. (Число продуктов, которые обычно используются для приготовления борща, ограничено, хотя иногда есть и некие особенности и нюансы).
Если перед ним стоит задача приготовить суп, при этом работая с командой в 10 человек, то он должен уточнить, какими качествами должен обладать суп, выбрать продукты и способ обработки продуктов, построить план для поваров и их подмастерий с указанием что, когда и как делать. При этом он еще должен все это свести в единую картину. Ну, чтобы картошка сочеталась с мясом, лук с марковкой и т.д.
Работа это очень интересная только для самого архитектора. Для остальных это та еще скука.

С терминологией у нас в стране некие проблемы.
Иногда или даже чаще всего эту работу делает начальник IT–отдела или CTO, если по–западному.
Но если у нас проект более серьезный, эти функции чаще всего делятся на двух специалистов: собственно архитектор и “тим лид” (опять же в плане терминологии есть и другие варианты). Первый следит за технологией изготовления борща, обычно это самый опытный чел с большим опытом и определенным складом ума, он сводит картину в единое целое. Тим лид же следит за поварами. При этом следит даже за мелочами, как они режут марковку и т.д. Он ближе к менеджеру, хотя это не менеджер в чистом виде, так как с кодом он работает и очень даже много. Иногда может быть несколько архитекторов или несколько тимов.

Вообще острая необходимость в архитекторе возникает тогда, когда нам нужно не просто сварить борщ, а когда мы варим какой–то суп на протяжении длительного времени, и он постоянно меняется и подстраивается под вкусы его поедателей, т.е. клиентов. К примеру, если покупатели захотели сделать суп еще и с рыбкой, то изначально нужно было варить такой суп, который смог бы потом стать рыбным, а потом мясным без сильной потери во времени варки, т.е. архитектор задает некоторую гибкость, выбирая инструменты.

везде ли нужна IT–архитектура?
Многие компании обходятся и без нее. Мне довелось работать более чем в пятнадцати, и только в двух я видел людей, которые называли себя архитекторами.
Как правило, необходимым условием возникновения этой роли является сложность и разнородность используемых ИТ–решений.
Но иногда, даже в рамках достаточно сложного одного продукта уже может возникнуть потребность в том или ином виде выстраивать архитектуру программного решения: ERP–системы, (SAP, 1C), хранилища данных (Microstrategy, SAP BW), большие базы данных.
Поэтому на рынке встречаются предложения по работе, которые называются “Архитектор САП” или “Архитектор хранилищ данных”. На поверку они часто оказываются громкими названиями позиций проектных менеджеров, и вот почему.

Задачи, которые возникают в компании тесно связаны с так называемой бизнес–архитектурой. Другими словами, нужно понимать, зачем тебе это и что тебе это даст. Если ты понимаешь, что копия сайта решает какую–то бизнес–задачу и не противоречит нормам, законам и правилам, то это вполне рабочий вариант. Например, компоненты с открытым кодом, взятые из интернета, сейчас входят в жизнь больших компаний как прагматичное решение. В Bosch, например, еще в конце 90–х это бы сочли ересью, примерно как двигатель от запорожца пихать в мерседес. А сейчас это рассматривается в большинстве компаний как вполне рабочий и экономически целесообразный вариант. И никто не называет это двигателем от запорожца.

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

Если область разработки небольшая (например, самописная система ERP — это довольно небольшая область), то у руководства компании возникает естественное желание объединить роли и назначить одного человека, который бы отвечал и за то, что надо реализовывать (архитектор), и как это делать (процесс проектного управления).

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

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

 

Ха! Проектное управление! Зачем это? Мы делаем проекты, и все получается! — скажете вы.

И будете частично правы. Бывают ситуации, когда проектное управление — излишняя трата времени и сил.

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

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

Поэтому по моему опыту правильней использовать проектное управление, оно позволяет расставить контрольные точки и вести параллельно одной командой более 50 разработок, не боясь, что упустишь что–то из виду.

 

Нужен ли ITIL в российской компании?

ITIL в любой относительно крупной компании нужен. Вопрос — в каком объеме. Взять тот же сервис деск. Если есть приложения, нужно выстраивать обработку обращений/инцидентов, нужно понимать, как подходить к решению проблем (повторяющихся обращений). Нужно определять как сохранять и управлять знаниями, когда их много и в одной голове не помещаются. И как только ты это сделаешь, сможешь сказать — офигеть, у меня же тут ITIL! Любая методология — неважно в какой области, проектного управления или стандартизации ИТ, требует подстройки под те условия, в которой она будет использована. А так в большинстве случаев, даже если ты не знал ничего про него, оглядываясь назад, сможешь сказать — смотри, у нас там был ITIL!

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