Введение

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

В качестве информационной системы была выбрана система Oracle, на примере внедрения системы в компанию МТС. ОАО «Мобильные ТелеСистемы» ведущим телекоммуникационным оператором в России и странах СНГ,

Общие сведения

Архитектура информационной системы -концепция, определяющая модель, структуру, выполняемые функции и взаимосвязь компонентов информационной системы.

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

Два основных идеологических определения архитектуры ИС таковы:

• “Архитектура ИС — это набор решений, наиболее существенным образом влияющих на совокупную стоимость владения системой”

•   “Архитектура ИС — это набор ключевых решений, неизменных при изменении бизнес–технологии в рамках бизнес–видения”

Оба эти определения согласованы в том смысле, что если ключевое решение приходится изменять при изменении бизнес–технологии в рамках бизнес–видения, то резко возрастает стоимость владения системой. Следствием этих определений является понимание важности принятия архитектуры системы как стандарта предприятия, ввиду значимости и стабильности архитектурных решений. Еще одно важное следствие первого определения — то, что архитектура системы на самом деле должна строиться на стадии технико–экономического обоснования системы.

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

• что делает система;

• как эти части взаимодействуют;

• где эти части размещены;

• на какие части она разделяется;

Таким образом, архитектура ИС является логическим построением, или моделью. Так же она влияет на совокупную стоимость владения через набор связанных с ней решений по выбору средств реализации, СУБД, операционной платформы, телекоммуникационных средств и т.п. — то есть через то, что мы называем инфраструктурой ИС. Инфраструктура включает решения не только по программному обеспечению, но также и по аппаратному комплексу и организационному обеспечению.

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

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

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

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

Объект автоматизации

В качестве объекта автоматизации рассмотрим компанию МТС. ОАО «Мобильные ТелеСистемы» является ведущим телекоммуникационным оператором в России и странах СНГ. Вместе со своими дочерними предприятиями компания обслуживает более 100 миллионов абонентов. Население всех регионов России, а также Армении, Беларуси, Украины, Узбекистана, Туркменистана, где МТС и ее дочерние предприятия имеют лицензии на оказание услуг в стандарте GSM, составляет более 230 миллионов человек. МТС является одной из компаний – «голубых фишек» российского рынка акций и входит в десятку крупнейших мобильных операторов мира по размеру абонентской базы

Предпосылками к переходу на новую информационную систему послужили следующие требования:

• Обеспечение гибкости и масштабируемости ИТ архитектуры:

  • Компонентная (модульная) архитектура приложений.

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

  • Управляемая и опережающая масштабируемость компонентов ИТ архитектуры.

• Управляемая архитектура данных и интеграционных связей:

  • Наличие и управление корпоративной моделью данных.

  • Переход к сервисно-ориентированной архитектуре (SOA) и использованию стандартных сервисов.

  • Повышение производительности фронт-офиса.

  • Повышение качества обслуживания клиентов.

  • Перенос рутинных операций в автоматизированные каналы обслуживания.

  • Развитие сети отделений и альтернативных каналов продаж.

  • Совершенствование ИТ-платформы и технологий.

  • Масштабируемость компонентов ИТ-архитектуры.

  • Ожидания по росту компании

Пред началом проекта был проведен анализ и оценка текущей архитектуры и бизнес стратегии. После определены узкие места и сформированы варианты подхода к разработке ИС.

После анализа были выделены следующие проблемы:

1. Нет «лучшей» системы - Все приблизительно равны!

2. Лучшие в своем классе системы - трудно интегрировать!

3. Кастомизация продукта – не особенно затратна!

4. Затраты на интеграцию – превышают затраты на кастомизацию!

5. Стоимость владения мультивендорным решением – значительно выше!

6. Основная проблема внедрения – интеграция.

Большой объем даны и пользователей стал большой проблемой. Требовалось, что бы система соответствовала предъявленным требованиям и ее внедрение не повлияло на работы существующей системы, данные не должны были потеряться, а стоимость внедрения не превышала полученного от внедрения эффекта. Так же было отмечено, что созданная система должна поддерживаться и адаптироваться в соответствии с требованиями без больших изменений до 2025-2035 года.

Были разработаны принципы формирования варианта реализации

Вариант 1

«Ориентация на скорость внедрения»

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

Вариант 2

«Ориентация на функционал и гибкость» Использование систем с развитой функциональностью, гибкостью и наибольшими долгосрочными перспективами

Вариант 3

«Ориентация на стратегическое партнерство с одним вендором»

Использование систем, построенных на платформах одного вендора

Вариант 4

«Ориентация на минимальную стоимость владения (TCO)»

Использование систем с наименьшей ТСО, за счет снижения гибкости ИТ архитектуры.

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

Архитектуры решено было строить на основании продуктов Oracle и использовать сервис - ориентированную архитектуру, поскольку данная архитектура обладает следующими преимуществами:

• Быстрое освоение сервис-ориентированной архитектуры (SOA) позволяет расширить возможности служб в ИТ-системах. Однако это только половина дела. Чтобы достичь поставленных целей по развитию ИТ-системы — снижение затрат, увеличение эффективности и повышение заметности, — необходимо быстро объединить эти службы в модульные и гибкие бизнес-приложения. Система Oracle SOA Suite 11g существенно упрощает процесс создания и развертывания SOA, а также управления ею с помощью лучшей в своем классе комплексной, открытой, интегрированной технологии.

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

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

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

Предлагаемые Oracle продукты для SOA и BPM составляют основу Oracle Application Integration Architecture— решения Oracle для быстрой интеграции приложений.