Релизы и версии

Как и во многих крупных компаниях, наш корпоративный ИТ ландшафт состоит из информационных систем, таких как система управления отношениями с клиентами (CRM), система самообслуживания, биллинговая система и т.д. Всего их в CMDB насчитывается несколько сотен. Каждая система включает в себя несколько программных компонент. Это и базы данных и JEE приложения, толстые клиенты и web-интерфейсы. До пришествия виртуализации каждая система развертывались на своем наборе оборудования. Впрочем, и сейчас основные системы развернуты на закупленных специально для них серверах.

Не удивительно, что ИТ система является основным элементом управления. К ИТ системам привязываются запросы на изменения (Request for Change, RFC). Системы являются основной единицей процесса управления релизами. Т.е. для каждой системы развивается своя ветка релизов. Все планирование, разработка, тестирование и развертывание ведется в границах систем. Версии приложений попросту совпадают с релизами. Мы не уникальны. Многие компании развивают свою ИТ-инфраструктуру примерно так же. Но в какой-то момент это становится проблемой. Сначала проблемой ИТ архитектуры, а вскоре и проблемой всего ИТ.

На днях листая перед сном ITIL я пытался найти ответ на вопрос почему релиз может включать в себя только одну ИТ систему. Честно говоря, в явном виде такой рекомендации я не нашел. В чем недостатки привязки релиза к одной конкретной ИТ системе? Все очень просто. Традиционный цикл выпуска программного обеспечения ограничивается фазами анализ->проектирование->разработка->тестирование->развертывание. Однако в большинстве современных компаний изменения в ИТ носят комплексный характер, затрагивают сразу несколько систем (см. примечание). Такие работы, как согласование интерфейсов, интеграционное тестирование, конфигурирование приложения (это когда вместо абстрактных интерфейсов, администраторы прописывают реальные ip-адреса web-сервисов и connection strings баз данных), пользовательское тестирование (UAT), разработка архитектуры, в конечном счете =) и управления конфигурациями – остаются за бортом процесса.

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

Примечание: Опрос Как интегрируют приложения в России, приведенный в блоге Андрея Коптелова, показывает что всего треть отечественных компаний никак не интегрируют свои приложения. Остальные – тем или иным способом решают задачу интеграции приложений

Заказная разработка vs. коробочные решения

Большую часть прошлой недели я провел, обсуждая с коллегами стратегию развития информационных систем нашей компании. И естественно тема: «Что лучше? Заказная разработка или коробочные решения» тоже возникла. Эта тема не сходит с первых полос ИТшных форумов уже минимум лет пятнадцать. Правда состоит в том, что в любой более-менее крупной компании будет и то и другое. Я не стану приводить доводы в пользу того или иного решения. Порассуждать я хочу совсем о другом, а именно о том, как эксплуатировать те и другие решения.

Эталоном процессов эксплуатации промышленных решений является ИТ-сервис менеджмент (ITSM). Helpdesk-и, отстроенная система управления инцидентами и дефектами и т.д. и т.п. Однако, для заказной разработки весь этот айтил-майтил, не то чтобы совсем не подходит,… просто не эффективен. Причины следующие:

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

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

Ну и третий аргумент заключается в том, что ИТ-индустрия семимильными шагами движется от массового производства компакт дисков(ну а как еще назвать программное обеспечение, продаваемое в каждом втором ларьке) к software-as-a-service (SaaS), т.е. продукту не тиражируемому в миллионах экземпляров, а уникальному, развернутому централизованно и потребляемому из сети. Смысл архаичного и мега-бюрократического подхода к эксплуатации такого решения просто теряется

Еще несколько слов про CHG

Перечитал своё вчерашнее сообщение. Наверное, не очень понятно, почему я пишу о JIRA в контексте управления изменениями (change management). Всё очень просто: у кого чего болит… У меня сейчас болит это самое управление изменениями.

Читать далее Еще несколько слов про CHG