В архитектуре ИС происходит переход от компонентной модели к модели, основанной на службах. Логика перехода состоит в том, чтобы распространить объектно-ориентированную парадигму на архитектуру систем.

Часть 2. Архитектура информационных систем
Уже более полувека работа по реализации информационных технологий, ставшая почти искусством, является профессией тысяч и тысяч людей. Сотен тысяч. Что нового ждет их в ближайшие годы?

В предыдущей публикации [1] мы обсуждали, ЧТО должны уметь современные информационные технологии, ЗА СЧЕТ ЧЕГО образуется их потребительская стоимость.

Но когда мы знаем, зачем нам нужен дом, стоит подумать о его архитектуре. Будет ли она соответствовать нашим потребностям, насколько приемлемым окажется то или иное архитектурное решение по духу, целесообразности, по технико-экономическим показателям? Что делать со старыми «строениями»: сносить, перестраивать, ремонтировать, стилизовать под новые или, наоборот, новые стилизовать под старину?

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

Поговорим об архитектуре информационных систем, направлениях и стратегии ее развития, если угодно, о моде в этой области, опираясь на прогнозы авторитетного аналитика ИТ-рынка, компании Gartner [2].

Новые потребности бизнеса — новые требования к ИС

Период освоения обществом и крупными компаниями возможностей Internet как средства повышения эффективности деятельности в разных сферах часто обозначают словосочетанием «новая экономика». Как изменяются требования к ИС в условиях новой экономики? Конечно, многие компании, особенно небольшие и среднего размера, пока вполне удовлетворены системами традиционной архитектуры. Однако мир ИТ меняется очень быстро. По прогнозу Gartner, существенных изменений следует ждать уже к 2005 году.

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

К числу этих требований относятся:

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

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

Налицо явные отличия ИС нового поколения от традиционных систем, касающиеся по крайней мере четырех групп свойств:

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

Очень изменились сами пользователи и методы их доступа к ИС. Прежде всего это касается квалификации пользователей. Сегодня это в основном малоискушенные в вычислительной технике специалисты: продавцы, экономисты, чиновники, «обычные» люди — пользователи банковских, торговых и прочих общедоступных систем. Им нужно заказать товар, заплатить за него, узнать расписание поездов или самолетов, заплатить налоги, управлять домашними приборами. Им хочется сделать это с помощью любого доступного многофункционального устройства: мобильного телефона, карманного компьютера, холодильника и т. п. Хочется передать по телефону голосовое или видеосообщение. ИС должна быть в состоянии выполнить все эти действия интуитивно понятным образом и на том языке, на котором говорит конечный пользователь.

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

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

Современная стратегия развития ИС

В развитии современных ИС можно выявить определенную этапность. Дифференциация бизнеса требует от предприятий поэтапного внедрения по меньшей мере следующих основных технологий (рис. 1):

  • доступ через Web (Web Access), обеспечивающий компании как минимум выход на новые рынки;
  • интеграция Интернет-технологий с другими видами бизнес-систем (E-Business Integration); преимущественно это происходит при создании систем типа В2С и В2В;
  • методы композиции процессов (Process Composition), приводящие к более эффективным и производительным решениям, чем "механистическая" интеграция, проведенная на предыдущем этапе.

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

Для каждого этапа характерны вполне определенные навыки, приобретаемые персоналом компании, уровень информационного обслуживания клиентов и длительность освоения технологий. В международной практике в настоящее время идет активное освоение методов интеграции и создания систем распределенной архитектуры, композиции процессов, а также приемов перепроектирования ИС на базе ряда современных «крупноблочных» технологий, таких как использование технологии Web-служб, порталов и т. п. (Применение новых ИТ в нашей стране обычно отстает примерно на два года от международной практики. Это означает, что отечественные разработчики и интеграторы в настоящее время осваивают методы интеграции электронного бизнеса и композиции процессов. Видимо, это достаточно точная оценка, поскольку число завершенных отечественных проектов, в которых активно использованы технологии J2EE/EJB и XML, пока еще невелико. Тем более незначительно и число ИС, построенных с их применением.)

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

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

