2012-05-31: Заседание совета директоров по разработке - об архитектуре
Будучи на Atlantic Systems Guild, я и Игорь Беспальчук были приглашены в Клуб директоров по разработке, который собирает Microsoft. На первое заседание клуба, на котором речь шла о тестировании, мы не попали, а вчера было второй заседание. На нем шла речь об архитектуре. Вели заседание Сергей Орлик, который и начал рассказ, Евгений Злобин и Денис Пасечник.
Конечно, за два часа обсудить такой сложный и многогранный вопрос невозможно. Однако, участники клуба - профессионалы и практики, и их не слишком интересовали теоретические аспекты, поэтому обсуждение касалось обмена практическим опытом по решению задач построения архитектуры и, что более важно - описанию, поддержанию и сопровождению сложной архитектуры большого предприятия. Коснулись также вопроса поддержания архитектуры в разработке малых форм - небольших приложений, эксплуатируемых многими заказчиками, и сильно дорабатываемых для каждого.
Дальше - отдельные тезисы, которых касалось обсуждение.
- В архитектуре различают три уровня: Enterprise architecture, Software architecture и Infractructure architecture. Организация работы на этих уровнях идет сильно по-разному, но при этом необходимо обеспечивать гладкую сшивку между уровнями, в частности между Software и infrastructure и организовывать это при выполнении проектов. Infrastracture влияет на software, особенно, например, при размещении в облаке. И это необходимо учитывать и формализовывать, создавая SLA (service layer agreement).
- Важно работать с софтом на полном жизненном цикле, не ограничиваясь разработкой и внедрением, а рассматривая эксплуатацию и последующую замену. На современных предприятиях IT-ландшафт включает множество систем и одновременно идет несколько (иногда 10+) проектов изменения.
- На больших предприятиях и, особенно, в банках, в том или ином виде существует архитектурный комитет, или отдел архитектуры, или главный архитектор, который работают с архитектурой при осуществлении проектов. Типичный пример - enterprise архитектор, архитектор инфраструктуры и архитектор по безопасности. Архитекторы подчинены непосредственно CEO или CIO, то есть занимают высокую позицию и имеют большое влияние, но должность не управленческая, а техническая. С удивлением узнал, что Главный архитектор есть в ГПБ (кто - не сказали).
- В банках вообще распространена ситуация, когда о новых решениях конкурентов бизнес узнает от IT :)
- Востребованы схемы, отражающие все уровни архитектуры в комплексе и позволяющие визуально переходить между уровнями. В качестве возможного инструмента называли связку SharePpoint+Visio, при этом для отражения актуального состояния желательно, чтобы Visio-диаграммы получают данные из внешних источников, например, из баз данных, отражающих состояние серверов и используемых для мониторинга.
- Как способ представления упоминался Archimate (естественно, мной), но Орлик достаточно резко сказал что в нем очень сложная академичная модель. С моей точки зрения, это странно, потому как им же активно упоминался TOGAF - а он более академичен, а TheOpenGroup сейчас активно перекидывает между ними мостики. После заседания ко мне многие подходили, интересовались archimate.
- Востребована также трассировка между верхним уровнем архитектуры (enterprise architecture) и архитектурой приложений. VS (ultimate edition) сейчас включает много возможностей для работы с архитектурой приложения, но вот архитектуру IT-системы предприятия в целом на ней пока не опишешь, архитекторы верхнего уровня работают в системах типа Enterprise Architect, и хотелось бы иметь трассировку между ними, в том числе - чтобы при решении задач интеграции разработчики одного модуля могли легко найти и познакомиться с архитектурой другого в необходимых им аспектам. Готового решения тут нет, но как идея была предложена перегрузка из EA в VS данных, которые при этом становятся доступны для ссылок из уровня VS.
- С точки зрения управления отмечена хорошая интеграция между Project Server, обеспечивающим управление верхнего уровня, и TFS, используемой для управления на уровне команд. Правда сам TFS не без недостатков, например, при списывании времени на задачу, время разных участников суммируется и история в разрезе участников не ведется. А это важно - хотя у задачи правильно иметь одного основного исполнителя, время привлекаемых экспертов и других участников надо фиксировать и отделять. Но в принципе можно доработать - и Ситроникс это для себя сделал.
- В VS (правда многое в ultimate) есть много различных средств для архитектора. Часть из них обеспечивают восстановление из кода, например, диаграмм последовательностей, что позволяет проследить реализацию метода. Есть Layer-диаграммы, позволяющие описать структуру приложения и возможные обращения. Далее разные классы можно относить к конкретным уровням и при нарушении структуры разработчик получает предупреждение. Существуют также средства автоматического контроля при check-in в версию, описываемые через политику. И это не просто возможность - ряд компаний (Ситроникс, ГазЭнергоБанк, Лидер-Инвест) этим пользуются в своей разработке. Кроме того, на механизме DGML можно описывать собственные диаграммы, нагруженные определенным смыслом и реализовывать механизмы генерации или контроля, с этим связанные, layer-диаграммы - использование этого механизма.
В целом встреча была интересной и полезной, именно как обмен опыта между практиками.
Она безусловно перекликается с темой работы с архитектурой в нашей компании. Не в том смысле, что мы сейчас быстро и безусловно начнем внедрять упомянутые возможности VS и контролировать разработчиков. Но количество визуализированных на диаграммах способов реализации в наших проектах, на мой взгляд, недопустимо мало, слишком многое находится в головах разработчиков, что влечет трудности для их эффективного развития.
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.