Инспектор
Вы можете этот курс.
Опубликован: 07.05.2007 | Уровень: специалист | Доступ: платный
Лекция 11:
Процесс разработки архитектур: управление и контроль, Gap-анализ, внедрение
Таким образом, условно можно сказать, что существует два типа несоответствий:
- "жесткие" несоответствия, которые связаны, например, с необходимостью замены ряда технологий или внедрения новых;
- "мягкие" несоответствия, например, несоответствие архитектурным принципам или несоответствия между имеющейся и требуемой квалификацией персонала.
После того как найденные несоответствия идентифицированы, должны быть расставлены приоритеты, а затем предложены возможные решения и проекты, которые бы "закрывали" найденные проблемные места. То есть, в конечном итоге, несоответствия "становятся" проектами, реализуемыми ИТ-департаментом и группой управления проектами.
Когда организация впервые выполняет анализ на несоответствия, то не исключено, что количество найденных несоответствий окажется невелико. Это может быть, в частности, связано с тем, что будущее состояние архитектуры еще не определено с достаточной степенью детализации. Возможна и обратная ситуация, когда этот список будет слишком велик. Это признак того, что команда, ответственная за разработку архитектуры, слишком много времени потратила на начальном этапе на анализ будущего состояния (на начальном этапе следовало бы понять существующее положение дел и только в общих чертах – направления развития), либо же это означает, что в организации действительно слишком много проблем.
Со временем, по мере более детальной проработки будущей архитектуры, анализ на несоответствия может выявлять сотни и более проблемных областей. Как обычно, при выборе проектов, решающих эти проблемы, действует правило 80/20, когда 20% возможных проектов решат 80% проблем. При этом необходимо учитывать, что требуются проекты в разных областях (структурные, функциональные, связанные с культурой и процедурами) и что на этапе анализа могут быть выявлены взаимозависимости, когда одни проекты, например, нельзя начинать, не реализовав предварительно другие (например, нельзя внедрять новое приложение, не обновив версию операционной системы на персональных компьютерах пользователей).
Необходимым элементом в проекте развития ИТ-архитектуры является оценка существующего состояния и перспективности использования имеющихся компонент. Рассмотрение элементов ИТ-архитектуры ведется обычно в двух аспектах: а) планирование и управление ИТ-системами, и б) стандарты и общие службы (компоненты).
Аспект планирования и управления включает:
- направление развития ИТ – определяет среднесрочные и перспективные роли ИТ в компании с учетом требований бизнеса и выделенных приоритетов;
- принципы реализации – определяют "правила" рассмотрения, внедрения и последующего управления технологиями;
- динамичность – планирование внедрения технологий должно проводиться с учетом их постоянного совершенствования и появления новых технологий, а также с учетом возможного изменения требований бизнеса.
Аспект стандартизации включает:
- Общие ИТ-службы. Сюда относятся кросс-функциональные и служебные приложения, такие как электронная почта.
- Вычислительная инфраструктура. Корпоративные стандарты на технологии и средства инфраструктуры должны базироваться на применении общепризнанных ИТ-стандартов.
- Элементы архитектуры системы. Эти элементы определяются как для среднесрочных, так и для перспективных стандартов. Каждый такой элемент оценивается с учетом ситуации в отрасли, степени использования в организации, целесообразности исключения из системы в течение перспективного срока (старение) или временного сохранения, целесообразности развития, целесообразности проведения переоценки его роли в будущем для обеспечения динамичности. При определении стратегии обычно выделяются среднесрочный (9-18 месяцев) и перспективный (18-36 месяцев) периоды, хотя на основании результатов аудита могут быть сформулированы и срочные задачи, требующие решения в течение недель и месяцев. Вид такой типовой модели для каждой отдельной компоненты ИТ-системы (такой как, например, системное ПО, серверы, средства хранения данных, приложения для компании в целом или для отдельного направления бизнеса и т. п.) приведен в табл. 11.2.
| Текущее состояние | Среднесрочный план 9-18 мес. | Перспективный план 18-36 мес. |
|---|---|---|
| Базовая среда – оценка "как есть" | Тактическое внедрение | Стратегическое направление |
| Снятие с эксплуатации | Продолжение эксплуатации | |
| Поддержка и сохранение | Развивающиеся платформы | |
| Следствия | ||
Оценка перспективности развития проводится с учетом:
- стратегии развития, перспективности расширения бизнеса, изменения отношений с клиентами и поставщиками;
- общемировых тенденций развития информационных технологий;
- выбранного направления развития ИТ-технологий в организации и стратегии реализации (срочные, среднесрочные и перспективные этапы).
Такая модель в области системного программного обеспечения для некоторой гипотетической компании может иметь вид, показанный в табл. 11.3.
В данном случае, на основании анализа существующей системы могло быть выявлено, например, следующее:
- большое количество эксплуатируемых приложений, использующих форматы DBF, FoxPro и MS SQL Server версии 7;
- корпоративная электронная почта отсутствует, например, пользователи используют почтовые ящики на общедоступных публичных серверах;
- большое количество версий эксплуатируемых операционных систем, в том числе устаревших и т.п.
В рамках проекта развития информационных систем организация может принять ряд решений, в том числе:
- переход в ближайшее время на Windows XP;
- внедрение корпоративной электронной почты MS Exchange/Outlook;
- в качестве целевой платформы СУБД и серверов приложений выбран Oracle – то есть новые приложения будут использовать СУБД Oracle, а в перспективе будут реализованы с поддержкой J2EE и выполняться на Oracle AS. В то же время существующие приложения, использующие MS SQL Server, будут сохранены;
- в течение ограниченного времени будет поддерживаться и формат DBF для обеспечения интеграции с унаследованными приложениями;
- организация будет периодически возвращаться к переоценке целесообразности использования среды .Net и J2EE – возможно, что выбор .Net приведет к необходимости изменения архитектуры, предполагающей ориентацию на Oracle и J2EE;
- организация может отметить для себя ряд последствий, в частности, необходимость переоснащения современными рабочими станциями и развития телекоммуникационных средств. Эти связи отражаются в модели развития технического обеспечения информационных систем.
