Стратегия развития информационных систем основывается на общей стратегии развития компании (учреждения) и конкретизирует положения общей стратегии с точки зрения ИТ. Общая стратегия развития компании определяет настоящие и будущие виды деятельности, типы выпускаемой продукции и объёмы выпуска, рынки на которых работает компания и её доли на этих рынках, организационную и территориальную структуру компании. В свою очередь, ИТ-стратегия содержит основные положения использования ИТ в бизнес компания, она определяет как будет поддержана заданная стратегия развития компании средствами ИТ.

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

 

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

Базовые принципы и направления развития ИТ должны быть детализированы до продуктов, например:

• Внедрение комплексного продукта (например, системы класса ERP II) и автоматизация на его основе всех бизнес-процессов.
• Внедрение нескольких специализированных продуктов, каждый из которых решает отдельный класс задач, и создание единой системы посредством интеграции этих продуктов.
• Проведение заказной разработки одной из подсистем и интеграция её с другими продуктами в единую систему.
• Разработка на заказ всей информационной системы в комплексе.
• Автоматизация отдельных участков (или бизнес-процессов) посредством внедрения отдельных модулей, входящих в один или в разные продукты.

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

• Комплексность автоматизации.
• Если не предполагается комплексная автоматизация, то определение направлений деятельности, бизнес-процессов или подразделений, которые будут автоматизироваться.
• Порядок автоматизации, сроки отдельных этапов.
• Выбор используемых продуктов, систем, платформ.
• Применение заказных разработок.
• Используемые методики интеграции.
• Способы реализации проектов (использование услуг сторонних компаний, аутсорсинг, выполнение работ силами собственного подразделения и пр.).
• Способы поддержки основных ИТ-сервисов (традиционный, SLA).

Также как ИТ-стратегия конкретизирует общую стратегию предприятия с точки зрения ИТ, так и ИТ-архитектура рассматривает ИТ-аспекты общей архитектуры предприятия. Определение архитектуры предприятия дано в стандарте ANSI/IEEE Std 1471-2000: «фундаментальная организация системы, реализованная в её компонентах, их взаимоотношениях друг с другом и средой и принципах, определяющих её конструкцию и развитие». Архитектура предприятия – это концептуальное средство, которое помогает организации понять свою структуру и способы работы. Обычно архитектура предприятия имеет форму большого набора взаимосвязанных моделей, описывающих структуру и функции предприятия.

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

Бизнес-ракурс. Бизнес-ракурс описывает бизнес предприятия. Сюда включаются бизнес-стратегии и планы по переводу предприятия из текущего состояния в планируемое состояние в будущем. В типовом случае этот ракурс включает:

• Цели и задачи верхнего уровня.
• Бизнес-процессы, охватывающие всё предприятие или значительную его часть.
• Выполняемые бизнес-функции.
• Основные организационные структуры.
•  Взаимосвязи между всеми перечисленными элементами.

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

Ракурс приложений. Ракурс приложений определяет набор приложений предприятия. Обычно этот ракурс включает:

• Описание приложений или автоматизированных сервисов, поддерживающих бизнес-процессы.
• Описание взаимодействия и взаимозависимостей (интерфейсов) прикладных систем предприятия.
• Планы разработки новых и переработки существующих приложений, основывающиеся на целях и задачах предприятиях, а также на эволюции технологических платформ.

В ракурсе приложений должны быть представлены службы, информация и функциональность, необходимые в масштабах всего предприятия, используемые пользователями различной квалификации, выполняющими разные функции, для достижения общих бизнес-целей.
Ракурс информации. Ракурс информации описывает, какая информация необходима организации для функционирования (выполнения её бизнес процессов). Этот ракурс включает:

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

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

Технологический ракурс. Технологический ракурс рассматривает аппаратное и программное обеспечение, используемое в организации. Этот ракурс включает (но не только):

• Аппаратные средства серверов и рабочих станций.
• Операционные системы.
• Средства сетевого доступа.
• Принтеры.
• Модемы.

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

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

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

Как архитектура приложений, так и технологическая архитектура состоят из концептуального представления, логического представления и физического представления.

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

