Адаптивность — залог выживания ИТ-инфраструктуры
Идея адаптивности ИТ-инфраструктуры лежит вне мира ИТ, и более того, вне мира технологий. Адаптивность — фундаментальный принцип эволюции. На ее знамени - слова Чарльза Дарвина: «Выживает не самый сильный из видов, не самый разумный, а тот, который быстрее других приспосабливается к изменениям». По сути речь идет о появлении нового критерия оценки ИТ. Сегодня недостаточно обеспечить требуемую эффективность и качество предоставляемых ИТ-услуг, приемлемые цену и стоимость владения, надежность функционирования. Необходимо гарантировать работоспособность системы при возникновении изменений. Будь то изменения в организации бизнеса или законодательства, рост/падение курса доллара или цены на нефть, переход на новую ERP-систему и т.д. Причины этих изменений различны по своей природе, но зачастую находятся вне области контроля со стороны ИТ. Критерий оценки ИТ
Допустим, ИТ-менеджер кропотливо изучает особенности организации бизнес-процессов, требования к информационной поддержке, используемые приложения, планируемый рост нагрузки, допустимое время простоя. Учитывает планы производителей аппаратуры и программного обеспечения, отправляет своих специалистов на курсы, внедряет совершенную систему защиты, системы резервного копирования и мониторинга. В результате героических усилий создается работающая, как часы, ИТ-инфраструктура. Но совет директоров принимает решение о повсеместном распространении опыта работы информационной системы, используемой в филиале компании в удаленном от центра городе, где объем бизнеса вырос в 2,3 раза. Аудит настоятельно рекомендует перейти на систему электронных расчетов с поставщиками. А судьба важнейшего для будущего компании тендера зависит от того, сможет ли ИТ-департамент к завтрашнему дню предоставить системе (аналитической, производственной, финансовой, почтовой) 10 ТБ дискового пространства и вычислительную мощность в 120,000 QphH. К плюсам такого поворота событий можно отнести то, что компания достигла уровня зрелости, на котором централизованное управление изменениями инфраструктуры становится одной важнейших задач ИТ. Но перепроектирование системы может оказаться болезненным и недешевым. Прежде всего, потому, что на новом уровне появляется общий пул централизованно управляемых корпоративных информационных ресурсов для разнородных по своей природе задач. А из разрозненных специализированных ресурсов этот пул создать невозможно. Стратегии отношения к изменениям Чтобы избежать неприятных неожиданностей в рамках стратегии развития компании следует предусмотреть то или иное отношение бизнеса к возможным изменениям. Формальный параметр, характеризующий это отношение, называется адаптивностью бизнеса и характеризует возможность приспосабливания к изменениям для получения преимуществ в бизнесе. При различных стратегиях отношения к изменениям меняются и основные задачи ИТ. Во-первых, реагирование на изменения - перестройка бизнеса в результате уже произошедших событий. Для бизнеса, предусматривающего лишь реагирование на изменения, главными задачами ИТ являются обеспечение непрерывности бизнеса и его безопасности. Во-вторых, и это более высокий уровень, предвидение изменений, то есть анализ тенденций и подготовка бизнеса к наиболее вероятным событиям. Продолжением второго типа являются проактивные изменения, то есть проведение упреждающих преобразований, направленных на эффективное функционирование бизнеса в условиях наиболее вероятных изменений. Очевидно, что каждой степени адаптивности бизнеса соответствует своя ИТ-инфраструктура, фокусирующаяся на разных задачах. Основные задачи ИТ при различных стратегиях отношения к изменениям
На высшем уровне зрелости главными задачами ИТ являются: виртуализация, то есть разделение логического и физического уровней предоставления ресурсов; динамическое выделение ресурсов «по требованию», переход от управления ресурсами к управлению услугами; повсеместное использование соглашений об уровне сервиса SLA (Service Level Agreement). Каждый более высокий уровень зрелости ИТ-инфраструктуры ни в коем случае не отменяет задач, которые решались на уровне предыдущем. Это значит, что обеспечение непрерывности бизнеса и его безопасности останутся в числе важнейших задач на любом уровне зрелости. Стоит помнить, что выбор степени адаптивности бизнеса — это не только декларация намерений и стратегии развития. Это ещё и бюджет на ИТ. Адаптивная организация бизнеса Адаптивную ИТ-инфраструктуру нельзя построить без адаптивной организации бизнеса. Идеальная модель такой организации бизнеса позволяет представить «как всё должно быть», хотя, конечно, в реальной жизни никогда не удаётся отвлечься от особенностей исторически унаследованных систем, от постоянно присутствующих ограничений бюджета, от квалификации и личных предпочтений персонала, от срочных сиюминутных задач и т.д. В основе модели — стратегия развития бизнеса, определяющая направления деятельности, видение рынка, цели и задачи компании. Способы реализации намеченных целей устанавливаются бизнес-процессами, содержащими роли, зоны ответственности подразделений и сотрудников компании, процедуры взаимодействия, требования к обеспечению бизнеса, в том числе и информационному. Основу информационного обеспечения составляют прикладные системы, а необходимые для их функционирования ресурсы предоставляет ИТ-инфраструктура. И, наконец, имеется единая система управления, охватывающая бизнес-процессы, прикладные системы и ИТ-инфраструктуру. Модель адаптивной организации бизнеса
Адаптивность функционирования модели достигается, если все компоненты модели согласованы между собой, т.е. выработаны и строго соблюдаются правила взаимодействия компонент, отвечающие стратегии развития бизнеса компании. Кроме того должна присутствовать возможность гибкой (эффективной, оперативной, непрерывной) реорганизации процессов (функций, ресурсов), реализующих внутреннюю структуру каждого компонента при условии соблюдения установленных правил взаимодействия с другими компонентами. Стоит все же оговориться, что никакая инфраструктура не способна абсолютно защитить бизнес от несовершенства законодательной базы, неэффективного управления, ошибок в оценке состояния и потребностей рынка, человеческого фактора и многого, многого другого. Постановка задачи Реализация адаптивной ИТ-инфраструктуры начинается с формулировки критерия адаптивности. Как определить и измерить изменения? Как соотнести дополнительные затраты на инфраструктуру с возможными потерями бизнеса, ориентированного на работу в стабильных условиях? Критерии адаптивности
В качестве верхней границы значений можно принять масштаб изменений, при котором требуется полная замена ИТ. Время построения и стоимость новой системы соответствуют значениям двух других критериев. Если специфика организации бизнеса компании такова, что эти значения являются допустимыми для бизнеса — можно смело забыть про адаптивность. В противном случае целесообразно сформировать список потенциальных изменений, которые следует принимать во внимание. Например, недоступность площадки основного центра, открытие филиалов-отделений, внедрение нового приложения, пиковые нагрузки в конце квартала, случайное или преднамеренное уничтожение данных и т.д. Крайне важно, чтобы этот список составляли руководители бизнес-подразделений и топ-менеджеры. Затем необходимо оценить время, масштаб и простоту изменений ИТ-инфраструктуры при различных вариантах реализации и бюджетах. Соответствующая таблица (пояснительная записка) с полученными данными способна языком цифр и фактов объяснить далеким от ИТ менеджерам, за какую адаптивность нужно поделиться частью прибыли. Подходы и методы проектирования Для проектирования адаптивной инфраструктуры используется несколько подходов, важнейшими из которых являются SOA (Service-Oriented Architecture — сервис ориентированная архитектура) и MDA (Model-Driven Architecture - управляемая моделями архитектура). Оба этих подхода широко обсуждаются в мире ИТ в самых различных аспектах - от автоматизации бизнес-процессов до проектирования программного обеспечения или аппаратуры. SOA предполагает что взаимодействие бизнеса и ИТ описывается посредством сервисов, каждый из которых представлен на всех уровнях: бизнеса, приложений и инфраструктуры. Кроме того, каждый сервис рассматривается с различных позиций (способов представления): внешнего или в качестве объекта управления. Главное чего позволяет добиться SOA — это обеспечить независимость реализации сервиса на разных уровнях. Любую ИТ-задачу можно представить в соответствие с SOA. Например, задачу построения корпоративной электронной почты и попробуем определить содержание полей таблицы. На уровне бизнеса производственными подразделениями формулируется внешнее представление сервиса. Например, для работы с почтой определяются компьютеры, с которых возможен доступ (рабочий десктоп и ноутбук в командировках), доступность почтового ящика в течение суток, спам-фильтр и т.д. С точки зрения сервиса на уровне бизнеса определяется, кто санкционирует подключение сотрудника к почте и его отключение, количество пользователей, ограничения на размер почтового ящика, правила формирования почтовых адресов, внутренние списки рассылки и пр. Кроме того, полезно продумать и согласовать варианты развития системы (например, централизованный архив, доступ через мобильную связь). На уровне приложений внешнее представление сервиса определяется серверным и клиентским почтовым программным обеспечением. Сервис как объект управления представляет собой программное обеспечение резервного копирования, обеспечения безопасности, СУБД, инструментальные средства контроля версий, средства администрирования, help-desk и пр. Внешнее представление сервиса на уровне инфраструктуры - результаты расчета требуемых параметров платформы, серверные ресурсы, ОС, ресурсы систем хранения, коммуникационные ресурсы, технологии обеспечения высокой доступности (кластерные архитектуры) и пр. Сервис как объект управления - комплекс подсистем управления инфраструктурой (локальной сетью, серверами, системами хранения, сетью хранения и пр.), технологии балансировки загрузки, виртуализация и пр. Управляемая моделями архитектура (MDA) была предложена группой OMG (Object Management Group) в 2000 году и изначально использовалась главным образом при разработке программных продуктов. Суть подхода состоит в описании сложных систем в виде набора моделей, каждая из которых разрабатывается в терминах, параметрах и концепции, установленных для данного уровня представления системы, и может трансформироваться в модели другого (как правило, нижнего) уровня, чем собственно и обеспечивается непрерывность представления системы в целом. Цели SOA и MDA полностью идентичны: структурировать описание взаимодействия бизнеса и ИТ таким образом, чтобы разделить представление отдельных компонент структуры на различных уровнях абстракции (например, логическое и физическое представления или представление пользователя и разработчика и пр.). Кроме того, чтобы можно было определить взаимодействие компонент различных уровней с помощью формальных интерфейсов или положений SLA (Service Level Agreement). При всем этом способ реализации той или иной компоненты системы должен оставаться незаметным для пользователей других уровней. Применение MDA к описанию взаимодействия бизнеса и ИТ представляет собой комбинацию перечисленных выше правил, понятия сервиса (как важнейшего для ИТ) и уровней представления системы из модели адаптивной организации бизнеса. Преследуя одни и те же цели, подходы SOA и MDA используют различные методы классификации отношений бизнеса и ИТ. Для MDA эта классификация выполняется с позиций логики сервиса, интерфейсов, данных и ресурсов. Использовать ли одновременно оба подхода или только один, по сути, не столь уж важно. Важно, в конце концов, получить структурированное описание взаимодействия бизнеса и ИТ. Если это произошло, значит, предварительная работа закончена и можно перейти к непосредственному проектированию ИТ-инфраструктуры. Следует отметить, что методы проектирования появились существенно раньше большинства обсуждаемых здесь вопросов. Многие из них известны с тех самых времен, когда проектирование перестали считать шаманством. В контексте рассматриваемой задачи представляется целесообразным упомянуть следующие четыре метода: упрощение, стандартизация, модульность и интеграция. На первый взгляд все перечисленные методы общеизвестны и тривиальны. И все же ошибочно понимаемая модульность может стать причиной крушения надежд. Например, можно тщательно подбирать модули для ИТ-инфраструктуры, строго следя за тем, чтобы каждый модуль имел сертификат качества, гарантию и поддерживал необходимые стандарты. Можно «от и до» изучить техническую документацию, научные журналы и энциклопедии. При всем этом инфраструктура может оказаться не подготовленной в равной степени как к изменениям, так и к работе в стационарных условиях - и не заработать. При таком подходе удивительно то, что некоторые системы вообще иногда работают. Ведь если система состоит примерно из 10 тысяч элементов, а каждый элемент имеет вероятность выхода из строя примерно одну десятитысячную, то вероятность сбоя очень велика. Чтобы избежать это, нужно уйти от атомарного подхода, отделить логический уровень представления системы от физического и начать диалог с бизнесом. Методы проектирования архитектуры платформы и системы управления ИТ-инфраструктурой
Методы реализации Проект ИТ-инфраструктуры будет иметь значительно больше шансов на успех, если в процессе разработки учесть методы его возможной реализации. Наиболее эффективный результат достигается при реализации «сверху вниз (greenfield)». Однако именно этот метод является также и самым затратным и самым рискованным. Обязательное условие его использования - наличие проработанной стратегии развития бизнеса. Необходима огромная предварительная работа и возможность выполнять централизованное управление изменениями. Наиболее просто внедряется метод реализации «снизу вверх (grassroots)». Этот метод не предполагает радикального перепроектирования системы и фокусируется на совместимости и интеграции существующих приложений без пересмотра выполняемых функций. Но полученный результат — это адаптивность с множественными оговорками. Баланс между интеграцией и реорганизацией взаимодействия бизнеса с ИТ обеспечивает «комбинированный (pragmatic)» метод. Используются как принципы проектирования адаптивной инфраструктуры, так и технологии. Результат — долговременная стратегия развития при ограниченной адаптивности на первых этапах. Методы реализации адаптивной ИТ-инфраструктуры
И, наконец, самое важное: нельзя обеспечить адаптивность исключительно на уровне методологии. Каждый используемый компонент должен обладать свойствами и техническими характеристиками, согласующимися с принципами адаптивности. С помощью правильных продуктов и правильных методологий можно построить более совершенную адаптивную ИТ-инфраструктуру, чем только с помощью методологий. Александр Старыгин |
Концепция адаптивной ИТ-инфраструктуры, сформулированная более четырех лет назад, переживает сегодня период расцвета, обрастая технологиями и продуктами, впитывая опыт выполненных проектов и проведенных аналитических исследований. Совершенствуя методы проектирования и подходы к оценке эффективности. Термин «адаптивность» стал привычным даже в устах технических специалистов.