По данным Gartner, к 2003 году по меньшей мере 40% предприятий будут в различных формах вовлечены в процесс архитектурного реинжиниринга их базовых прикладных систем по сравнению с 5% в 2000 году.

Технологические инновации: как делать системы

Одним из важнейших показателей современных ИТ является время вывода на рынок. Востребованы те технологии, которые позволяют создавать системы в минимальные сроки. Встречаются утверждения, что в начале эксплуатации ИС менеджеров мало интересуют их нагрузочные характеристики: скорость реакции, время выполнения той или иной задачи. Дескать, эти характеристики могут быть отработаны в ходе эксплуатации — главное, чтобы они не были катастрофически плохи. Создается иллюзия того, что ИС собирается очень быстро — и сразу реализует нужную функциональность; стало быть, время ее вывода на рынок минимально. Появилась даже модель «кликнул — собрал систему». В Gartner считают, что к 2003 году те предприятия, которые не освоили подход «кликнул — собрал систему» и рекомбинантную бизнес-модель, позволяющую быстро «подстроить» соответствующий бизнес-процесс, упустят значительную долю рыночных преимуществ.

Однако такая модель может быть работоспособной, только если составные части новой системы являются достаточно крупными функциональными блоками, оформленными как компоненты (паттерны), а их интерфейсы позволяют легко интегрироваться с использованием типовых элементов инфраструктуры приложений, реализующих стандартизованные протоколы (например, XML, J2EE/EJB, WAP, SOAP и т. д.). Это соображение объясняет движущие факторы и направления развития объектно-ориентированных методов как в проектировании и программировании, так и в плане архитектуры современных ИС.

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

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

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

Рисунок 2. Дезинтеграция разработки приложений: замещение процедур службами

Подобную дезинтеграцию методов разработки приложений характеризует не только разделение труда, но и переход от физического описания системных компонентов к логическому с соответствующим замещением системных процедур (физический уровень) службами (см. рис. 2). Этот процесс активно развивается, апробируется, реализуется и моделируется в разных — не обязательно последовательно поддерживающих объектно-ориентированную парадигму — технологиях и операционных средах, которые уже представлены на рынке (CORBA, DCE MQSeries и др.) или выводятся на него (например, .Net). Системные службы не только организуют выполнение конкретного вызова, но могут реализовать некоторую логическую последовательность системных действий, заданную настройками. В основе корректного выполнения лежит использование службами логического и физического описания ресурсов ИС и набора определенных в ИС системных правил и действий, которые и поддерживаются службами. Относительно простыми действиями являются реализуемые службами протоколы обмена, однако службы могут быть настроены и на сложные системные действия, например на последовательности запуска прикладных программ.

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

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

Новый взгляд на судьбу и архитектуру старых систем

С точки зрения тех, кто отвечает за реализацию нового для предприятия решения, существующие базовые системы — это так называемые наследованные системы (legacy system). Наследованные системы — это ранее сделанные инвестиции. Поэтому вопрос об их замене зачастую рассматривается в контексте последовательных минимальных технологических изменений. Именно идея сохранения инвестиций диктует логику развития ИС предприятий. Директора информационных служб и их руководители понимают, что принципиальная доработка ИС — это значительные инвестиции, которые складываются не только из стоимости программного обеспечения и оборудования. Наследованные системы несут в себе накопленный опыт, отработанные бизнес-процессы. Если ИС начинает сдерживать бизнес, и другие способы не позволяют достигнуть кардинального изменения ситуации, то наиболее приемлемым путем развития ИС является, видимо, их обратный инжиниринг и наращивание функциональности на этой основе. Надо ли заменять наследованные системы или достаточно косметического ремонта? Решать приходится в каждом конкретном случае. Замена обычно требуется тогда, когда другие варианты оказываются значительно дороже.

Чаще всего схема развития наследованных систем состоит из трех этапов (см. рис. 3). Перечислим их в порядке возрастания сложности реализации:

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

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

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