Логическое представление показывает основные функциональные компоненты и их взаимосвязи внутри системы без определения технических деталей реализации необходимой функциональности. Архитекторы создают модели приложений, которые являются логическим представлением бизнес-моделей, поскольку они определяют как удовлетворить бизнес-цели и бизнес-требования. Модели приложений представляют собой логические представления архитектуры приложений. Архитекторы в данном случае работают с общей структурой приложений. Они решают, как будет отображаться управление данными и шаги бизнес-процессов, они проектируют взаимодействие между компонентами модели в терминах логических сообщений и последовательностей, и они определяют, какие данные и состояния может содержать модель.

Физическое представление – является наименее абстрактным и иллюстрирует специфику реализации компонентов и взаимосвязей между ними. Каждый элемент физического представления реализуется в процессе проектирования и разработки как программный или аппаратный компонент. Каждый элемент модели приложения должен быть поставлен в соответствие элементам реально существующих технологий. Этим способом модели приложений преобразовываются в модели реализации. Часть этих задач выполняется во время традиционной разработки, когда программисты прописывают детальную бизнес-логику в виде программного кода, но множество действий по реализации хорошо классифицируются как действия по применению специализированной среды. Это такая техника разработки, в которой множество элементов инфраструктуры распределённых приложений и управления данными поддерживается специализированной средой, которая расширяет пользовательскую логику приложений и декларативные структуры управления. Применение специализированной среды скрывает от разработчика множество сложностей, например, поддержку асинхронного режима приёма-передачи сообщений, а также позволяет разработчику с невысоким профессиональным уровнем реализовывать сложные проекты.

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

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

Состав работ по разработке ИТ-стратегии и ИТ-архитектуры

Разработка ИТ-стратегии

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

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

В настоящее время для разработки архитектуры приложений используются два подхода:

• Разработка архитектуры на основе интеграции приложений (концепция Enterprise Application Integration – EAI).
• Разработка сервисо-ориентированной архитектуры (Service Oriented Architecture – SOA).

SOA - это новая парадигма проектирования распределенных интегрированных систем. Согласно SOA любые части информационных систем, имеющие функциональность, рассматриваются как службы (service providers, провайдеры служб), которые предоставляют свою функциональность другим частям системы посредством обмена сообщениями. Сервисы обеспечивают бизнес-логику и средства управления состояниями, относящиеся к проблеме, для решения которой они предназначены.

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

Разработка сервисо-ориентированной архитектуры (SOA), что в настоящее время больше применимо при построении системы на основе заказных разработок или при внедрении продуктов, уже построенных на основе принципов SOA.

Разработка сервисо-ориентированной архитектуры (SOA) с преобразованием используемых унаследованных приложений к SOA. В этом случае процесс разработки самой архитектуры аналогичен предыдущему варианту, поэтому мы рассмотрим только этап преобразования используемых унаследованных приложений к SOA.

Разработка архитектуры приложений на основе концепции EAI

Очень укрупнённо, методику разработки архитектуры приложений на основе концепции EAI, в случае, когда осуществляется полное перепроектирование, можно представить следующим образом:

• Обследование предприятия, определение основных функциональных требований к приложениям.
• Выбор базового полнофункционального пакета, удовлетворяющего сформулированным требованиям.
• Проектирование методов интеграции выбранной на этапе 2 базовой системы с уже используемыми унаследованными системами, оценка затрат на интеграцию.
• Определение типов дополнительных систем, которые необходимо будет дополнительно внедрить, чтобы полностью удовлетворить потребности, выявленные на первом шаге. Выбор этих систем.
• Проектирование методов интеграции выбранной на этапе 2 базовой системы с дополнительными системами, определёнными на этапе 4, оценка затрат на интеграцию.
• Если затраты (сроки, деньги) на интеграцию сопоставимы с затратами на внедрение более тяжёлого пакета, необходимо вернуться на этап 2, повторив процесс выбора с анализом более тяжелых систем.
• Определение последовательности внедрения модулей выбранной комплексной системы, внедрения дополнительных систем и интеграции с уже используемыми системами.
• Разработка требований к технологической архитектуре на основе разработанной архитектуры приложений.
• В тех случаях, когда базовый пакет заранее предопределён, или даже уже частично внедрён и не подлежит замене, может проводиться неполный комплекс работ по уточнению или развитию имеющейся архитектуры приложений (этапы 3, 4, 5, 7 или некоторые из них).

Разработка сервисо-ориентированной архитектуры приложений (SOA)

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

