Заседание Клуба директоров по разработке об архитектуре
30.05.2012 состоялось второе заседание Клуба директоров по разработке, посвященное архитектуре. Вели заседание Сергей Орлик, который и начал рассказ, Евгений Злобин и Денис Пасечник.
Конечно, за два часа обсудить такой сложный и многогранный вопрос невозможно. Однако участники клуба — профессионалы и практики, и их не слишком интересовали теоретические аспекты. Поэтому обсуждение касалось обмена практическим опытом по решению задач построения архитектуры и, что более важно — описанию, поддержанию и сопровождению сложной архитектуры большого предприятия. Коснулись также вопроса поддержания архитектуры в разработке «малых форм» — небольших приложений, которые эксплуатируются многими заказчиками и сильно дорабатываются для каждого.
Дальше — отдельные тезисы по темам, которых касалось обсуждение.
- В архитектуре различают три уровня: Enterprise architecture, Software architecture и Infractructure architecture. Организация работы на этих уровнях идет сильно по-разному, но при выполнении проектов необходимо обеспечивать гладкую сшивку между уровнями, в частности между Software и Infrastructure. Infrastructure влияет на Software (например, существенно влияет при размещении в облаке). И это необходимо учитывать и формализовывать, создавая SLA (service layer agreement).
- Важно работать с софтом на полном жизненном цикле, не ограничиваясь разработкой и внедрением, а рассматривая эксплуатацию и последующую замену. На современных предприятиях IT-ландшафт включает множество систем и одновременно идет несколько (иногда 10+) проектов изменения.
- На больших предприятиях, особенно в банках, в том или ином виде существует архитектурный комитет, или отдел архитектуры, или главный архитектор, которые работают с архитектурой при осуществлении проектов. Типичный пример — Enterprise архитектор, архитектор инфраструктуры и архитектор по безопасности. Архитекторы подчинены непосредственно CEO или CIO, то есть занимают высокую позицию и имеют большое влияние, но эта должность не управленческая, а техническая.
- В банках вообще распространена ситуация, когда о новых решениях конкурентов бизнес узнает от IT 🙂
- Востребованы схемы, отражающие все уровни архитектуры в комплексе и позволяющие визуально переходить между уровнями. В качестве возможного инструмента называли связку SharePpoint+Visio, при этом для отражения актуального состояния желательно, чтобы Visio-диаграммы получали данные из внешних источников, например, из баз данных, отражающих состояние серверов и используемых для мониторинга. Как способ представления упоминался Archimate, но была отмечена чрезмерная сложность заложенной в нем модели.
- Востребована также трассировка между верхним уровнем архитектуры (Enterprise architecture) и архитектурой приложений. VS (ultimate edition) сейчас включает много возможностей для работы с архитектурой приложения, но вот архитектуру IT-системы предприятия в целом на ней пока не опишешь. Архитекторы верхнего уровня работают в системах типа Enterprise Architect, и хотелось бы иметь трассировку между архитектурой в нем и архитектурой приложений в VS, в том числе для того, чтобы при решении задач интеграции разработчики одного модуля могли легко найти и познакомиться с архитектурой другого в необходимых им аспектам. Готового решения тут нет, но как идея была предложена перегрузка из EA в VS данных, которые при этом становятся доступны для ссылок из уровня VS.
- С точки зрения управления отмечена хорошая интеграция между Project Server, обеспечивающим управление верхнего уровня, и TFS, используемого для управления на уровне команд. Правда сам TFS не без недостатков. Например, при списывании времени на задачу, время разных участников суммируется и история в разрезе участников не ведется. А это важно: хотя правильно иметь одного основного исполнителя задачи, время привлекаемых экспертов и других участников также надо фиксировать и отделять. Но это, в принципе, можно доработать, что и делают.
- В VS (правда, некоторые есть только в версии ultimate) есть много различных средств для архитектора. Часть из них обеспечивает восстановление из кода (например, диаграмм последовательностей), что позволяет проследить реализацию метода. Есть Layer-диаграммы, позволяющие описать структуру приложения и возможные обращения. Разные классы можно относить к конкретным уровням, чтобы при нарушении структуры разработчик получал предупреждение. Существуют также средства автоматического контроля при check-in в версию, описываемые через политику. И это не просто возможность — ряд компаний этим пользуются в своей разработке. Кроме того, на механизме DGML можно описывать собственные диаграммы, нагруженные определенным смыслом, и реализовывать механизмы генерации или контроля, с этим связанные. Layer-диаграммы — использование этого механизма.
В целом встреча была интересной и полезной именно как обмен опытом между практиками. Надеюсь, такие встречи будут продолжаться.