В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
Валерий Андреев
Директор по науке и развитию компании ИВК
Сегодня в отношении сетецен-тричных корпоративных решений стало очень сложно использовать такое устоявшееся понятие как "ИТ-платформа". Что это? К чему она относится? К программной или аппаратной части современных сетецентричных автоматизированных систем (АС)? Территориальная распределенность современных АС добавляет в общую картину такой элемент нестабильности, что впору говорить об ИТ-ландшафте для подобных систем, который "накрывает" всю АС и является основой для построения ее связной инфраструктуры. Поэтому вопрос выбора дизайна для ИТ-ландшафта оставался бы открытым по сей день, если бы он не решал основной и самой главной задачи по построению ИТ-инфраструктуры АС - интеграции разнородных ресурсов для обеспечения их оперативного управления.
Время жизни и развитие системы
В последнее время важное значение в этом процессе стала приобретать временная составляющая АС, а точнее, ее срок жизни. Конечно, никто не собирается жить вечно, но и "временщикам" сегодня не по себе, поэтому вопрос большого (годы, даже десятилетия!) времени жизни актуальной АС становится обыденным, а в отношении государственных АС (ГАС) просто непременным требованием в техническом задании.
Помимо информационной безопасности, реализация которой в территориально распределенных АС является важнейшей в организационном плане и сложнейшей с технической точки зрения задачей, на первый план сегодня выходят также вопросы развития, а точнее, вопросы ускоренного развития АС. Оно должно предусматривать, что созданные на этапе проектирования рабочие модули всего через пару лет на этапе развертывания системы уже становятся "унаследованными", а еще через несколько лет их приходится переписывать (портировать, модернизировать, удалять и пр.) по причине морального устаревания. Это нормальный процесс, который присущ многим информационным системам, в особенности нынешним ERP и прочим системам. Для того чтобы этим не заниматься, заказчик возлагает на себя сомнительное удовольствие модернизации, проводя ее собственными силами и растягивая процесс во времени. Это и называется "оставить заказчика один на один с не полностью отчуждаемым решением".
Здесь заказчик часто находит другой путь: интегрировать уже поддерживаемые им "унаследованные" локальные (лоскутные) решения - все равно решать задачу интеграции необходимо. Такая интеграция останавливается обычно на банальном "человеческом факторе", когда каждый объект ИТ-ландшафта имеет группу должностных лиц, занимающихся подготовкой и рассылкой согласованных данных, используя при этом офисные возможности программной платформы Windows и имеющиеся средства доставки, в основном средства электронной почты того же производителя. Разумеется, все те ограничения, которые присущи названной программной платформе, тут же начинают работать против заказчика, усложняя проблему интеграции многократно, решая, правда, проблему занятости и приводя к тотальному дефициту квалифицированных кадров.
В любом случае, обсуждаемые шаги приводят ИТ-рынок в состояние полной готовности: по причине существенной выраженности территориальной составляющей "одной шестой суши" любой подобный информационный проект становится и крупным и разнородным.
ИТ-архитектура
И все-таки сегодня уже ясно, что решение проблемы упорядочения ИТ-ландшафта и интеграции разнородных территориально распределенных ресурсов имеется - это выбор современного архитектурного решения для построения единой ИТ-инфраструктуры любого предприятия, распределенного по некоторой территории. Использование такого статичного понятия как "архитектура", почему-то ассоциирующегося у многих с бетоном и арматурой, для такого динамичного по своей природе образования, как АС, вполне оправданно. В силу того, что любая АС осуществляет некоторый единый вычислительный процесс в интересах его потребителей - должностных лиц или процессов предприятия (организации, учреждения и пр.), возможности для его реализации должны быть заложены в архитектуру АС изначально.
Напомним, что по определению АС представляет собой организационно-технический комплекс, обеспечивающий выработку решений на основе автоматизации информационных процессов в различных сферах деятельности (управление, проектирование, производство и т.д.) или их сочетаниях. Для этого АС реализует свое функциональное предназначение на базе некоторой информационной технологии в виде определенной последовательности информационно-связанных функций, задач или процедур (процессов), выполняемых в автоматизированном или автоматическом режимах. Вообще, как известно, АС создаются для решения:
- задач контроля и оперативного управления;
- производственных и финансово-экономических задач;
- задач вычисления;
- представления и аналитической обработки данных;
- задач информационного взаимодействия и пр.
Как видим, предназначений АС может быть много, а вот обеспечивающих механизмов мало, они являются прямым следствием тех возможностей, которые нам отпустила природа при работе с информацией - генерация, сбор, хранение, обработка, передача, защита и удаление. Отсюда вытекают методы решения задач, использующиеся в АС:
- генерация данных;
- сбор оперативной информации;
- создание хранилищ данных;
- систематизация и обработка данных;
- организация защищенного доступа к информационным ресурсам и ряд других.
Что такое ИТ-ландшафт
Если далее рассматривать ИТ-ландшафт любого достаточно крупного предприятия, то мы увидим сложный комплекс различных прикладных систем, которые практически в полном объеме относятся к категории "унаследованных", а также программных и аппаратных платформ разных производителей, объединенных к тому же локальными сетями разной структуры и часто подключенных к сети Интернет. Назвать все это "ИТ-платформой предприятия" даже при условии функционирования ее на программной платформе Microsoft с учетом человеческого фактора никак нельзя. Это образование также не является ИТ-инфраструктурой. Но вот что можно отметить совершенно уверенно, так это зависимость эффективности бизнеса предприятия от эффективности работы такого ИТ-ландшафта. В последнее время все чаще говорится о том, что бизнес не может существовать без ИТ-ландшафта, ведь вся бизнес-логика (логика управления в общем случае) сосредоточена в приложениях, которые исполняются на вычислителях (аппаратных платформах, серверах и пр.) и взаимодействуют с должностными лицами посредством настольных систем.
Поэтому стремление предприятий повышать свою конкурентоспособность, оперативно реагировать на изменения обстановки, желание первых лиц принимать своевременные и верные решения (в том числе и в режиме реального времени), обеспечивать выживаемость и возможности для развития - все это находится в самой тесной взаимосвязи с возможностями корпоративного ИТ-ландшафта. Сегодня необходимо, чтобы он сам был способен гибко адаптироваться к требованиям управления, не являлся чрезмерно сложным, извлекал максимум возможного из существующих "унаследованных" систем, мог сокращать затраты времени и средств на разработку нового, был открытым и модульным. Это непременные условия для поддержания гибкости и оперативности управления той инфраструктурой, которая должна еще образоваться на ИТ-ландшафте. Возможность не только реагировать на изменения технологий, но и извлекать из них важные функциональные преимущества вряд ли достижима без необходимости известной динамики ИТ-ландшафта на фоне реализации задач интеграции приложений.
Именно сложности интеграции приложений значительно ограничивают возможность создания гибкой, динамичной ИТ-инфраструктуры предприятия, которая эти прикладные процессы и должна обслуживать.
Решения для интеграции
Существуют различные классы программных решений для интеграции приложений, но большинство из них (даже те, которые наиболее близки по своим принципам к современным подходам) имеют ряд общих недостатков. Это, прежде всего, реализация принципа "сильной связанности" (tightly coupled), когда механизмы интеграции привязаны к коду интегрируемых приложений, в результате чего изменения в одном из них потребуют модификации других. Разнообразие способов интеграции, отсутствие стандарта, который удовлетворил бы приложения любых типов, приводят к необходимости специального программирования интеграционных интерфейсов (адаптеров) для каждой пары взаимодействующих прикладных систем. И если кто-то скажет, что это совсем "не бином Ньютона", то будет и прав и не прав одновременно. Потому что как раз это и есть бином Ньютона, определяющий число попарных сочетаний и растущий квадратично от числа интегрируемых сущностей. Реализация указанного принципа возможна лишь на узком круге неизменных приложений, расширение которого приводит к катастрофическим трудозатратам.
Кроме того, воплощение указанного принципа приводит к фактическому узакониванию функциональной избыточности, реализованной практически в каждом приложении. Так как многие разработчики включают в свои решения и средства защиты информации, и средства доставки, и авторизацию и прочие механизмы, которые относятся к инфраструктурным, и, следовательно, они должны обрабатываться именно элементами ИТ-инфраструктуры, а не прикладными процессами. Отрыв "прикладной зоны" от инфраструктурной - тенденция сегодняшнего дня, направленная, прежде всего, на упрощение управления процессами в АС, а также на увеличение производительности приложений в сетецентричных решениях.
Именно поэтому сегодня назрела необходимость формулирования более глубокого (архитектурного) подхода в решении задач интеграции, чем просто стандартизация известных механизмов и техник. Так же как и при комплексном решении задач ИБ в АС, мы утверждаем, что изменение архитектуры существующих АС и внедрение концепции SO A (Service-Oriented Architecture) позволит создать такую ИТ-инфраструктуру, которая обеспечит быструю консолидацию и реконфигурацию распределенных программных компонентов для поддержки бизнес-процессов в их постоянной динамике. Таким образом, основой "ландшафтного дизайна" АС сегодня является сетецентричная концепция SO А, предусматривающая создание территориально распределенных прикладных систем, в которых исполняемые функции рассматриваются как службы (сервисы), доступные в сети. А вот это уже совсем не бином Ньютона, так как независимые, выделенные элементы системы (службы, сервисы) слабо связаны (loosely coupled) между собой. Их задача - гарантированно вернуть результат в соответствии с исходными данными и реализацией прикладной составляющей сервиса. С одной стороны, это чрезвычайно сильно повышает гибкость системы, но с другой - существенно затрудняет управление всей системой в целом и в особенности управление безопасностью, так как в данном случае вся логика исполнения заложена именно в сервисах. И тот, кто управляет сервисами, владеет, по сути, всей информацией в системе.
Новый подход к сервису
По сравнению с техниками, реализующими принцип "сильной связанности", новый подход - это практически парадигма, являющаяся сегодня реальной новацией в построении АС и практически не имеющая альтернатив в будущем.
Напомним, что в качестве сервиса в SO А может выступать как приложение целиком, так и отдельные его функциональные модули. Сервисами могут быть прикладные функции, реализующие определенную логику исполнения, бизнес-транзакции, состоящие из нескольких функций более низкого уровня, и системные функции, отражающие специфику различных программных платформ. Взаимодействуя по сети в определенной последовательности, сервисы позволяют реализовать тот или иной бизнес-процесс.
Остается сделать совсем немного -добиться универсальности в реализации сервиса и в его взаимодействии с прочими сервисами в разнородной ИТ-инфраструктуре. Здесь также существуют разные подходы: оставаться в рамках выбранной для создания АС интеграционной платформы, используя ее API, либо работать с интерфейсами, нейтральными по отношению к специфике реализации сервисов, которая накладывается в результате учета особенностей функционирования ИТ-ландшафта, либо использовать стандартизованные интерфейсы, имеющиеся в интеграционной платформе. В каждом случае есть свои плюсы и минусы, например, упрощение использования может сузить функционал, или ориентация на стандартные интерфейсы и протоколы может усугубить разнородность ИТ-инфраструктуры и т.д. Сегодня существует, по крайней мере, одна стандартизованная реализация SOA-архитектуры, ориентированная на стандарты Web-сервисов -интерфейсов и протоколов межсервисного взаимодействия.
Но SOA и Web-сервисы - это далеко не одно и то же, хотя нас нередко и пытаются убедить в обратном. Web-сервисы - это лишь одна из возможных реализаций, активно пропагандируемая в связке с программной платформой Microsoft. Можно найти много общего между SO А, с одной стороны, и моделями Common Object Request Broker Architecture (CORBA) и Microsoft Distributed Component Object Model (DCOM) - с другой, вот только в них опять присутствует принцип "сильной связанности".
Что же выбрать?
В любом случае выбор предлагаемого дизайна всегда остается за заказчиком, для которого важны не только решение задачи интеграции как таковой, но и ресурсы, которые для этого необходимо потратить. Поскольку концепция SOA и решения, ее реализующие, находятся на пути становления, то стандартных путей, а следовательно, рекомендуемых цен здесь пока нет. Аналитики отмечают, что стоимость решения колеблется в пределах от нескольких сотен до нескольких тысяч долларов на каждое рабочее место АС. Много это или мало? Если учитывать предполагаемое время жизни создаваемой инфраструктуры и общую стоимость владения, то немного. Вообще, существуют вполне понятные преимущества реализации сетецентричных решений на основе SOA, они делятся на стратегические и тактические.
Стратегические:
- сокращение времени реализации распределенных проектов;Тактические:
- более простые разработка и внедрение приложений;Преимущества SOA
Центральным элементом SOA является корпоративная сервисная шина (Enterprise Service Bus, ESB) или магистраль. ESB - одновременно и среда информационного обмена между сервисами, и контролирующее звено в системе, обеспечивающее реализацию единой политики безопасности сетецентрированной АС. Именно наличие этой шины позволяет реализовать "отрыв" прикладных процессов от инфраструктуры и дать стандартизованные интерфейсы и протоколы функционирования этих процессов как на объектах автоматизации, так и глобально в АС в целом.
IBM, BEA Systems, Progress Software, TIBCO, Microsoft, Oracle включают в свои интеграционные платформы инструменты для реализации принципов SO А. В средах управления ИТ-инфраструктурой от Hewlett-Packard, Computer Associates, IBM, ВМС Software имеются не только средства управления Web-сервисами, но и более комплексные предложения для мониторинга и контроля ресурсов в SO А. Включение в состав платформы SAP продукта NetWeawer подвело черту в сомнениях разработчиков ERP-систем относительно внедрения гибких "шинных" решений в свои монолитные платформы. Куда двигаться? Таким образом, многие пользователи серьезно присматриваются к новой идее, экспериментируя или активно внедряя трехуровневые технологии. Первые реализации и особенно те преимущества, которые обещает комплексный сервис-ориентированный подход, включая гибкость ИТ-инфраструктуры по отношению к любым изменениям, возможность интеграции в единую среду исполнения на единых принципах функционирования существующих ресурсов предприятия и внешних решений, доказывают необходимость движения именно в этом направлении. Ведь в конечном итоге SO А меняет не столько ИТ-ландшафт, сколько принципы взаимодействия бизнеса и ИТ, отношение должностных лиц АС к своим обязанностям, очередной раз доказывая известную мысль профессора Преображенского о разрухе, которая сидит не в клозетах, а в головах.Опубликовано: Журнал "Технологии и средства связи" #3, 2008
Посещений: 25766
Статьи по теме
Автор
| |||
В рубрику "Решения корпоративного класса" | К списку рубрик | К списку авторов | К списку публикаций
