Как и для всякого проекта, при разработке и внедрении архитектуры предприятия нужно уметь оценивать уровень полученного результата. Для этого META Group рекомендовала использовать шкалу зрелости, аналогичную той, которая применяется в методике Capability
Мы неоднократно будем сталкиваться с аналогичными моделями оценки зрелости тех или иных процессов, например, процесса организации инвестиций в ИТ. В основе всех таких моделей, по большому счету, лежит новаторская работа Филиппа Кросби (Philip Crosby) "Quality is Free" (дословно, "Качество – это бесплатно") 1979 года. Эти идеи легли в основу концепции и теории Тотального управления качеством
Кросби разработал методику, которая включает в себя пять стадий или уровней развития процессов, связанных с качеством. Он назвал эти стадии следующим образом:
В отношении архитектуры предлагаемая модель относит зрелость архитектуры предприятия также к одному из пяти уровней:
Уровень 1. Начальный.
Уровень 2. Повторяемый.
Уровень 3. Определенный или регламентируемый.
Уровень 4. Управляемый.
Уровень 5. Оптимизирующий.
В табл. 12.1 приведены общие характеристики уровней организационной зрелости.
| Уровень | Основные характеристики |
|---|---|
| 1. Начальный | Спонтанные информационные связи. Хаотичность, непоследовательность |
| 2. Повторяемый | Базовые процессы. Повторяемые операции |
| 3. Определенный | Стандартизация процессов. Интеграция, наличие процедур |
| 4. Управляемый | Контроль качества. Использование обратной связи |
| 5. Оптимизирующий | Постоянное развитие. Самоадаптация системы |
Таблица 12.2 подробнее расшифровывает критерии, которым архитектура должна удовлетворять на различных уровнях своего развития.
| Уровень 1 начальный | Уровень 2 повторяемый | Уровень 3 определенный | Уровень 4 управляемый | Уровень 5 оптимизированный | |
|---|---|---|---|---|---|
| Связь с |
Отсутствует или неявная | Явная связь с миссией. | Явная связь с ключевыми параметрами миссии | Периодическая переоценка актуальности связи. Контролируемый интервал времени между изменением требований и изменением архитектуры | Процессы постоянно улучшаются на основании измеряемых требований |
| Вовлеченность высшего руководства | "Что такое корпоративная архитектура?" "Зачем она нам вообще нужна?" "Нет, это у нас работать не будет" | Руководство что-то слышало о проекте по разработке архитектуры. Усердное кивание головами. Некоторое сопротивление в связи с ожидаемыми результатами | Руководство в курсе проекта и поддерживает его. Руководство поддерживает наличие стандартов | Высшее руководство участвует в обсуждении результатов проекта | Руководство активно участвует в оптимизации бизнес-процессов в рамках архитектурного проекта. |
| Участие бизнес-подразделений | "Мы поддерживаем данный проект, пока он рекомендует те стандарты, которые мы уже сами раньше выбрали". "Стандарты только помешают нам реализовать миссию предприятия" | Признание факта, что поддержка слишком большого числа разных технологий накладна. Возможно разочарование от внедрения инновационных приложений "в пустоте" | Признание факта, что стандарты архитектуры помогут облегчить интеграцию и повысят шансы компании на реализацию миссии. Большинство бизнес-подразделений активно участвуют в разработке архитектуры | Все бизнес-подразделения активно участвуют в разработке архитектуры | Рекомендации бизнес-подразделений используются для улучшения самого процесса разработки архитектуры |
| Описание самого процесса разработки архитектуры | Отсутствует или сохраняется в том виде, как осталось к моменту завершения прошлого провального проекта | Активно разрабатывается внутри ИТ-службы. Недостаточно широко известно в организации | Процесс хорошо определен и известен ИТ-специалистам и бизнес-подразделениям | Процесс является частью корпоративной культуры, он сильно связан с другими процессами, такими как финансовое планирование, реинжиниринг, разработка новых продуктов и др. | Спланированные усилия по оптимизации процесса. Моделирование предлагаемых изменений процесса перед реализацией |
| Разработка |
Нет никакой архитектуры – просто не о чем говорить. Несколько стандартов, выбранных случайным образом | Стандарты существуют, но не объединены в систему | Разработка |
Архитектура компонент ИС определена вплоть до уровня стандартов. Эксплуатируемые системы проверяются на соответствие стандартам | То же, что и на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса разработки aрхитектуры |
| Распространение описания архитектуры в организации | Вроде бы описание находится в папке, которую недавно видели где-то в службе ИТ. Новые сотрудники ИТ-службы, вероятнее всего, даже не знают о существовании этой папки | Папка с описанием архитектуры периодически обновляется, или результаты размещаются на web-сайте. Для документирования используется MS Word и картинки. Совещания и обсуждения архитектуры иногда имеют место | Документы регулярно обновляются и уточняются. Актуальная на каждый момент версия доступна на web-сайте, в БД коллективного доступа и т.п. Для управления документацией используются специализированные средства. Периодические презентации по ходу процесса для ИТ-службы. Вероятно, они входят в курс начального обучения новых сотрудников | Документы регулярно обновляются и уточняются с контролируемыми сроками. Проводится мониторинг обучения и ознакомления | То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса распространения архитектуры |
| Контроль за применением стандартов | Явные процедуры отсутствуют | Некоторые стандарты контролируются (напр., ПО рабочих станций). Отклонения на стадиях проектирования и внедрения могут остаться незамеченными | Явный контроль основной части стандартов. Формализованный процесс рассмотрения отклонений | Явный контроль всех инвестиций в ИТ. Формализованный процесс использования выявленных отклонений для коррекции архитектуры | То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса контроля |
| Управление проектом разработки архитектуры | Стандарты и средства отсутствуют или случайные. Формальный механизм определения приоритетов отсутствует | Используются средства планирования и управления. Оценка рисков производится командой проекта | Целевая архитектура определяет требования к квалификации персонала. Процедуры управления изменениями определены и связаны с процессом рецензирования архитектуры | Инициация проекта и определение ключевых требований производится совместно руководителями организации и ИТ-службы. Управление вендорами – одна из ключевых компетенций. Требования непрерывности производства заложены в цикл планирования проекта | Действует программа обеспечения результативности. Контракты с вендорами продлеваются на основе измеряемых показателей производительности и соответствия корпоративным стандартам. Ключевая компетенция – непрерывность бизнеса |
| Корпоративная архитектура масштаба предприятия | Миссия, требования к данным и приложениям определены только в принципе. Данные о процессах, приложениях, информационных ресурсах, а также их модели неполны или отсутствуют вообще | Большинство приложений перечислены в реестре. Для части бизнес-процессов существуют модели | Все приложения классифицированы в реестре в соответствии с их позиционированием для бизнеса и состоянием. Модели бизнес-процессов существуют и используются для проектирования разработки решений | Моделирование процессов и выбор приложений производится в соответствии с архитектурой. Методы и средства моделирования периодически проверяются. Оцениваются затраты времени на моделирование и фактическое использование моделей | Метрики, определяемые на уровне 4, используются для улучшения процессов. Происходит переход от использования отдельных приложений к использованию решений. Бизнес-моделирование является постоянным и обязательным, актуальные модели сохраняются в |
| Организация закупок ИТ | Стратегия закупок отсутствует. Персонал, участвующий в закупках, не принимает заметного участия в процессе разработки архитектуры | Декларируется следование процедурам и стандартам. Контроль заявок и фактических закупок на соответствие архитектуре неполный или отсутствует | Стратегия закупок определена и предусматривает соответствие стандартам архитектуры. Требования запросов на закупку формируются с учетом стандартов. Персонал, осуществляющий закупки, участвует в контроле за соблюдением стандартов | Все закупки планируются и управляются в соответствии с определенной архитектурой. Оценка предложений поставщиков интегрирована в процесс планирования архитектуры. Существуют процедуры по учету и утилизации устаревающих компонент ИС | Незапланированные закупки отсутствуют |
Аналогичная модель, правда, с разбиением уровня 1 на два – "начальный" и "отсутствующий", предложена Институтом разработок архитектуры предприятия (Institute for Enterprise Architecture Developments) [6.26].
Интересное распределение организаций из группы Global 2000 по степени зрелости архитектуры приведено, по данным [6.27], в таблице 12.3.
| Уровень | 2004 | 2007 (прогноз) |
|---|---|---|
| 1 | 30% | 15% |
| 2 | 45% | 40% |
| 3 | 20% | 35% |
| 4 | <5% | 10% |
| 5 | нет | <1% |
Как же на практике реализуется "самый нижний" уровень ИТ-архитектуры предприятия, связанный непосредственно с определением инфраструктуры ИТ? Принимая во внимание наличие детально разработанных стандартов открытых систем, их "привлекательность" и "обоснованность" со стороны многих международных, национальных и некоммерческих организаций по стандартизации, можно было бы ожидать, что за прошедшие с их появления примерно 10 лет большая часть окружающих нас информационных систем должна бы полностью соответствовать их принципам.
Увы, в действительности этого не наблюдается. Основные причины заключаются в том [6.28], что, с одной стороны, эти стандарты не являются необходимо полными, а с другой – производители программных и аппаратных средств реально далеко не всегда выпускают взаимозаменяемые продукты, даже когда они (частично) соответствуют одним и тем же стандартам. Дополнительным фактором может являться значительное время, которое требуется для согласования и утверждения стандартов. Поэтому многим предприятиям приходится выбирать ограниченное количество вендоров и в дальнейшем руководствоваться совместимостью с данными технологиями.
Следствием такого выбора становится тот факт, что принцип "единства архитектуры" перестает быть абсолютным. В ряде случаев оказывается, что определенное отклонение от установленных принципов может быть обосновано. Например, предприятие могло бы выбрать СУБД Oracle и UNIX-платформу для ведения основных производственных баз данных, требующих высокой производительности и надежности. Но для реализации решаемой в течение одного месяца задачи ввода данных из архивов вновь приобретенной компании вполне могут использоваться более простые и дешевые средства. Другим примером может служить применение готового, существующего на рынке, приложения для решения частной задачи одного из бизнес-подразделений. Даже если это приложение будет использовать другую СУБД, отличную от той, которая определена в стандарте предприятия, практически во всех случаях стандарт будет либо проигнорирован, либо пересмотрен. В любом случае, нужно также учитывать и факторы инвестиций и времени, необходимых для перехода к единой архитектуре в масштабе предприятия. При этом, как правило, чем более жесткие ограничения накладывает архитектура предприятия, тем менее она становится полезной на практике.
Означает ли это, что на самом деле все приводимые ранее аргументы в пользу наличия архитектуры бесполезны? Ни в коей мере. Потенциально преимущества всегда могут быть достигнуты, вопрос только в нахождении оптимального компромисса между преимуществами и усилиями, потраченными на определение и достижение целевой "идеальной" архитектуры.
Таким образом, главной целью проекта должно являться создание не "абстрактной, совершенной" архитектуры, а, скорее, "достаточно хорошей". Одним из основных параметров такой архитектуры будет являться гибкость, позволяющая относительно быстро подстраиваться под меняющиеся внешние условия.
Выше мы уже говорили о том, что архитектура предприятия неизбежно является упрощенной моделью бесконечно сложной реальности под названием "организация". Это означает, что нужен компромисс в степени детализации такого описания.
Основная рекомендация, которая существует на этот счет, состоит в том, что следует придерживаться минималистского подхода в проектировании архитектуры, т.е. определять требования к архитектуре самого высокого приоритета и затем делать минимально возможное и не более того, чтобы удовлетворить этим требованиям [6.29]. Это позволяет иметь ограниченный и контролируемый набор архитектурных решений, но в то же время оставляет необходимую степень свободы для технических специалистов по реализации функционала тех или иных систем.
Выше, в лекциях 3, 4, мы рассматривали различные уровни архитектурных решений:
Принцип состоит в том, что если достижение некоторого требования может быть реализовано за счет делегирования принятия решения на более низком уровне, то соответствующее решение не является важным с архитектурной точки зрения (по крайней мере, для данного уровня).
Это требует от нас более четкого осознания того, какие же все-таки решения являются архитектурными. Однозначно под эту категорию решений подпадают те, которые связаны с идентификацией структурных элементов систем или проектированием интерфейсов между элементами, включая спецификации и описание видимого поведения и свойств системы.
Очевидно, что архитектура предприятия должна скорее быть гибкой, чем идеальной. Это нашло отражение в принципе, который был сформулирован как "достаточно хорошая" архитектура [6.30]. При этом принцип "достаточно хорошей" архитектуры противостоит стремлению создания "идеальной" архитектуры. Философия заключается в том, чтобы создать достаточно гибкую и восприимчивую архитектуру, которая может модернизироваться в процессе своего жизненного цикла в ответ на изменения в моделях бизнеса и технологиях, и это гораздо важнее, чем создание теоретически правильной, идеальной архитектуры, представляющей полное и конечное видение.
Для реализации этого подхода рекомендуется следовать следующим трем принципам:
При этом имеются и другие элементы, определяющие "достаточно хорошую" архитектуру.
При рассмотрении архитектуры необходимо рассматривать три промежутка времени: сегодня, ближайшее будущее, отдаленная перспектива.
Gartner рекомендует 15% усилий и внимания уделять существующей сегодня в организации архитектуре, 70% – архитектуре, которую предполагается реализовать в ближайшем будущем, и еще 15% усилий – архитектуре, как она видится в отдаленной перспективе.
Работы, относящиеся к существующей сегодня архитектуре, связаны с анализом и документированием имеющейся архитектуры, т.е. созданием моделей имеющихся систем, описанием связей между системами, моделированием используемых данных и потоков работ. И хотя эти работы имеют важное значение с точки зрения каталогизации существующих связей, их ценность не очень велика с точки зрения обеспечения динамичности и гибкости организации. Обычно результатом излишних усилий по описанию сегодняшней архитектуры являются альбомы и папки с документами, которые большую часть времени стоят на полках без дела. Поэтому, признавая ценность определенных усилий по каталогизации (они позволяют оценивать влияние рассматриваемых к внедрению новых систем), время, инвестируемое в сегодняшнюю архитектуру, должно быть минимизировано.
Целью проектирования будущей архитектуры является обеспечение синхронизации долгосрочной ИТ-стратегии с долгосрочной бизнес-стратегией, как правило, во временном диапазоне трех лет и более. И, несмотря на то, что это важно, предполагаемая к реализации в отдаленном будущем архитектура, как правило, носит достаточно общий, недетализированный характер, поскольку будущее по своей природе неизвестно как с точки зрения бизнеса, так и с точки зрения информационных технологий. Например, на уровне бизнеса при описании долгосрочной стратегии могут использоваться утверждения типа "мы хотим быть самой крупной сетью магазинов в городе N". И хотя такого рода утверждения могут быть великолепным долгосрочным ориентиром для компании, они дают немного с точки зрения направления развития ИТ. Они слишком для этого абстрактны.
Поэтому "достаточно хорошая" архитектура должна описывать архитектуру предприятия завтрашнего дня, ближайшего будущего и обеспечивать руководства, модели, интерфейсы, определения и протоколы для непосредственного использования в процессе проектирования и интеграции новых систем.
(рис 12.1) Стратегическое окно возможностей для "достаточно хорошей" архитектурыДействительно, ведь когда вы съезжаете с горы на лыжах по выбранной (черной, красной, синей, зеленой) трассе, вы не думаете о том, где находится подножье горы, а прогнозируете для себя прежде всего то, как и где вы сделаете несколько ближайших поворотов. И после очередного поворота вы снова оцениваете свое положение и возможные маневры на некоторое расстояние вперед.
Аналогично, "архитектура завтрашнего дня" обеспечивает такой взгляд в будущее на достаточно короткую перспективу. Если архитектура создается, в первую очередь, для обеспечения динамичности предприятия, она должна постоянно настраиваться на новые возможности, которые открываются в бизнесе и информационных технологиях. Принятие правильных решений на уровне непосредственных, ближайших шагов гораздо важнее, чем определение конечной цели – спуска к подножью горы.
Необходимо также учитывать еще один временной горизонт, который называется "стратегическое окно возможностей":
Интересно отметить, что за прошедшие между двумя публикациями Gartner 4 года рекомендуемая продолжительность среднесрочного горизонта планирования сократилась с 2-3 лет до 18 месяцев, а стратегического горизонта – с 3-5 лет до 30 месяцев. Очевидно, что это связано с влиянием происходящего глобального ускорения бизнес-процессов и постоянного развития информационных технологий.
Архитектура должна приносить пользу, прежде всего, с точки зрения достаточно короткого, 9-месячного промежутка времени. Окно оперативных возможностей должно постоянно перемещаться и соответствовать интервалу примерно в 18 месяцев. Это тот период времени, который связан с нашим понятием "архитектура завтрашнего дня". Стратегическое окно должно быть не более 30 месяцев и соответствовать принятому в компании горизонту стратегического планирования.
Третья метрика связана с распределением усилий на различных фазах жизненного цикла архитектуры. Управление, руководство и надзор над процессом создания архитектуры должны занимать примерно 40% всех усилий по созданию архитектуры. Вторым по "значимости" аспектом проекта – порядка 30% усилий – является собственно разработка моделей, стратегий, решений и их документирование, то, что обычно понимается под понятием "построение, разработка архитектуры". Примерно по 15% усилий рекомендуется сосредоточить на обеспечении восприятия предложенных решений со стороны руководства и бизнес-подразделений – то есть "продаже" идеи внутри организации, а также на проведение оценки и сравнительного анализа с лучшими практиками или доступными аналогами.
Действительно, хотя отдельные ошибки в выборе конкретной технологии могут иногда привести к неудаче всей архитектуры в целом, все-таки большинство проблем при создании архитектуры являются следствием плохого управления и контроля.
Многие архитекторы считают, что основной фокус усилий по созданию архитектуры должен лежать в области технологий. Однако даже достаточно хорошо проработанная с технологической точки зрения архитектура может потерпеть неудачу при реализации, если не организовать правильно процесс управления.
Таким образом, наиболее важными вопросами, на которые необходимо обращать внимание при управлении архитектурным процессом, являются следующие:
При этом ключевым элементом для решения первой из задач является максимальная конкретность, которая достигается прежде всего за счет наличия явной связи между каждым архитектурным элементом и бизнес-целью. Эти шаги обеспечивают создание необходимой среды для использования в организации архитектуры и обоснование необходимости инвестиций в разработку архитектуры. Обоснование инвестиций в архитектуру должно быть основано на использовании конкретной информации, связанной со специфическими целями и задачами бизнеса организации. Общие слова в этом плане могут быть врагом архитектуры. Каждый элемент архитектуры должен поддерживать достижение определенной бизнес-цели.
Проведение же периодических измерений, сравнений и оценок позволяет проводить необходимые корректировки уже в ходе реализации проектов, основываясь на измеряемых объективных показателях. Это помогает увидеть результаты работы по созданию архитектуры, обеспечивает возможность внесения необходимых изменений и создает обратную связь для всего процесса.
Описание Архитектуры предприятия связано с большим количеством информации, которая поступает из различных источников и имеет различные форматы: текст, графические модели и пр. Кроме того, с этой информацией должно работать достаточно большое количество людей. Различные модели определенным образом связаны между собой, и эти связи необходимо также отслеживать для того, чтобы имелась возможность достаточно эффективного анализа архитектуры предприятия и влияния принимаемых решений.
Некоторые организации вполне могут обходиться без специализированных средств разработки архитектуры, ограничиваясь использованием графических пакетов типа Microsoft Visio для построения различных типов моделей (благо в этом пакете имеется для этого огромное количество шаблонов, от конструкций языка UML до шаблонов описания организационных структур, потоков работ и описания унаследованных приложений), а также использованием текстовых редакторов и электронных таблиц.
Однако по мере того, как количество различных артефактов (документов, моделей), создаваемых в процессе работы над архитектурой, растет, становится понятно, что использование только этих "подручных" средств приводит к потере качества, потере связей между артефактами и целостности описания архитектуры.
Для удовлетворения этих специфических потребностей в обеспечении архитектурного процесса появился целый класс программных продуктов. Перечислим названия некоторых компаний-разработчиков таких систем, многие из которых, за исключением последней, практически неизвестны на российском рынке: Casewise, Computas, Framework Software, Popkin Software, Proforma, Ptech, Rational Software.
(рис 12.2) Источники информации для систем разработки Архитектуры предприятияНе описывая и не сравнивая различные системы, которые могут использоваться для разработки архитектуры предприятия, опишем основной функционал, который они могут предоставлять.
Различные планы, модели и документы, связанные с архитектурой, должны быть помещены в репозитории (специальной базе данных, созданной для хранения многих типов документов и диаграмм). Между ними должны быть установлены необходимые связи. При этом различные группы пользователей рассматривают различные категории информации и представления одной и той же архитектуры предприятия. Бизнес-менеджеров, например, больше будут интересовать диаграммы с информацией о бизнес-процессах. Менеджеров ИТ будут интересовать прикладные системы, связанные с этими бизнес-процессами, а на более глубоком уровне анализа их могут интересовать диаграммы, описывающие внутреннюю архитектуру этих систем. Если архитектура документирована с достаточной степенью детализации, появляется возможность отслеживания влияния возможных изменений. Репозиторий может содержать, например, информацию о сотрудниках и затратах. При этом появляется возможность анализировать влияние изменений в бизнес-процессах на стоимость их выполнения. Эти средства должны обеспечивать хранение артефактов в репозитории в соответствии с принятыми методиками описания архитектуры, такими, например, как модель Захмана; и чем большее количество методик выбранное средство поддерживает, тем больше возможностей выбора у пользователей.
При этом многие модели и иная связанная с архитектурой предприятия информация, в любом случае, создается и будет создаваться с использованием других программных продуктов и инструментальных средств, поэтому средства разработки архитектуры предприятия должны иметь возможность использования внешних источников информации, некоторые из которых показаны на рис. 12.2.
(рис 12.3) Принципы работы систем поддержки процесса разработки архитектурыПеречислим более детально набор возможных функций систем разработки архитектуры предприятия:
В идеале, это должен быть двунаправленный процесс. Например, модели бизнес-процессов могут быть уже подготовлены с помощью пакета
Рисунок 12.3 схематично показывает связи между интерфейсом, который дает представление описаний архитектуры в соответствии с выбранной методикой, диаграммами, моделями и документами различных поддерживаемых форматов, репозиторием и
Согласитесь, что это достаточно обширный список функциональных возможностей, которые обеспечивают эти системы и которые в действительности могут потребоваться на различных этапах работы над архитектурой предприятия. Поэтому в достаточно сложных архитектурных проектах их использование может оказать существенную помощь. Однако при выборе поставщиков таких систем следует иметь в виду, что рынок этих систем сам по себе достаточно молодой и не вполне сформировавшийся, поэтому возможны быстрые изменения в списке компаний-участников и доступности тех или иных инструментальных средств.
Мы уже отмечали ранее необходимость постоянного мониторинга тенденций развития ИТ, чтобы обеспечить постоянное соответствие информационных систем предприятия требованиям бизнеса и иметь возможности для получения конкурентного преимущества. Для решения этой задачи специалисты Gartner [6.31] рекомендуют создавать специализированную группу новых технологий. Подчеркнем, что речь идет, прежде всего, о частной задаче мониторинга технологий для развития информационных систем – то есть, работа этой группы не подменяет деятельность департамента исследований и разработок, занятого развитием основного бизнеса компании.
В задачи этой группы входят: определение интересующей компанию области, отслеживание новых продуктов и технологий в данной области, ранжирование или приоритезация потенциальных продуктов-кандидатов, практическая оценка, "просвещение" пользователей в организации о достигаемых преимуществах и, наконец, собственно внедрение. Отметим, что определение интересующей компанию фокус-области должно проводиться как бы "c разных сторон" – прежде всего c учетом стратегических целей компании, которые могут быть прослежены до технологических областей, а также наоборот – отталкиваясь от пожеланий бизнес-подразделений. Еще одним важным аспектом является включение в фокус-область тех технологий, которые в данный момент не используются в бизнесе компании, но могут быть полезны при его функциональном расширении.
Группа, занимающаяся оценкой технологий, как правило, невелика по численному составу и может насчитывать от 2-3 человек в небольших компаниях до 10-12 в крупных холдингах. Интересным решением может стать плановая периодическая ротация ее состава с производственными подразделениями. Такой подход обладает дополнительным преимуществом, так как сотрудник, приходящий или возвращающийся в свое подразделение после работы в группе, эффективно продолжает свою "просветительскую" деятельность, рассказывая об известных решениях. В компаниях типа A и наиболее рыночно-агрессивных компаниях типа B (распределение компаний по группам A, B, C в зависимости от отношения к внедрению новых технологий обсуждалось в лекциях 1 и 2) такая группа обычно входит в состав ИТ-службы, но является выделенной и независимой в том плане, что она подчиняется напрямую
На основании анализа доступной информации по деятельности таких групп в различных организациях специалисты Gartner смогли выделить пять характерных типов "поведения" таких групп. Конечно, на практике встречаются и смешанные характеры, но, как правило, один из типов всегда преобладает. В таблице 12.4 для них приведены типичные характеристики и возникающие проблемы.
| Название | Стиль работы | Проблемы |
|---|---|---|
| Штурманы | Мониторинг и оценка приложений с концентрацией на стратегических направлениях для компании | Не всегда успешная оценка продукта или технологии бывает востребована в подразделении |
| Партизаны | Незаметно помогают бизнес-подразделениям внедрять новые продукты | Нехватка времени для стратегического анализа и мониторинга |
| Проповедники | Рассказывают высшему руководству компании о преимуществах новых технологий и продуктов | Нежелание что-либо проверять самим на практике |
| Проводники | Координируют и направляют усилия других подразделений по оценке технологий | Не всегда достигается практический результат |
| Теоретики (sсholars) | Заняты изучением технологий послезавтрашнего дня | Сложно обеспечить связь с насущными потребностями бизнеса компании |
Относительный объем финансирования такого стратегического мониторинга технологий сильно зависит от масштаба компании и обратно пропорционален доходу, т.е. небольшие компании вынуждены тратить больший процент своего дохода на анализ новых технологий. Для компаний с доходом до $100 млн. в год средними значениями являются 0,7% от дохода и 7,5% от операционного ИТ-бюджета.
Для государственных организаций проблема применения новых технологий приобретает дополнительную сложность. Вполне объяснимыми причинами того служат:
Результатом может явиться и является:
В этом случае выходом может являться централизованная деятельность. Например, в рамках проектов "электронного правительства" (например, ФЦП "Электронная Россия") имело бы смысл активизировать процесс накопления экспертизы и знаний в области архитектурных шаблонов, использующих новые технологии, для государственных информационных систем, а также организовать заказные работы для объективного анализа перспективных технологий по отдельным направлениям реализации программы с размещением результатов в свободном, по крайней мере, для государственных организаций, доступе.
Как и для всякого проекта, при разработке и внедрении архитектуры предприятия нужно уметь оценивать уровень полученного результата. Для этого META Group рекомендовала использовать шкалу зрелости, аналогичную той, которая применяется в методике Capability
Мы неоднократно будем сталкиваться с аналогичными моделями оценки зрелости тех или иных процессов, например, процесса организации инвестиций в ИТ. В основе всех таких моделей, по большому счету, лежит новаторская работа Филиппа Кросби (Philip Crosby) "Quality is Free" (дословно, "Качество – это бесплатно") 1979 года. Эти идеи легли в основу концепции и теории Тотального управления качеством
Кросби разработал методику, которая включает в себя пять стадий или уровней развития процессов, связанных с качеством. Он назвал эти стадии следующим образом:
В отношении архитектуры предлагаемая модель относит зрелость архитектуры предприятия также к одному из пяти уровней:
Уровень 1. Начальный.
Уровень 2. Повторяемый.
Уровень 3. Определенный или регламентируемый.
Уровень 4. Управляемый.
Уровень 5. Оптимизирующий.
В табл. 12.1 приведены общие характеристики уровней организационной зрелости.
| Уровень | Основные характеристики |
|---|---|
| 1. Начальный | Спонтанные информационные связи. Хаотичность, непоследовательность |
| 2. Повторяемый | Базовые процессы. Повторяемые операции |
| 3. Определенный | Стандартизация процессов. Интеграция, наличие процедур |
| 4. Управляемый | Контроль качества. Использование обратной связи |
| 5. Оптимизирующий | Постоянное развитие. Самоадаптация системы |
Таблица 12.2 подробнее расшифровывает критерии, которым архитектура должна удовлетворять на различных уровнях своего развития.
| Уровень 1 начальный | Уровень 2 повторяемый | Уровень 3 определенный | Уровень 4 управляемый | Уровень 5 оптимизированный | |
|---|---|---|---|---|---|
| Связь с |
Отсутствует или неявная | Явная связь с миссией. | Явная связь с ключевыми параметрами миссии | Периодическая переоценка актуальности связи. Контролируемый интервал времени между изменением требований и изменением архитектуры | Процессы постоянно улучшаются на основании измеряемых требований |
| Вовлеченность высшего руководства | "Что такое корпоративная архитектура?" "Зачем она нам вообще нужна?" "Нет, это у нас работать не будет" | Руководство что-то слышало о проекте по разработке архитектуры. Усердное кивание головами. Некоторое сопротивление в связи с ожидаемыми результатами | Руководство в курсе проекта и поддерживает его. Руководство поддерживает наличие стандартов | Высшее руководство участвует в обсуждении результатов проекта | Руководство активно участвует в оптимизации бизнес-процессов в рамках архитектурного проекта. |
| Участие бизнес-подразделений | "Мы поддерживаем данный проект, пока он рекомендует те стандарты, которые мы уже сами раньше выбрали". "Стандарты только помешают нам реализовать миссию предприятия" | Признание факта, что поддержка слишком большого числа разных технологий накладна. Возможно разочарование от внедрения инновационных приложений "в пустоте" | Признание факта, что стандарты архитектуры помогут облегчить интеграцию и повысят шансы компании на реализацию миссии. Большинство бизнес-подразделений активно участвуют в разработке архитектуры | Все бизнес-подразделения активно участвуют в разработке архитектуры | Рекомендации бизнес-подразделений используются для улучшения самого процесса разработки архитектуры |
| Описание самого процесса разработки архитектуры | Отсутствует или сохраняется в том виде, как осталось к моменту завершения прошлого провального проекта | Активно разрабатывается внутри ИТ-службы. Недостаточно широко известно в организации | Процесс хорошо определен и известен ИТ-специалистам и бизнес-подразделениям | Процесс является частью корпоративной культуры, он сильно связан с другими процессами, такими как финансовое планирование, реинжиниринг, разработка новых продуктов и др. | Спланированные усилия по оптимизации процесса. Моделирование предлагаемых изменений процесса перед реализацией |
| Разработка |
Нет никакой архитектуры – просто не о чем говорить. Несколько стандартов, выбранных случайным образом | Стандарты существуют, но не объединены в систему | Разработка |
Архитектура компонент ИС определена вплоть до уровня стандартов. Эксплуатируемые системы проверяются на соответствие стандартам | То же, что и на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса разработки aрхитектуры |
| Распространение описания архитектуры в организации | Вроде бы описание находится в папке, которую недавно видели где-то в службе ИТ. Новые сотрудники ИТ-службы, вероятнее всего, даже не знают о существовании этой папки | Папка с описанием архитектуры периодически обновляется, или результаты размещаются на web-сайте. Для документирования используется MS Word и картинки. Совещания и обсуждения архитектуры иногда имеют место | Документы регулярно обновляются и уточняются. Актуальная на каждый момент версия доступна на web-сайте, в БД коллективного доступа и т.п. Для управления документацией используются специализированные средства. Периодические презентации по ходу процесса для ИТ-службы. Вероятно, они входят в курс начального обучения новых сотрудников | Документы регулярно обновляются и уточняются с контролируемыми сроками. Проводится мониторинг обучения и ознакомления | То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса распространения архитектуры |
| Контроль за применением стандартов | Явные процедуры отсутствуют | Некоторые стандарты контролируются (напр., ПО рабочих станций). Отклонения на стадиях проектирования и внедрения могут остаться незамеченными | Явный контроль основной части стандартов. Формализованный процесс рассмотрения отклонений | Явный контроль всех инвестиций в ИТ. Формализованный процесс использования выявленных отклонений для коррекции архитектуры | То же, что на уровне 4. Дополнительно – исключительные ситуации используются для улучшения процесса контроля |
| Управление проектом разработки архитектуры | Стандарты и средства отсутствуют или случайные. Формальный механизм определения приоритетов отсутствует | Используются средства планирования и управления. Оценка рисков производится командой проекта | Целевая архитектура определяет требования к квалификации персонала. Процедуры управления изменениями определены и связаны с процессом рецензирования архитектуры | Инициация проекта и определение ключевых требований производится совместно руководителями организации и ИТ-службы. Управление вендорами – одна из ключевых компетенций. Требования непрерывности производства заложены в цикл планирования проекта | Действует программа обеспечения результативности. Контракты с вендорами продлеваются на основе измеряемых показателей производительности и соответствия корпоративным стандартам. Ключевая компетенция – непрерывность бизнеса |
| Корпоративная архитектура масштаба предприятия | Миссия, требования к данным и приложениям определены только в принципе. Данные о процессах, приложениях, информационных ресурсах, а также их модели неполны или отсутствуют вообще | Большинство приложений перечислены в реестре. Для части бизнес-процессов существуют модели | Все приложения классифицированы в реестре в соответствии с их позиционированием для бизнеса и состоянием. Модели бизнес-процессов существуют и используются для проектирования разработки решений | Моделирование процессов и выбор приложений производится в соответствии с архитектурой. Методы и средства моделирования периодически проверяются. Оцениваются затраты времени на моделирование и фактическое использование моделей | Метрики, определяемые на уровне 4, используются для улучшения процессов. Происходит переход от использования отдельных приложений к использованию решений. Бизнес-моделирование является постоянным и обязательным, актуальные модели сохраняются в |
| Организация закупок ИТ | Стратегия закупок отсутствует. Персонал, участвующий в закупках, не принимает заметного участия в процессе разработки архитектуры | Декларируется следование процедурам и стандартам. Контроль заявок и фактических закупок на соответствие архитектуре неполный или отсутствует | Стратегия закупок определена и предусматривает соответствие стандартам архитектуры. Требования запросов на закупку формируются с учетом стандартов. Персонал, осуществляющий закупки, участвует в контроле за соблюдением стандартов | Все закупки планируются и управляются в соответствии с определенной архитектурой. Оценка предложений поставщиков интегрирована в процесс планирования архитектуры. Существуют процедуры по учету и утилизации устаревающих компонент ИС | Незапланированные закупки отсутствуют |
Аналогичная модель, правда, с разбиением уровня 1 на два – "начальный" и "отсутствующий", предложена Институтом разработок архитектуры предприятия (Institute for Enterprise Architecture Developments) [6.26].
Интересное распределение организаций из группы Global 2000 по степени зрелости архитектуры приведено, по данным [6.27], в таблице 12.3.
| Уровень | 2004 | 2007 (прогноз) |
|---|---|---|
| 1 | 30% | 15% |
| 2 | 45% | 40% |
| 3 | 20% | 35% |
| 4 | <5% | 10% |
| 5 | нет | <1% |
Как же на практике реализуется "самый нижний" уровень ИТ-архитектуры предприятия, связанный непосредственно с определением инфраструктуры ИТ? Принимая во внимание наличие детально разработанных стандартов открытых систем, их "привлекательность" и "обоснованность" со стороны многих международных, национальных и некоммерческих организаций по стандартизации, можно было бы ожидать, что за прошедшие с их появления примерно 10 лет большая часть окружающих нас информационных систем должна бы полностью соответствовать их принципам.
Увы, в действительности этого не наблюдается. Основные причины заключаются в том [6.28], что, с одной стороны, эти стандарты не являются необходимо полными, а с другой – производители программных и аппаратных средств реально далеко не всегда выпускают взаимозаменяемые продукты, даже когда они (частично) соответствуют одним и тем же стандартам. Дополнительным фактором может являться значительное время, которое требуется для согласования и утверждения стандартов. Поэтому многим предприятиям приходится выбирать ограниченное количество вендоров и в дальнейшем руководствоваться совместимостью с данными технологиями.
Следствием такого выбора становится тот факт, что принцип "единства архитектуры" перестает быть абсолютным. В ряде случаев оказывается, что определенное отклонение от установленных принципов может быть обосновано. Например, предприятие могло бы выбрать СУБД Oracle и UNIX-платформу для ведения основных производственных баз данных, требующих высокой производительности и надежности. Но для реализации решаемой в течение одного месяца задачи ввода данных из архивов вновь приобретенной компании вполне могут использоваться более простые и дешевые средства. Другим примером может служить применение готового, существующего на рынке, приложения для решения частной задачи одного из бизнес-подразделений. Даже если это приложение будет использовать другую СУБД, отличную от той, которая определена в стандарте предприятия, практически во всех случаях стандарт будет либо проигнорирован, либо пересмотрен. В любом случае, нужно также учитывать и факторы инвестиций и времени, необходимых для перехода к единой архитектуре в масштабе предприятия. При этом, как правило, чем более жесткие ограничения накладывает архитектура предприятия, тем менее она становится полезной на практике.
Означает ли это, что на самом деле все приводимые ранее аргументы в пользу наличия архитектуры бесполезны? Ни в коей мере. Потенциально преимущества всегда могут быть достигнуты, вопрос только в нахождении оптимального компромисса между преимуществами и усилиями, потраченными на определение и достижение целевой "идеальной" архитектуры.
Таким образом, главной целью проекта должно являться создание не "абстрактной, совершенной" архитектуры, а, скорее, "достаточно хорошей". Одним из основных параметров такой архитектуры будет являться гибкость, позволяющая относительно быстро подстраиваться под меняющиеся внешние условия.
Выше мы уже говорили о том, что архитектура предприятия неизбежно является упрощенной моделью бесконечно сложной реальности под названием "организация". Это означает, что нужен компромисс в степени детализации такого описания.
Основная рекомендация, которая существует на этот счет, состоит в том, что следует придерживаться минималистского подхода в проектировании архитектуры, т.е. определять требования к архитектуре самого высокого приоритета и затем делать минимально возможное и не более того, чтобы удовлетворить этим требованиям [6.29]. Это позволяет иметь ограниченный и контролируемый набор архитектурных решений, но в то же время оставляет необходимую степень свободы для технических специалистов по реализации функционала тех или иных систем.
Выше, в лекциях 3, 4, мы рассматривали различные уровни архитектурных решений:
Принцип состоит в том, что если достижение некоторого требования может быть реализовано за счет делегирования принятия решения на более низком уровне, то соответствующее решение не является важным с архитектурной точки зрения (по крайней мере, для данного уровня).
Это требует от нас более четкого осознания того, какие же все-таки решения являются архитектурными. Однозначно под эту категорию решений подпадают те, которые связаны с идентификацией структурных элементов систем или проектированием интерфейсов между элементами, включая спецификации и описание видимого поведения и свойств системы.
Очевидно, что архитектура предприятия должна скорее быть гибкой, чем идеальной. Это нашло отражение в принципе, который был сформулирован как "достаточно хорошая" архитектура [6.30]. При этом принцип "достаточно хорошей" архитектуры противостоит стремлению создания "идеальной" архитектуры. Философия заключается в том, чтобы создать достаточно гибкую и восприимчивую архитектуру, которая может модернизироваться в процессе своего жизненного цикла в ответ на изменения в моделях бизнеса и технологиях, и это гораздо важнее, чем создание теоретически правильной, идеальной архитектуры, представляющей полное и конечное видение.
Для реализации этого подхода рекомендуется следовать следующим трем принципам:
При этом имеются и другие элементы, определяющие "достаточно хорошую" архитектуру.
При рассмотрении архитектуры необходимо рассматривать три промежутка времени: сегодня, ближайшее будущее, отдаленная перспектива.
Gartner рекомендует 15% усилий и внимания уделять существующей сегодня в организации архитектуре, 70% – архитектуре, которую предполагается реализовать в ближайшем будущем, и еще 15% усилий – архитектуре, как она видится в отдаленной перспективе.
Работы, относящиеся к существующей сегодня архитектуре, связаны с анализом и документированием имеющейся архитектуры, т.е. созданием моделей имеющихся систем, описанием связей между системами, моделированием используемых данных и потоков работ. И хотя эти работы имеют важное значение с точки зрения каталогизации существующих связей, их ценность не очень велика с точки зрения обеспечения динамичности и гибкости организации. Обычно результатом излишних усилий по описанию сегодняшней архитектуры являются альбомы и папки с документами, которые большую часть времени стоят на полках без дела. Поэтому, признавая ценность определенных усилий по каталогизации (они позволяют оценивать влияние рассматриваемых к внедрению новых систем), время, инвестируемое в сегодняшнюю архитектуру, должно быть минимизировано.
Целью проектирования будущей архитектуры является обеспечение синхронизации долгосрочной ИТ-стратегии с долгосрочной бизнес-стратегией, как правило, во временном диапазоне трех лет и более. И, несмотря на то, что это важно, предполагаемая к реализации в отдаленном будущем архитектура, как правило, носит достаточно общий, недетализированный характер, поскольку будущее по своей природе неизвестно как с точки зрения бизнеса, так и с точки зрения информационных технологий. Например, на уровне бизнеса при описании долгосрочной стратегии могут использоваться утверждения типа "мы хотим быть самой крупной сетью магазинов в городе N". И хотя такого рода утверждения могут быть великолепным долгосрочным ориентиром для компании, они дают немного с точки зрения направления развития ИТ. Они слишком для этого абстрактны.
Поэтому "достаточно хорошая" архитектура должна описывать архитектуру предприятия завтрашнего дня, ближайшего будущего и обеспечивать руководства, модели, интерфейсы, определения и протоколы для непосредственного использования в процессе проектирования и интеграции новых систем.
(рис 12.1) Стратегическое окно возможностей для "достаточно хорошей" архитектурыДействительно, ведь когда вы съезжаете с горы на лыжах по выбранной (черной, красной, синей, зеленой) трассе, вы не думаете о том, где находится подножье горы, а прогнозируете для себя прежде всего то, как и где вы сделаете несколько ближайших поворотов. И после очередного поворота вы снова оцениваете свое положение и возможные маневры на некоторое расстояние вперед.
Аналогично, "архитектура завтрашнего дня" обеспечивает такой взгляд в будущее на достаточно короткую перспективу. Если архитектура создается, в первую очередь, для обеспечения динамичности предприятия, она должна постоянно настраиваться на новые возможности, которые открываются в бизнесе и информационных технологиях. Принятие правильных решений на уровне непосредственных, ближайших шагов гораздо важнее, чем определение конечной цели – спуска к подножью горы.
Необходимо также учитывать еще один временной горизонт, который называется "стратегическое окно возможностей":
Интересно отметить, что за прошедшие между двумя публикациями Gartner 4 года рекомендуемая продолжительность среднесрочного горизонта планирования сократилась с 2-3 лет до 18 месяцев, а стратегического горизонта – с 3-5 лет до 30 месяцев. Очевидно, что это связано с влиянием происходящего глобального ускорения бизнес-процессов и постоянного развития информационных технологий.
Архитектура должна приносить пользу, прежде всего, с точки зрения достаточно короткого, 9-месячного промежутка времени. Окно оперативных возможностей должно постоянно перемещаться и соответствовать интервалу примерно в 18 месяцев. Это тот период времени, который связан с нашим понятием "архитектура завтрашнего дня". Стратегическое окно должно быть не более 30 месяцев и соответствовать принятому в компании горизонту стратегического планирования.
Третья метрика связана с распределением усилий на различных фазах жизненного цикла архитектуры. Управление, руководство и надзор над процессом создания архитектуры должны занимать примерно 40% всех усилий по созданию архитектуры. Вторым по "значимости" аспектом проекта – порядка 30% усилий – является собственно разработка моделей, стратегий, решений и их документирование, то, что обычно понимается под понятием "построение, разработка архитектуры". Примерно по 15% усилий рекомендуется сосредоточить на обеспечении восприятия предложенных решений со стороны руководства и бизнес-подразделений – то есть "продаже" идеи внутри организации, а также на проведение оценки и сравнительного анализа с лучшими практиками или доступными аналогами.
Действительно, хотя отдельные ошибки в выборе конкретной технологии могут иногда привести к неудаче всей архитектуры в целом, все-таки большинство проблем при создании архитектуры являются следствием плохого управления и контроля.
Многие архитекторы считают, что основной фокус усилий по созданию архитектуры должен лежать в области технологий. Однако даже достаточно хорошо проработанная с технологической точки зрения архитектура может потерпеть неудачу при реализации, если не организовать правильно процесс управления.
Таким образом, наиболее важными вопросами, на которые необходимо обращать внимание при управлении архитектурным процессом, являются следующие:
При этом ключевым элементом для решения первой из задач является максимальная конкретность, которая достигается прежде всего за счет наличия явной связи между каждым архитектурным элементом и бизнес-целью. Эти шаги обеспечивают создание необходимой среды для использования в организации архитектуры и обоснование необходимости инвестиций в разработку архитектуры. Обоснование инвестиций в архитектуру должно быть основано на использовании конкретной информации, связанной со специфическими целями и задачами бизнеса организации. Общие слова в этом плане могут быть врагом архитектуры. Каждый элемент архитектуры должен поддерживать достижение определенной бизнес-цели.
Проведение же периодических измерений, сравнений и оценок позволяет проводить необходимые корректировки уже в ходе реализации проектов, основываясь на измеряемых объективных показателях. Это помогает увидеть результаты работы по созданию архитектуры, обеспечивает возможность внесения необходимых изменений и создает обратную связь для всего процесса.
Описание Архитектуры предприятия связано с большим количеством информации, которая поступает из различных источников и имеет различные форматы: текст, графические модели и пр. Кроме того, с этой информацией должно работать достаточно большое количество людей. Различные модели определенным образом связаны между собой, и эти связи необходимо также отслеживать для того, чтобы имелась возможность достаточно эффективного анализа архитектуры предприятия и влияния принимаемых решений.
Некоторые организации вполне могут обходиться без специализированных средств разработки архитектуры, ограничиваясь использованием графических пакетов типа Microsoft Visio для построения различных типов моделей (благо в этом пакете имеется для этого огромное количество шаблонов, от конструкций языка UML до шаблонов описания организационных структур, потоков работ и описания унаследованных приложений), а также использованием текстовых редакторов и электронных таблиц.
Однако по мере того, как количество различных артефактов (документов, моделей), создаваемых в процессе работы над архитектурой, растет, становится понятно, что использование только этих "подручных" средств приводит к потере качества, потере связей между артефактами и целостности описания архитектуры.
Для удовлетворения этих специфических потребностей в обеспечении архитектурного процесса появился целый класс программных продуктов. Перечислим названия некоторых компаний-разработчиков таких систем, многие из которых, за исключением последней, практически неизвестны на российском рынке: Casewise, Computas, Framework Software, Popkin Software, Proforma, Ptech, Rational Software.
(рис 12.2) Источники информации для систем разработки Архитектуры предприятияНе описывая и не сравнивая различные системы, которые могут использоваться для разработки архитектуры предприятия, опишем основной функционал, который они могут предоставлять.
Различные планы, модели и документы, связанные с архитектурой, должны быть помещены в репозитории (специальной базе данных, созданной для хранения многих типов документов и диаграмм). Между ними должны быть установлены необходимые связи. При этом различные группы пользователей рассматривают различные категории информации и представления одной и той же архитектуры предприятия. Бизнес-менеджеров, например, больше будут интересовать диаграммы с информацией о бизнес-процессах. Менеджеров ИТ будут интересовать прикладные системы, связанные с этими бизнес-процессами, а на более глубоком уровне анализа их могут интересовать диаграммы, описывающие внутреннюю архитектуру этих систем. Если архитектура документирована с достаточной степенью детализации, появляется возможность отслеживания влияния возможных изменений. Репозиторий может содержать, например, информацию о сотрудниках и затратах. При этом появляется возможность анализировать влияние изменений в бизнес-процессах на стоимость их выполнения. Эти средства должны обеспечивать хранение артефактов в репозитории в соответствии с принятыми методиками описания архитектуры, такими, например, как модель Захмана; и чем большее количество методик выбранное средство поддерживает, тем больше возможностей выбора у пользователей.
При этом многие модели и иная связанная с архитектурой предприятия информация, в любом случае, создается и будет создаваться с использованием других программных продуктов и инструментальных средств, поэтому средства разработки архитектуры предприятия должны иметь возможность использования внешних источников информации, некоторые из которых показаны на рис. 12.2.
(рис 12.3) Принципы работы систем поддержки процесса разработки архитектурыПеречислим более детально набор возможных функций систем разработки архитектуры предприятия:
В идеале, это должен быть двунаправленный процесс. Например, модели бизнес-процессов могут быть уже подготовлены с помощью пакета
Рисунок 12.3 схематично показывает связи между интерфейсом, который дает представление описаний архитектуры в соответствии с выбранной методикой, диаграммами, моделями и документами различных поддерживаемых форматов, репозиторием и
Согласитесь, что это достаточно обширный список функциональных возможностей, которые обеспечивают эти системы и которые в действительности могут потребоваться на различных этапах работы над архитектурой предприятия. Поэтому в достаточно сложных архитектурных проектах их использование может оказать существенную помощь. Однако при выборе поставщиков таких систем следует иметь в виду, что рынок этих систем сам по себе достаточно молодой и не вполне сформировавшийся, поэтому возможны быстрые изменения в списке компаний-участников и доступности тех или иных инструментальных средств.
Мы уже отмечали ранее необходимость постоянного мониторинга тенденций развития ИТ, чтобы обеспечить постоянное соответствие информационных систем предприятия требованиям бизнеса и иметь возможности для получения конкурентного преимущества. Для решения этой задачи специалисты Gartner [6.31] рекомендуют создавать специализированную группу новых технологий. Подчеркнем, что речь идет, прежде всего, о частной задаче мониторинга технологий для развития информационных систем – то есть, работа этой группы не подменяет деятельность департамента исследований и разработок, занятого развитием основного бизнеса компании.
В задачи этой группы входят: определение интересующей компанию области, отслеживание новых продуктов и технологий в данной области, ранжирование или приоритезация потенциальных продуктов-кандидатов, практическая оценка, "просвещение" пользователей в организации о достигаемых преимуществах и, наконец, собственно внедрение. Отметим, что определение интересующей компанию фокус-области должно проводиться как бы "c разных сторон" – прежде всего c учетом стратегических целей компании, которые могут быть прослежены до технологических областей, а также наоборот – отталкиваясь от пожеланий бизнес-подразделений. Еще одним важным аспектом является включение в фокус-область тех технологий, которые в данный момент не используются в бизнесе компании, но могут быть полезны при его функциональном расширении.
Группа, занимающаяся оценкой технологий, как правило, невелика по численному составу и может насчитывать от 2-3 человек в небольших компаниях до 10-12 в крупных холдингах. Интересным решением может стать плановая периодическая ротация ее состава с производственными подразделениями. Такой подход обладает дополнительным преимуществом, так как сотрудник, приходящий или возвращающийся в свое подразделение после работы в группе, эффективно продолжает свою "просветительскую" деятельность, рассказывая об известных решениях. В компаниях типа A и наиболее рыночно-агрессивных компаниях типа B (распределение компаний по группам A, B, C в зависимости от отношения к внедрению новых технологий обсуждалось в лекциях 1 и 2) такая группа обычно входит в состав ИТ-службы, но является выделенной и независимой в том плане, что она подчиняется напрямую
На основании анализа доступной информации по деятельности таких групп в различных организациях специалисты Gartner смогли выделить пять характерных типов "поведения" таких групп. Конечно, на практике встречаются и смешанные характеры, но, как правило, один из типов всегда преобладает. В таблице 12.4 для них приведены типичные характеристики и возникающие проблемы.
| Название | Стиль работы | Проблемы |
|---|---|---|
| Штурманы | Мониторинг и оценка приложений с концентрацией на стратегических направлениях для компании | Не всегда успешная оценка продукта или технологии бывает востребована в подразделении |
| Партизаны | Незаметно помогают бизнес-подразделениям внедрять новые продукты | Нехватка времени для стратегического анализа и мониторинга |
| Проповедники | Рассказывают высшему руководству компании о преимуществах новых технологий и продуктов | Нежелание что-либо проверять самим на практике |
| Проводники | Координируют и направляют усилия других подразделений по оценке технологий | Не всегда достигается практический результат |
| Теоретики (sсholars) | Заняты изучением технологий послезавтрашнего дня | Сложно обеспечить связь с насущными потребностями бизнеса компании |
Относительный объем финансирования такого стратегического мониторинга технологий сильно зависит от масштаба компании и обратно пропорционален доходу, т.е. небольшие компании вынуждены тратить больший процент своего дохода на анализ новых технологий. Для компаний с доходом до $100 млн. в год средними значениями являются 0,7% от дохода и 7,5% от операционного ИТ-бюджета.
Для государственных организаций проблема применения новых технологий приобретает дополнительную сложность. Вполне объяснимыми причинами того служат:
Результатом может явиться и является:
В этом случае выходом может являться централизованная деятельность. Например, в рамках проектов "электронного правительства" (например, ФЦП "Электронная Россия") имело бы смысл активизировать процесс накопления экспертизы и знаний в области архитектурных шаблонов, использующих новые технологии, для государственных информационных систем, а также организовать заказные работы для объективного анализа перспективных технологий по отдельным направлениям реализации программы с размещением результатов в свободном, по крайней мере, для государственных организаций, доступе.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.