Метка: Release management

Стратегия развития корпоративных информационных систем (2)

strategyТема Стратегия развития корпоративных информационных систем вызвала довольно много откликов на FB, поэтому еще несколько соображений относительно pace layer model. Первое относится к тому, могут ли приложения переезжать из одного слоя в другой.  На этот вопрос дается четкий ответ в работе How to Differentiate Governance and Change Management in Your Pace-Layered Application Strategy (19 September 2012 ID:G00237513). Организации должны регулярно пересматривать свой портфель приложений и при необходимости корректировать классификацию той или иной системы. Продолжить чтение «Стратегия развития корпоративных информационных систем (2)»

Стратегия развития корпоративных информационных систем

paraЗабавные вещи пишут ребята из Gartner относительно стратегии развития приложений. Называется это pace layer model. Если говорить в двух словах, то смысл модели следующий. Организации необходимо иметь три типа бизнес-приложений: system of records, system of differentiation, system of innovation. На мой взгляд, названия не очень удачные. Но дело, разумеется, не в словах, а в подходе, который стоит за этими названиями. Продолжить чтение «Стратегия развития корпоративных информационных систем»

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

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

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

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

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

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