Создание отдела архитектуры

Question

Некоторый контекст заранее:

Представьте, что более 200 разработчиков разработали наконец более или менее независимую команду / отдел по архитектуре. За портфелем программного обеспечения, состоящим из 20+ «проектов» / приложений различных размеров в производстве, позаботились руководители групп / технические руководители, которые также отвечали и отвечали за «архитектуру» проектов.

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

• Каковы DO с и НЕ с такого предприятия?

• Кто такие люди, которые составляют такую ​​архитектурную команду?

• Какими должны быть их обязанности?

• Что выходит за их рамки?

• Каковы полезные стратегии перехода для компании?

• Как не допустить этих искаженных взглядов каждый раз, когда кто-то даже упоминает «команду архитекторов»?

• Ваша компания уже успешно прошла такое изменение?
  Почему это не удалось?
  Почему это было успешно?

Это должно не быть дискуссией на тему «Что такое architecutre?» (Которая очень тесно связана;).

Действительно интересные моменты были бы приемлемыми / реалистичными, может быть, даже беспроблемными способами создать такую ​​команду, кроме того, конечно, некоторые предупреждения относительно сражений лучше не начинать.

Answer 1

Вот несколько вопросов, о которых следует подумать:

• Каков точный мандат для команды архитекторов?
• Каковы результаты работы команды архитекторов? Рамки, рекомендации, помощь в реализации ... Или они просто Архитектура Астронавтов ?
• Это только для приложений, идущих вперед, или это будет обратный порт?
• Кто будет отвечать за бэкпорт? (И мы имеем в виду бюджет здесь ...)
• Будут ли выделены ресурсы для тестирования бэкпортов?
• Обладает ли реальная сила у команды архитекторов, или менеджмент потерпит неудачу, когда первая группа начнет ворчать примерно за 4 месяца, которые потребуются для реализации изменений ...
• Как вы будете справляться с трениями между отдельными проектными группами и командой управления (и будут ли трения?). Оппортунисты воспримут это как прекрасную возможность для жокея на позиции ...
• Имейте в виду, что это будет в первую очередь политическая игра ...

Мой друг, у тебя впереди тяжелая дорога ...

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

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

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

Answer 2

Архитектура трудно понять правильно.

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

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

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

Я думаю, что на другие вопросы, которые вы задаете о сфере действия / обязанностях / переходе, ответили "это зависит". Это зависит от компании, людей, денег и графика.

Answer 3

«Архитектура» в этом контексте сама по себе ничего не значит. Это означает «эксперты по сквозным темам».

Всякий раз, когда у вас есть «Архитектурная команда», у вас будет сквозная команда, которая будет предоставлять услуги для многих проектов.

Как указывалось в предыдущих ответах, вам необходимо знать, к каким темам будет обращаться такой "отдел архитектуры".

Теперь вот пример организации архитектурных команд, основанный на нескольких темах:

• Команда по бизнес и функциональной архитектуре: пишет множество спецификаций, связанных с бизнесом, и проверяет соответствие между существующим приложением и функциональным рабочим процессом, чтобы составить целостную картографию приложения.
• Группа прикладной архитектуры: предоставляет картографию, а также решает, как функциональные спецификации, определенные Группой бизнес-функциональной архитектуры, будут организованы в приложения.
  Например, вам нужен функциональный модуль для «процесса портфеля», но группа по архитектуре приложений может решить разделить его на «модуль запуска», «диспетчер», графический интерфейс и т. Д.
• Группы технической архитектуры, всегда состоящие из:
  • Команда по архитектуре исполнения, для всех не связанных с бизнесом чисто технических тем (ведение журналов, KPI, платформы, ...)
  • Команда разработчиков архитектуры (оценка и поддержка инструментов, технологическое обследование, управление хранилищами для контроля версий и конфигурации)
  • OA (Операционная архитектура) для того, чтобы сделать среду "исполняемой" (то есть, зная правильные процессы, правильные серверы и подходящие сети для развертывания вашей системы как для омологации, так и для производства).

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

И тебе пора.

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

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

Любая переделка в магазине такого размера на самом деле означает, что он действительно может внести необходимые изменения в унаследованные проекты , ожидая, пока переделки дадут первые выпуски. (Наследие не может просто ждать и оставаться на месте в течение 2-3 лет переделок)

Большая переделка должна включать три основных этапа:

• 1 / диалог с наследием
• 2 / завершить наследство
• 3 / заменить наследие

То есть любой данный компонент разрабатывается трижды! ;)

