Базовые принципы построения Архитектуры

Комплексная автоматизация функции управления требует создания единого информационного пространства на любом современном предприятии, в котором обычные сотрудники и руководство смогут осуществлять свою деятельность, руководствуясь едиными правилами доступа, представления и обработки информации. Современные методы построения ЕИП предприятия базируются на проведении комплексного реинжиниринга бизнес-процессов, на создании информационно-логической модели и последующей реализации соответствующего программного и информационного обеспечения с использованием новых технологий. Разработка ИТ-архитектуры позволяет ясно представить:

•Какая информация/данные критичны для бизнеса компании и как они организованы;

•Какие приложения будут поддерживать бизнес;

•Смогут ли эти приложения эффективно взаимодействовать между собой и с внешними системами партнеров и поставщиков;

•Соответствуют ли используемые технологии требованиям поддержки бизнес-процессов;

•Достаточно ли обеспечена информационная безопасность систем;

•Смогут ли сотрудники компании получить своевременный доступ к нужным данным из любого необходимого места;

•Какие стандарты должны использоваться при разработке и закупке компонент системы;

Формирование архитектуры производится с использованием распространенных методологий, рамочных моделей (frameworks) описания архитектуры и инструментальных средств моделирования (например, ARIS IT Architect) – с учетом имеющихся у Заказчика опыта и предпочтений. В ходе проекта формируется набор архитектурных принципов, определяются используемые и перспективные стандарты и разрабатываются модели архитектуры в целом и ее отдельных областей (приложения, данные, интеграция, техническая инфраструктура, безопасность и др.). Примерный порядок построения единого информационного пространства предприятия следующий:

•Обследование предприятия

°Цели и основные задачи:

°Четкое определение задач и целей проекта;

°Формулирование функционально-технических требований к проекту;

°Инфраструктурный аудит ИТ-системы предприятия для проектирования архитектуры решения;

°Формализация существующих на предприятии бизнес-процессов, автоматизируемых в рамках проекта;

°Получение данных для обоснования количества лицензий;

°Оценка ресурсов, которые потребуются для реализации проекта;

°Оценка рисков проекта;

°Разработка предварительного плана проекта, графика работ и спецификации поставок по каждому этапу и проекту в целом.

•Результаты обследования:

°Отчет с фиксацией ситуации в виде «Как есть»;

°Предложение по созданию информационной системы в виде «Как необходимо»;

°Предложение по «Функционально-техническим требованиям к проекту»;

°План реализации проекта;

°Оценка рисков проекта и предложения по их минимизации;

°Ориентировочная стоимость пилотного проекта и конечного решения.

•Поставка необходимых предприятию аппаратного обеспечения и функциональных решений по автоматизации подразделений:

°Адаптация и настройка базовых, при необходимости разработка новых решений в соответствии с функционально-техническими требованиями, полученными на этапе обследования;

°Развертывание платформы с базовыми сервисами обработки и хранения документов;

°Опытная эксплуатация решения;

°Интеграция с ERP-системой;

°Ввод системы в промышленную эксплуатацию.

•Обучение технического персонала и пользователей.

•Обеспечение дополнительного функционала – работы, выделенные на этапе обследования в отдельные этапы.

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

Модель Архитектуры Предприятия можно разделить на несколько ключевых уровней (категорий):

• Архитектура бизнеса – содержит стратегию компании, подход к управлению, организационную структуру и ключевые бизнес процессы.

• Архитектура информационных систем – описывает, как устроены или будут устроены информационные системы компании. Архитектура информационных систем может быть разбита на две подгруппы:

• Архитектура приложений – показывает бизнес приложения, развернутые в компании, их взаимодействие друг с другом, а также их связь с бизнес процессами компании

• Архитектура данных – содержит описание логической и физической структуры данных компании, а также подход и средства управления данными.

• Техническая архитектура – описывает программное обеспечение и оборудование, которое необходимо для развертывания бизнес сервисов, данные и приложения, ИТ инфраструктуру, сервера приложений, сети, телекоммуникации, стандарты и т. д.

Следующим уровнем иерархии может быть по:

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

•Архитектура сегмента. Это архитектура направления деятельности компании, программы проектов или отдельного подразделения. Таких сегментов у компании будет несколько. На этом уровне вы погружаетесь в специфические особенности и требования конкретного подразделения, функции или компании в составе организации. Прорабатываете бизнес кейсы использования ИТ с руководством подразделения. Архитектура сегмента должна иметь ту же структуру и общие сервисы, что и стратегическая архитектура.

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

Уровни зрелости ИТ

В процессе роста и развития организации, департамент ИТ также проходит несколько этапов своего развития. При построении Архитектуры Предприятия следует принимать во внимание уровень зрелости организации в целом, так и ИТ в частности. Можно выделить следующие этапы и симптомы состояния ИТ департамента:

Начальный или «локализация»

В компании быстро разрабатывают или закупают информационные системы, которые дают ценность отдельным бизнес подразделением или функциям. Основные симптомы данного этапа развития:

