Архитектура ИТ решений. Часть 1. Архитектура предприятия

I ВСТУПЛЕНИЕ

Архитектура распределяет массы и объемы. Вдохновение превращает инертный камень в драму. Ле Корбюзье.
Недавно столкнулся со следующей ситуацией, одна крупная ИТ компания подбирала для себя архитектора, с целью доработки компьютерной платформы. Такая работа, естественно, требовала привлечения специалиста высокой квалификации. То есть разработчика ПО поименовали именно архитектором, рассчитывая заполучить помимо кодировщика, еще и профессионала, способного разобраться с чужими решениями, до проектировать их, на свое усмотрение принимать самостоятельные решения и т.п… Когда стали выяснять, а как же в организации вообще обстоит дело с архитектурой, обозначились следующие тенденции. Есть ряд высококвалифицированных разработчиков, позиционируемых как архитекторы. Помимо непосредственно создания кода, они выполняют проектирование различных технологических систем и задают вектор и горизонт их развития. Решения представлены ими в основном в виде текстовых описаний, разбавленных небольшим количеством схем, в основном производных от диаграмм компонентов. Каждый из архитекторов представляется уникальным и эксклюзивным носителем знаний, а по сути — является узким местом в процессе производства программных продуктов. Ведь на практике без его постоянных уточняющих консультаций, воспользоваться результатом евонной деятельности практически невозможно. Полная, логически выстроенная, структурированная картинка сложного решения есть лишь в его голове. ...Далее...

Что нужно знать, чтобы стать системным архитектором

Роли в проекте выглядят так:
  1. Аналитик слышит от бизнеса задачу в духе «нам надо работать быстрее» и идёт выяснять, что для этого нужно. Долго ковыряется и узнаёт, например, что производству нужна более простая или прозрачная схема процесса обработки заказов. Обсуждает с командой. Бизнес решает делать. Аналитик бросает в архитектора требованиями к новой системе. Аналитик узнаёт, к чему надо идти.
  2. Архитектор смотрит на требования, смотрит на систему, удивляется, смотрит ещё раз туда-сюда — и после этого ставит точное техническое задание. Архитектор видит, что нужно делать.
  3. Проектировщик — самый счастливый человек. Он берёт требования архитектора и просто лабает их до уровня детального проекта системы. Проектировщик знает, как нужно делать конкретные детали.
  4. Проект-менеджер берёт проект и смотрит, сколько нужно людей, железа, денег и других ресурсов. Делает план работ. ПМ знает, кто будет делать, и сколько это будет стоить.
Потом в обратном порядке проект принимается. Ещё тут могут участвовать главные инженеры (в местах, где много железа или где требуются комплексные работы) и другие люди. Часто роли совмещаются — например, архитектор может быть как проектировщиком, так и брать на себя часть аналитики. ПМ может быть иногда тимлидом разработчиков. Но модель ролей примерно такая. Дальше — имхо про то, что нужно от первых трёх ролей. ...Далее...

«Хочешь быть системным архитектором? Там только свет и чистота…»



Много лет назад я от усталости облокотился на стену техкоридора и начал по ней медленно сползать. Мы только что сдали проект после пары недель ночных переработок, чтобы уложиться в дедлайн. Мимо шёл мой руководитель, я простонал:

— Рома, я задолбался быть инженером. Всё, ухожу!
Он ласково улыбнулся и сказал:
— Хорошо. Будешь системным архитектором. Там только свет и чистота. Выспись и приходи, расскажу, что будешь делать.

Я был молодым и наивным. Выспался и пришёл. Тогда начал постепенно становиться архитектором (сейчас стал), и могу смело сказать: света и чистоты тут столько же, сколько в буднях инженера. А вот ответственности больше. Поэтому — нет, не надо быть архитектором, если вы не понимаете, на что идёте.

Но! Если понимаете — это будет очень увлекательное приключение.
Читать дальше →

Как быть тимлидом — моя версия



Я был абсолютно двинутый на компьютерах и геймерствовал безбожно. В юности хотел пойти писать игрушки и даже некоторое время писал. Рос, рос, рос. Был в разное время разработчиком, тимлидом, проект-менеджером. Выяснилось, что в проекте надо не только кодить, но и предлагать какие-то решения сходу, обосновывать их, договариваться, быстро переключаться между разнородными задачами. Лично для меня это серьезная нагрузка на мозг. Перейти из режима «кодить» и «говорить ртом» — отнимает много сил.

Полтора года назад я пришел на проект портала облачной платформы Техносерв Cloud. Появилась возможность собрать новую команду и больше не переключать роли ПМ и разработчика.

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

Самое интересное — это собирать команду под себя на новый проект. Читать дальше →


Последние посты