• Сервисы. При проектировании сервисов основная задача состоит в том, чтобы эффективно инкапсулировать логику и данные, связанные с процессами в реальном мире. Значительные интеллектуальные усилия требуются для принятия решений, что можно объединить, а что должно быть реализовано отдельными сервисами.
• Сообщения. Сервисы взаимодействуют между собой, обмениваясь сообщениями. Должны быть полностью определены сообщения, которые порождают и принимают сервисы, включая требования к последовательности этих сообщений.
• Контракты. Каждый контракт описывает метод взаимодействия двух сервисов. В это описание входит: перечень посылаемых каждым сервисом сообщений, их форматы, методы отправки, последовательность обмена сообщениями, перечень принимаемых каждым сервисом сообщений и способы приёма.
• Политики. Политики должны давать возможность влиять на работу приложений, т.е. устанавливать и изменять правила, действующие во время выполнения, которые определяют методы работы сервисов и их взаимодействие. Разработка политик в ходе процесса проектирования ведёт к увеличению гибкости и управляемости приложений.
• Состояния. Сервисы управляют состояниями и состояния, часто, являются главной причиной их существования. Состояние – это то, что хранится в некоторой долгосрочной среде, такой как файловая система или база данных. Сервисы гарантируют посредством своей бизнес-логики, содержательность, непротиворечивость и точность сохраняемых состояний. В процессе работы сервисы будут получать запросы от других сервисов, извлекать некоторые состояния из этой среды длительного хранения и строить ответы или корректировать эти состояния.
• Процессы. Каждый процесс управляет последовательностью действий при выполнении некоторой работы, постепенно переводя систему из одного состояния в другое. В сервисо-ориентированной архитектуре должны быть спроектированы бизнес-сервисы, построенные по традиционным принципам, и процессные сервисы, которые будут координировать выполнение бизнес-сервисов.
• Приложения. Приложения объединяют процессные сервисы, бизнес-сервисы и сервисы пользовательских интерфейсов. Бизнес-сервисы обычно проектируются в четыре слоя: сервисы фасада, сервисы бизнес-процессов, сервисы бизнес-сущностей и сервисы представления данных. Такая модель работоспособна как для традиционных типов приложений, которые имеют интерфейс для взаимодействия пользователей с бизнес-сервисами, так и для сервисов, взаимодействующих с другими сервисами.

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

Преобразование унаследованных приложений к сервисо-ориентированной архитектуре (SOA)

Процесс преобразования существующей архитектуры информационных систем в сервисо-ориентрованную архитектуру состоит из семи шагов и представлен схемой на рисунке 1.

увеличить

Рис. 1 Схема процесса преобразования имеющейся архитектуры информационной системы в сервисо-ориентированную архитектуру.

Шаг 1а – Декомпозиция предметной области. Определение бизнес-процессов, подпроцессов, юскейсов.
Шаг 1b – Анализ существующих не объектно-ориентированных систем и преобразование их к компонентной архитектуре.
Шаг 2 – Создание дерева целей сервисной модели для тестирования полноты сервисной модели. Каждой подцели в дальнейшем будет соответствовать определённый сервис.
Шаг 3 – Анализ подсистем – это определение того, какие UML-юскейсы реализуются какими компонентами системы, анализ взаимодействия компонентов и влияния нефункциональных требований на архитектуру системы.
Шаг 4 – Определение, какие компоненты отвечают за какие сервисы., определение сервис-провайдеров и сервис-потребителей.
Шаг 5 – Определение интерфейсов каждого компонента.
Шаг 6 – Структуризация компонентов и сервисов на основе применяемых шаблонов архитектуры.
Шаг 7 – Определение программных и технических средств спомощью которых будет реализован каждый сервис.

Разработка технологической архитектуры

Технологическая архитектура включает в себя следующие компоненты:

• сетевую архитектуру;
• архитектуру хранения;
• архитектуру инфраструктуры приложений;
• архитектуру управления;
• архитектуру безопасности.

Работы по разработке технологической архитектуры должны начинаться с обследования имеющейся ИТ-инфраструктуры предприятия (учреждения) и определения её соответствия требованиям архитектуры приложений. Далее для каждого из перечисленных компонентов технологической архитектуры должны быть выполнены:

• разработка концептуального представления;
• разработка логического представления;
• разработка физического представления.