Удачи и спокойной ночи.

Answer 4

Интересный вопрос.

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

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

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

После этого я бы взял несколько потенциальных клиентов и продвинул их (засыпал потенциальных клиентов из пула разработчиков) команде разработчиков архитектуры. Затем они встретятся с руководителями, чтобы убедиться, что все идет по «большой картине».

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

Answer 5

Подумайте о том, чтобы прочитать / купить эту статью в ACM: Архитектор программного обеспечения . Там есть несколько ссылок, и автор необычайно ясен в такой распространенной теме. Он не будет отвечать на ваши вопросы напрямую, но статья будет фокусироваться на вашей стратегии.

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

Answer 6

Только архитектура может превратить людей в астронавтов / зомби. Так что им определенно нужно иметь какое-то кодирование, даже если это базовое прототипирование. На самом деле успех их прототипов должен быть определенным фактором обзора.

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

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

Им должно быть предоставлено время для освоения новых инструментов / проектов / обязанностей в существующих проектах, если они захотят.

Они должны были бы по крайней мере сделать 3-4 проверки кода критических модулей и выработать рекомендации по стилю кода.

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

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

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

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

У них должен быть высококвалифицированный человек в качестве менеджера.

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

Иметь хотя бы одну реальную цель (например, объединять все общие черты между проектами в одну библиотеку) каждые 1 год

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

Answer 7

Вам необходимо проработать бизнес-сценарии A) и B)

А) Что если вы не настроите его, то есть ничего не делать:
Смета переделок по текущим затратам на техническое обслуживание

B) Затем вы настраиваете:
Нарушение срочных результатов из-за отвлечения ресурсов.
Риск, связанный с несколькими продуктами, может быть устранен в краткосрочной перспективе.
Затраты на воспринимаемую дополнительную рабочую силу.
Кто отметит, если продукты ослаблены упражнением (производительность или предполагаемая негибкость)

Затем приведите команды разработчиков к тому же упражнению, сравните результаты.

Если вы оправдываете это, вот два пути, которые я видел :
1. Выберите ведущий продукт для управления архитектурой и добавьте ресурсы в этот проект.
Тогда будьте готовы добавить больше ресурсов и будьте терпеливы, иначе пострадает свинцовый продукт.
Вы рискуете разделить этот маршрут, он сработал, когда основной продукт приносил 40% дохода.
2. Создайте небольшую команду, основанную на самых многообещающих дискуссиях, происходящих внутри компании, постепенно добавляйте новую архитектуру в каждый продукт.
Переплетите эту команду, работайте над работой над продуктами.

Некоторые вопросы для вас, чтобы посмотреть :
1. Как скоро вам нужно достичь конвергенции архитектуры, чтобы получить выгоду для бизнеса.
2. Кто из членов команды уже говорит о конвергенции архитектуры, и спрашивают ли они / предлагают ли они ее важность, этот вопрос нужно задать на «задний план» для 80% отказов вашей команды.

Чего не делать
* Нанимайте экспертов извне (если вы сейчас не в полном беспорядке)
* Откажитесь через несколько месяцев, это длительный срок.
* Изменить все проекты сразу.
* Начинайте до тех пор, пока у вас не появится ядро ​​из трех, чтобы это могло произойти.
* Пусть отдел архитектуры станет больше, чем должен быть
* Пусть это будет воспринято, как архитектурный отдел решит проблемы продуктовых команд
* Пусть любой продукт «ожидает новой архитектуры»
* Позвольте архитектурному отделу "определить все" или имейте ползучесть
* Заставить все продукты в архитектуре, некоторые могут не соответствовать (например, не разработаны в той же стране)

Что делать:
* Вооружен хорошим обоснованием от первый вопрос получить высшее руководство купить и просить продукт команды сообщают о прогрессе
* Вносить пошаговые изменения в соответствие продукта с архитектурой карта
* Работа по согласованию наиболее перспективных или мало рискованных продуктовых линеек первый
* Настройка метрик, чтобы вы могли продемонстрировать добавленную стоимость (см. оправдание из первого набора вопросы)
* Иметь дорожную карту для всех продуктов, чтобы сходиться или нет.
* Подумайте, что обеспечивает основная архитектура и кто ее поддерживает Артефакты
* Позвольте продуктовым командам внести свой вклад в ядро ​​с точки зрения спецификации, код и обслуживание ядра
* Учебный курс по настройке использования команды архитекторов для новые стартеры и существующие команды

Answer 8

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

Answer 9

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

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

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