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

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

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

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

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

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

Custdev в разработке продуктов для видеонаблюдения

Практически все компании, которые занимаются разработкой модулей видеоанализа делают это, исходя из экстраполяции собственной инженерной мысли. Компания думает: «Мы сможем разработать функцию, которая, например, будет обнаруживать оставленные предметы, или детектировать огонь, или считать людей на кассах магазинов и т.п.». И делает это. Решение о том, какой модуль создать принимается в большинстве случаев исходя из возможностей разработчиков и ресурсов компании. В результате часто модули, которые получаются, становятся своего рода техническими экспериментами. И когда их покупают заказчики, внедряют в действующие системы видеонаблюдения и начинают применять на практике, оказывается, что реальной пользы они не несут.

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

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

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


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

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

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


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

Как убить технаря в тимлиде

В IT линейных руководителей и тимлидов традиционно набирают из лучших инженеров. Их работа теперь состоит совсем в другом: управлять людьми и взаимодействовать с другими командами и организациями. Исходный же посыл «я лучше знаю, как нужно» часто приводит к совмещению в одном лидере одновременно двух крайностей: отсутствия делегирования и тотального контроля. И то, и другое вовсе не оставляет ни времени, ни сил на управление. О том, как со всем этим справиться и какие еще препятствия могут встретиться на пути новоиспеченного руководителя, на основе собственного опыта и собственноручно набитых шишек расскажет Александр Трофимов из Лаборатории Касперского.


В основе публикации — расшифровка доклада Александра Трофимова с HighLoad++ 2017
Читать дальше →

TeamLead — наше все: самые популярные доклады с HighLoad++ 2017. Часть 1

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

Для этого обзора мы выбрали восемь наиболее популярных выступлений.



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

#Ускорение4X. Принцип № 0/1. Изменяемая среда

Итак, мы хотим ускорить разработку в 4 раза. Нет, мы не хотим, мы уже ускорили. Вы хотите.
Серебряной пули, ускоряющей в 4 раза, нет. Есть целая обойма пуль разного калибра, типа, убойной силы и применимости в конкретной ситуации.

Я просто расскажу вам, как это делали мы. Какие нашли решения, фишки, подходы, философию. Нужно это вам или нет – решайте сами. Мы не навязываем. Просто нас задолбали с вопросами по почте и на конференциях, поэтому решили рассказать централизованно, в самом подходящем для этого месте — Хабре. Тут же разработчики опытом обмениваются? Все спрашивающим будем ссылки давать.

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

Если согласны – под кат. Читать дальше →

Гибкий суррогат

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

Сегодня посмотрим на не так сильно распространенный, но более близкий к нам, программистам и разным ИТшникам, пример.

Конкретно вам НЕ стоит читать дальше, если вы МОЖЕТЕ в течение 5 минут ответить на вопрос: насколько изменилась скорость, или эффективность вашей работы за последние полгода?

Если вы ответили на этот вопрос цифрой, и цифра эта не равна нулю, то публикация не для вас.

Для 1Сников вместо нуля может быть Неопределено, для js'ников — undefined. Читать дальше →

Почему Agile не работает и что с этим делать

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

Читать дальше →
  • Новее
  • 1


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