Наиболее сложный вариант — замена существующей системы на новую, собственной разработки или серийную. Такое решение обычно основывается на очень серьезных экономических аргументах. Не имея важных организационно-экономических причин, пользователи редко прибегают к подобным решениям. Весомым аргументом для выбора серийной системы может быть неумение построить собственные сбалансированные бизнес-процессы, а, следовательно, внедрить на предприятии процессы, поддерживаемые в апробированном решении, например SAP R/3, Oracle e-Business Suite и т. п. Сложившаяся новая стратегия развития ИС, описанная в предыдущем разделе, связана скорее с изменениями на рынке и с доступностью на нем целого ряда новых технологий.

Логика принятия решений при этом остается незыблемой: ключевым фактором остается обеспечение возврата на инвестиции.

Прикладные программные системы: взгляд изнутри

У базовых технологий есть пользователи — прежде всего производители прикладных систем, таких как ERP, CRM, SCM и др. Для них наличие эффективных, легкоинтегрируемых, отвечающих современным концепциям базовых технологий — это возможность сосредоточиться на прикладных свойствах создаваемой системы. Разработка прикладного программного обеспечения становится проще, так как подчиняется установленным базовой технологией правилам формирования архитектуры, программирования, определения интерфейсов. Кроме того, не приходится заботиться о программной совместимости с другими средами и системами: эти проблемы, как правило, решены в базовой технологии.

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

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

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

В настоящее время, по мнению Gartner, сложилась группа ведущих поставщиков так называемых платформ электронного бизнеса (e-Business Platform). К их числу относят (не в порядке приоритета) IBM WebSphere, Microsoft .Net, Sun ONE, Iona iPortal, Oracle 9i Application Server, BEA E-Business Platform, HP Bluestone.

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

Порталы. При перепроектировании систем уровня предприятия очень часто возникают потребности в сохранении ряда наследованных систем и упорядочении нормативно-справочной информации: классификаторов, списка услуг, нормативов и т. п. Возникает и ряд потребностей общефирменного характера наподобие разграничения доступа к приложениям и базам данных или накопления корпоративных знаний. Это уже службы более высокого уровня, службы корпоративной системы. Порталы, поставляемые лидерами рынка, содержат эти службы и методики их наполнения. Порталы — мощные средства интеграции приложений предприятий, включая наследованные системы, системы ERP, CRM, SCM, пакеты прикладных программ, и все это в рамках intranet и с доступом из Internet. Развитие корпоративных служб для разработчиков поставляемых серверов приложений является довольно естественным шагом, хотя и достаточно новым. В число лидеров входят уже упоминавшиеся ведущие поставщики серверов приложений — IBM, Oracle, Sun, а также SAP, Sybase, Computer Associates и др. Предприятию, осуществляющему выбор портала, стоит не только сделать оценки, как при выборе сервера приложений, но и понять соотношение желаемого перечня служб и стоимости типового решения. Стоимость порталов существенно зависит от реализованных в них служб. Очевидно, что порталы содержат в своем составе и возможности использования служб и серверов приложений и их интеграции с использованием программного обеспечения промежуточного слоя. Именно технология порталов наиболее близка к модели «кликнул — собрал систему». Остается понять, «куда кликнуть», другими словами, предложить средства быстрой сборки ИС.

Конечно, базовые технологии не решают всех проблем. Остаются нерешенными те задачи интеграции, которые все равно не решить без поставщиков прикладных систем:

  • интеграция на уровне структуры сообщений прикладного уровня;
  • интеграция данных с целью извлечения новой информации, например хранилища данных (Data Warehouse), интеллектуальная поддержка бизнеса (Business Intelligence), разведка данных (Data Mining);
  • управление знаниями (Knowledge Management) организации.

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

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

***

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

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

Литература

[1] Позин Б. А. ИТ будущего: потребности и возможности (часть I) // Директор информационной службы. 2002. № 2.

[2] Gartner Symposium ITXPO 2001, Cannes, France 5-8 November. 2001.

Борис Позин — директор Дирекции программных систем ИК «Сибинтек». PozinBA@sibintek.ru

Поделитесь материалом с коллегами и друзьями