Архитектура ИТ решений. Часть 2. Архитекторы

С предыдущей частью статьи можно ознакомиться, перейдя по ссылке

III ОПРЕДЕЛЕНИЕ ПОНЯТИЯ АРХИТЕКТОР

Врач может похоронить свою ошибку, архитектор – разве что обсадить стены плющом. Фрэнк Ллойд Райт.
Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это? Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня. Кстати существует профессиональный стандарт квалификационных требований системных архитекторов (5), на основании которых архитектору может быть присвоен один из шести квалификационных уровней. Будем использовать этот стандарт в ходе нашего рассмотрения темы, чтобы не упустить ничего важного в работе ИТ архитектора. ...Далее...

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

I ВСТУПЛЕНИЕ

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

[Перевод] Питер Хинченс: Психология архитектуры программного обеспечения

Один из принципов Социальной Архитектуры заключается в том, что способ нашей организации важнее того, кем мы являемся.
imageДиркжан Октман (Dirkjan Ochtman) обратил мое внимание на определение архитектуры программного обеспечения в Википедии: «совокупность структур, требуемых для понимания системы, которая объединяет элементы программного обеспечения, связи между ними и их принадлежность». Для меня эта бессодержательная и цикличная болтовня служит хорошим примером того, как унизительно мало мы знаем о том, что на самом деле важно при создании масштабной архитектуры программного обеспечения. Архитектура — это искусство и наука создания крупных искусственных структур, используемых человеком. Если я что и понял и успешно применял на протяжении тридцати лет при создании все более крупных систем программного обеспечения, так это то, что программное обеспечение — это все о людях. Крупные структуры сами по себе бессмысленны. Важно то, как они функционируют для использования их людьми. А в программном обеспечении, человеческое начинается с программистов, которые делают его. Основные проблемы в архитектуре программного обеспечения кроются в человеческой психологии, а не в технологиях. Наша психология по-разному может влиять на нашу работу. Я могу привести примеры того, как группа людей словно становится глупее по мере того, как она расширяется, или когда им приходится работать, будучи разделенными огромным расстоянием. Значит ли это, что чем меньше команда, тем она эффективней? Как же тогда такое крупное глобальное сообщество как ZeroMQ умудряется успешно работать? ...Далее...

[Перевод] Питера Хинченс: Психология архитектуры программного обеспечения

Один из принципов Социальной Архитектуры заключается в том, что способ нашей организации важнее того, кем мы являемся.
imageДиркжан Октман (Dirkjan Ochtman) обратил мое внимание на определение архитектуры программного обеспечения в Википедии: «совокупность структур, требуемых для понимания системы, которая объединяет элементы программного обеспечения, связи между ними и их принадлежность». Для меня эта бессодержательная и цикличная болтовня служит хорошим примером того, как унизительно мало мы знаем о том, что на самом деле важно при создании масштабной архитектуры программного обеспечения. Архитектура — это искусство и наука создания крупных искусственных структур, используемых человеком. Если я что и понял и успешно применял на протяжении тридцати лет при создании все более крупных систем программного обеспечения, так это то, что программное обеспечение — это все о людях. Крупные структуры сами по себе бессмысленны. Важно то, как они функционируют для использования их людьми. А в программном обеспечении, человеческое начинается с программистов, которые делают его. Основные проблемы в архитектуре программного обеспечения кроются в человеческой психологии, а не в технологиях. Наша психология по-разному может влиять на нашу работу. Я могу привести примеры того, как группа людей словно становится глупее по мере того, как она расширяется, или когда им приходится работать, будучи разделенными огромным расстоянием. Значит ли это, что чем меньше команда, тем она эффективней? Как же тогда такое крупное глобальное сообщество как ZeroMQ умудряется успешно работать? ...Далее...

СТО: мечты сбываются? И другие доклады для тимлидов с HighLoad++

Продолжаем обзор самых популярных докладов HighLoad++ 2017 по тематике тимлидерства. В этой части мы расскажем о выступлениях для уже состоявшихся руководителей — в первую очередь о движении из тимлида на более высокие посты. Ну и немного поговорим о психологии.


Читать дальше →

СТО: мечты сбываются? И другие лучшие доклады для тимлидов с HighLoad++

Продолжаем обзор самых популярных докладов HighLoad++ 2017 по тематике тимлидерства. В этой части мы расскажем о выступлениях для уже состоявшихся руководителей — в первую очередь о движении из тимлида на более высокие посты. Ну и немного поговорим о психологии.


Читать дальше →

[Перевод] Чему нас может научить теорема о четырех красках в разработке ПО

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

#Ускорение4X. Принцип № 0/3. Системное подчинение

Напомню, что мы изучаем практику #Ускорение4X.

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

Не знаю, как вы, а я наблюдаю за проектами изменений лет 10. Кроме наших любимых ИТ-проектов (которые ведь тоже — изменения), много приходилось и видеть, и делать самому обычных, организационных изменений.

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

Но еще важнее другой, побочный итог — мы убедились, что методика_такая-то — фуфло. Потому что не работает.

Так часто бывает, например, с внедрением принципов agile, или конкретно методики скрам. Так будет и с методикой #Ускорение4X, если действовать с той же ключевой ошибкой — главной ошибкой внедрения изменений в нашей стране.

Ошибка, увы, настолько банальна, что вы мне не поверите. Это не страшно, если не поверите, но если начнете наблюдать за внедрением изменений вокруг вас — в компании, в городе, в стране, то убедитесь, что дело именно в этом. Читать дальше →

Как начать создание Open Source проекта



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

  • Мой опыт создания Open Source проекта
  • Определение целей и планирование
  • Тонкости оформления
  • Мои ошибки

Полгода назад мне пришла идея создания своего open source проекта. Вместо тестовых задач на интервью мне было бы достаточно отправить ссылку на репозиторий, а перспектива помочь коллегам с решением их повседневных проблем еще больше зарядила меня энергией.
Читать дальше →

[Перевод] Как построить сообщество. Перевод книги «Социальная архитектура»: Миф об индивидуальном интеллекте

image Наверно, вы уже поняли, что я не сторонник одинокой гениальности. По большому счету это объясняется тем, что, несмотря на членство в организации Менса (крупнейшая, старейшая и самая известная организация для людей с высоким IQ), я помню, как совершал на удивление гениальные ошибки. Со временем я стал думать, что любое упоминание об индивидуальном интеллекте является опасно упрощенным мифом. В нем всегда гениальные личности думают над важными проблемами, и в результате упорного труда они генерируют решения и шлифуют их до совершенства. Иногда они переживают «эврика-моменты», когда им открываются гениально простые ответы на сложные проблемы. Изобретатель, его процесс изобретения, исключительное, драгоценное явление, и остальным лучше не вмешиваться. История полна героями-одиночками. Мы обязаны им нашим современным миром. Однако если присмотреться внимательнее, то станет понятно, что эта сказка не соответствует фактам. История не показывает одиноких изобретателей. Она рассказывает нам о везении людей, которые украли или присвоили себе право собственности на идеи, над которыми работали многие. Она полна примеров про гениальных людей, которые после удачного попадания тратят десятилетия на бесполезные и безрезультативные поиски. Самые известные крупные изобретатели вроде Томаса Эдисона были хороши в систематическом поиске, который выполнялся крупными командами. Это как заявить, что Стив Джобс изобрел каждую примочку, сделанную командой «Apple». Этот приятный миф годится для маркетинга, но он далек от истины. ...Далее...


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