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


12

Некоторые контексты:

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

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

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

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

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

  • Что не входит в сферу действия?

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

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

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

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

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

  0

Как я проиллюстрировал в моем ответе ниже, для организации такого размера нет такой команды, как команда _one_ architecture. Слишком много тем тоже. 24 сен. 082008-09-24 05:44:52

+2

Почти 5 лет спустя мне любопытно узнать, какой маршрут был выбран, и как это оказалось :) 05 апр. 132013-04-05 03:59:57

7

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

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

Мой друг, у вас есть жесткая дорога впереди ...

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

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

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


1

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

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

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

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

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

Я бы не привел новую группу со стороны. Это создало бы нежелательную динамику Us vs. Them, которая никогда не бывает хорошей. Посторонние также не имели бы представления о том, как должны работать вещи, или почему вещи не работают так, как логика подразумевает, что они должны. :)


0

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

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

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


1

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

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

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

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

  • Бизнеса и функциональная архитектуру команды: пишет много спецификаций, связанные с бизнесом, и проверяет соответствие между существующим приложением и функциональным рабочим процессом, чтобы завершить согласованную картографию приложения.
  • Команда «Архитектура приложения»: предоставляет картографию, а также определяет, как функциональные спецификации, определенные Группой бизнеса и функциональной архитектуры, будут организованы в приложения.
    Например, вам нужен функциональный модуль для «процесса портфеля», но команда Application Architecture может решить разбить его на «пусковую установку», «диспетчер», графический интерфейс и т. Д.
  • Техническая архитектура команды, всегда состоит из:
    • Execution архитектуры команды, для всех нерабочих-чисто технические темы (лесозаготовительных, КПЭ, рамки, ...)
    • Архитектура Развитие команды (оценка инструмента и поддержка, технологическое обследование, управление репозиториями для контроля версий и конфигурации)
    • OA (Операционная архитектура) для создания «исполняемого» объекта (то есть, зная правильные процессы, правильные серверы и правильные сети для развертывания ваших либо для омологации, либо для производства.)

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

И вы в порядке.

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

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

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

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

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

обозначает любой данный компонент фактически разработан три времени! ;)

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


0

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


2

Архитектуру трудно получить.

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

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

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

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


0

Вы должны работать через бизнес-сценариев А) и Б)

A) Что делать, если вы не установите его, то есть ничего не делать:
Оценки переделки при переходе затрат на техническое обслуживание

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

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

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

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

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

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


0

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

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

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

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

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

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

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

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

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

Они должны обладать высокотехническим персоналом в качестве своего менеджера.

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

Есть по крайней мере одна реальной цели (как консолидировать все сходства между проектами в одной библиотеку) каждый 1 год

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


0

Рассмотрите возможность чтения/покупки этой статьи из ACM: The Software Architect. Там есть несколько ссылок, и автор необычайно ясен в такой рассеянной теме. Он не будет отвечать на ваши вопросы напрямую, но в статье будет сосредоточена ваша стратегия.

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