•Роль ИТ департамента – второстепенная

•Стратегия ИТ департамента – отсутствует

•Бюджет ИТ департамента – отсутствует

•Тип деятельности ИТ департамента – пассивный, только по запросу.

•Задачи менеджмента – максимальная экономия

•Место в организационной структуре компании – служба в составе бизнес департамента (администрация, финансы)

Развития или «стандартизация»

Компания переходит от закрытия потребностей отдельных бизнес подразделений или функций и повышает эффективность ИТ за счет стандартизации технологий и инфраструктуры. Основные симптомы данного этапа развития:

•Роль ИТ департамента – не стратегический ресурс

•Стратегия ИТ департамента – отсутствует или на начальном уровне

•Бюджет ИТ департамента – отсутствует или управляемый со стороны

•Тип деятельности ИТ департамента – слабо активный по ИТ инфраструктуре и пассивный, только по запросу для бизнеса

•Задачи менеджмента – минимальные инвестиции

•Место в организационной структуре компании – служба или отдел в составе бизнес департамента (администрация, финансы) или под курацией.

Становления или «оптимизация»

Компания строит сквозные бизнес процессы, используя общие данные и информационные системы. Централизует по возможности бизнес процессы и функции подразделений в централизованных информационных системах по предварительно описанных операционных моделях. Основные симптомы данного этапа развития:

•Роль ИТ департамента – важная

•Стратегия ИТ департамента – частично отвечает бизнес требованиям

•Бюджет ИТ департамента – существует и управляем

•Тип деятельности ИТ департамента – реактивная реакция на бизнес требования,

•Задачи менеджмента – получение бизнес выгоды в краткосрочной перспективе

•Место в организационной структуре компании – выделенный департамент, но ИТ менеджер не входит в состав совета директоров.

Зрелый

Повторное использование имеющихся бизнес процессов и компонентов для создания новых сервисов и возможностей. ИТ работает на опережение и является не отъемлющей частью бизнеса. Основные симптомы данного этапа развития:

•Роль ИТ департамента – стратегический ресурс организации

•Стратегия ИТ департамента – интегрированная в бизнес стратегию компании

•Бюджет ИТ департамента – существует и рассматривается как инвестиции в бизнес

•Тип деятельности ИТ департамента – активная реакция (превентивная) на бизнес требования

•Задачи менеджмента – долгосрочные инвестиции в бизнес

•Место в организационной структуре компании – департамент, ИТ директор в составе совета директоров

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

•Проблемы поддержки роста и изменений бизнеса

•Дублирование бизнес процессов

•Многообразие платформ и систем

•Неудовлетворенность текущем состоянием ИТ

Критерии выбора методологии

Так как методологии сильно отличаются друг от друга, то следует задать критерии для их сравнения.

• Полнота таксономии, определяет, насколько методология пригодна для классификации различных архитектурных артефактов. Полностью сосредоточена на фреймворке Захмана.

• Полнота процесса, определяет, насколько детально представлен процесс создания архитектуры предприятия.

• Руководство по эталонным моделям, определяет полезность методологии в создании адекватного набора эталонных моделей. На этом практически полностью сосредоточена методология FEA.

• Практическое руководство определяет, насколько методология позволяет воплотить в жизнь умозрительное представление об архитектуре предприятия и сформировать культуру, в которой эта архитектура будет использоваться. На этом практически полностью сосредоточена методология Gartner.

• Модель готовности определяет, насколько методология позволяет оценить эффективность использования архитектуры предприятия в различных подразделениях.

• Ориентированность на бизнес определяет, ориентирована ли методология на использование технологии для повышения ценности бизнеса, где ценность бизнеса определяется как снижение затрат или увеличение доходов.

• Руководство по управлению определяет, насколько методология полезна в понимании и создании эффективной модели управления для архитектуры предприятия.

• Руководство по разбиению определяет полезность методологии в эффективном разбиении предприятия на отделы, что весьма важно при управлении сложностью.

• Наличие каталога определяет, насколько эффективно методология позволяет создать каталог архитектурных активов, которые можно будет использовать в дальнейшем.

• Нейтральность по отношению к поставщикам услуг определяет вероятность того, что при внедрении методологии вы окажетесь привязанными к конкретной консалтинговой организации. Высокая оценка означает низкую степень привязки к конкретной организации.

• Доступность информации определяет количество и качество бесплатных или относительно недорогих материалов по данной методологии.

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

Построение Архитектуры Предприятия может быть выполнено с применением различных методов и практик. В данной книге мы вкратце рассмотрим несколько и сфокусируем свое внимание на одной из них:

•«Zahman Framework» – наиболее ранняя и известная методология. Идеально подходит для «классификации» элементов архитектуры.

•«TOGAF (The Open Group Architecture Framework)». Методология получила широкую известность и распространение, во многом за счет открытости. Представляет из себя каркас «построения процессов».

•«Gartner» – методология экспертного анализа с использованием «лучших» практик.

•«FEAF» – методология построения архитектуры, использующая «сервис ориентированный» подход.