Покорение сложности ИТ

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

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

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

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

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

Возрастание сложности ИТ

Вопрос: каковы источники и формы сложности в современной корпоративной вычислительной среде?

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

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

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

Давление администрации. ИТ-отделы находятся под постоянным давлением, вынуждающим их как можно быстрее достигать большего с меньшими затратами. Синдром «больше, быстрее, дешевле», естественно, ведет к появлению плохо спланированных, второпях спроектированных и недоделанных систем.

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

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

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

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

«Оппортунистические» связи

Стратегический прогноз: к 2010 году более 30% новых приложений не будут иметь достаточной способности к интеграции, обеспечивающей их многократное использование (вероятность 0,7).

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

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

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

Решение проблемы унаследованных систем начинается с изменения отношения к ним и к ИТ в целом. Это означает признание следующих фактов:

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

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

Неодолимая тяга к инновациям

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

В модели жизненного цикла, предложенной аналитической компанией Gartner (рис. 1), технологии, находящиеся на «плато продуктивности», надежны и вполне понятны, а их стоимость, достоинства и недостатки легко поддаются прогнозированию. Однако выгоды от этих технологий общеизвестны, поэтому их продажи не дают особых конкурентных преимуществ. Напротив, новые технологии, расположенные в области «пика раздутых ожиданий», обычно малопонятны и страдают от недостатка инструментальных средств, некомпетентности и плохого качества реализации. Однако они обещают инновационную дифференциацию, которая для многих предпринимателей является не менее существенной, чем стабильность их основных систем.

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

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

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

Синдром «больше, быстрее, дешевле»

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

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

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

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

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

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

Важность признания сложности ИТ

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

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

Рекомендации. Изучите прошлое своей ИТ-среды и примите как должное исторически сложившиеся ИТ-ресурсы.

Передовые принципы проектирования программ

Вопрос: как принципы проектирования программного обеспечения помогают справиться со сложностью ИТ?

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

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

принцип «черного ящика» — инкапсулируй;
принцип «луковицы» — расслаивай и специализируйся;
«коммунальный» принцип — уважай и объединяйся;
принцип «городского планирования» — формируй составные приложения.

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

Принцип «черного ящика»

Стратегические прогнозы: к 2010 году модульность сервисов будет диктоваться как процессами, так и данными (вероятность 0,8); с 2005-го по 2010 год доля новых бизнес-компонентов, находящихся в третьей «нормальной» форме, увеличится с 10 до 30% (вероятность 0,7).

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

Не все виды инкапсуляции одинаково хороши. Большая глубина инкапсуляции и изоляции повышает эффективность общей архитектуры, но требует больших инвестиций и усилий по внедрению. Различные уровни программной инкапсуляции описаны в пяти «нормальных» формах (рис. 3). Все они полезны, но для достижения более высоких уровней требуется сначала пройти через нижние.

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

Вторая «нормальная» форма предполагает, что интерфейс представляет одну и только одну законченную бизнес-функцию. Законченность бизнес-функции — понятие относительное, и интерфейс может иметь несколько точек входа. Тем не менее определение интерфейса во второй форме гарантирует его четкую дифференциацию от других, а также логическое обоснование объединения в одном интерфейсе конкретного набора точек входа. Не накладывается каких-либо ограничений ни на характер выдаваемых данных, ни на способ их обработки.

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

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

Наконец, пятая «нормальная» форма делает принадлежащие компоненту данные «непрозрачными» — вне компонента структура данных неизвестна. Даже метод долговременного хранения данных (если таковой используется) не известен за пределами компонента. Различные компоненты получают и хранят данные в разных формах и используют разные технологии, наилучшим образом отвечающие семантической природе этих данных. Долговременное хранилище непосредственно не доступно для семантического анализа и, таким образом, приобретает ранг средства резервного копирования. Основные оперативные данные всегда находятся внутри компонента. Возрастающая степень нормализации требует, чтобы структуры процессов и данных были тесно увязаны и, в конечном счете, превратились в единое целое. Основными становятся данные интерфейса, а не сохраненная запись, как практикуется сегодня. Компоненты в пятой нормальной форме инкапсуляции являются объектами. Такая степень инкапсуляции достигается редко — если вообще достигается.

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

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

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

Принцип «луковицы»

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

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

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

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

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

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

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

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

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

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

«Коммунальный» принцип

Стратегический прогноз: к 2010 году 80% крупных и средних предприятий будут использовать специализированную программную инфраструктуру промежуточного слоя для всесторонней интеграции приложений, устанавливая необходимые взаимосвязи при сохранении независимости своих приложений (вероятность 0,7).

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

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

«Нервная система» предприятия (Enterprise Nervous System, ENS) — инфраструктура, облегчающая взаимодействие и семантическую интеграцию без неуместных претензий к внутренней структуре приложений-участников (рис. 5). Как только требования к ENS установлены, инженерные группы в различных прикладных областях свободны следовать собственным взглядам на архитектуру ИТ. Взаимозависимость, достигаемая посредством ENS, гарантирует сохранение автономии отдельных приложений и прикладных областей. ENS управляет сложностью корпоративной ИТ-инфраструктуры, допуская изоляцию и независимое управление приложениями или прикладными областями, но устанавливая определенный уровень совместного использования данных и семантической согласованности этих приложений.

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

Принцип «городского планирования»

Стратегический прогноз: с 2005 по 2010 годы доля новых прикладных проектов, ориентированных на интегрированную компонуемую модель предприятия, возрастет с 5 до 40% (вероятность 0,7).

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

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

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

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

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

Прогрессивные тенденции

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

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

SOA: выгода зависит от инвестиций

Сервис-ориентированная архитектура (Service-Oriented Architecture, SOA) обещает многие потенциальные выгоды, в том числе уменьшение сложности. Однако степень реализации этого обещания напрямую зависит от объема затраченных средств. Термином SOA сегодня обозначают самые разные варианты технологий. Одни отождествляют SOA с Web-сервисами, другие приравнивают к распределенным вычислениям или к интеграции событий и сервисов. Дебаты вокруг данного термина, на первый взгляд, кажутся академическими, но от того, какую позицию вы займете, зависит, что именно ваше предприятия получит от инициативы SOA (рис. 7).

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

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

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

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

Рекомендации. Для получения максимальной отдачи от инвестиций в SOA рассматривайте ее как долгосрочную программную архитектуру и инженерную практику, а не как простую реализацию Web-сервисов.

Интегрированный репозиторий

Стратегические прогнозы: к 2010 году интегрированный репозиторий станет центральным элементом всех ведущих прикладных платформ (вероятность 0,7); к 2010 году при построении репозиториев будут конкурировать несколько «стандартных» спецификаций (вероятность 0,8).

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

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

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

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

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

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

Открытый код

Стратегические прогнозы: к 2010 году на большинстве ведущих прикладных платформ доля программ с открытым кодом превысит 20% (вероятность 0,7); к 2010 году соответствие стандартам останется обязательным, но не менее 40% API на ведущих платформах будут собственными дорогостоящими расширениями (вероятность 0,8).

До эпохи Internet прикладные платформы, такие как IBM CICS, BEA Tuxedo и хранимые процедуры баз данных, возникали как полностью частные среды. Затем движение к открытым системам породило быстрый рост первых платформенных стандартов, включая стек протоколов TCP/IP, ставший технической основой Internet, а также среду распределенных вычислений DCE, предшественницу более поздних механизмов удаленного вызова процедур (таких, как удаленный вызов методов Java RMI и объектная модель распределенных компонентов Microsoft DCOM).

К 2000 году большинство прикладных платформ, в том числе, CORBA и J2EE, существенным образом опирались на стандарты (рис. 9).

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

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

Ведущие поставщики коммерческих продуктов воспринимают Open Source как неизбежность. Все чаще они решают принять этот подход, а не бороться с ним. В то же время продолжается реализация стандартов в коммерческих продуктах. Ни продукты с открытым кодом, ни продукты на основе стандартов не могут диктовать высокие цены. Для сохранения своих доходов поставщики вкладывают капитал в расширенные собственные дополнения к стандартным технологиям и технологиям категории Open Source, а также изменяют свои бизнес-модели, стремясь извлекать доходы не из продаж программного обеспечения, а из услуг. Таким образом, ведущие коммерческие платформы все больше напоминают «трехслойный пирог»: открытый код, легко заменяемые стандартные решения и уникальные собственные дополнения.

Рекомендации. Приготовьтесь управлять комбинацией открытых, стандартных и проприетарных технологий на большинстве корпоративных прикладных платформ.

Микроядро встречается с ESB

Платформа — это сложный набор технологий, обслуживание и обновление которых порождают проблемы как у пользователей, так и у поставщиков. Самые современные платформы являются комплексами, состоящими из нескольких программных систем. Такие системы включают в себя множество компонентов, таких как контейнеры сервлетов, контейнеры EJB, системы обмена сообщениями, серверы обработки транзакций, серверы безопасности, модули кэширования, адаптеры прикладных систем, контроллеры управления бизнес-процессами, механизмы преобразования, Web-серверы, процессы прослушивания Web-сервисов и синтаксические анализаторы XML. Еще больше осложняет ситуацию то, что некоторые из систем разработаны поставщиками программного комплекса, а другие приобретены у ассоциаций разработчиков, достались в наследство при слиянии компаний или предоставлены сообществом Open Source.

Поставщики платформ все чаще используют архитектурный стиль «микроядра», в котором платформа состоит из ядра и многочисленных подключаемых функциональных компонентов (рис. 10). «Подключаемость» компонентов, уменьшающая сложность управления платформой, достигается с помощью общего набора системных программных интерфейсов (System Programming Interface, SPI). Sun Microsystems совместно с компаниями Tibco, Oracle, SAP и другими стремится возглавить процесс стандартизации подобных интерфейсов, инициировав проект спецификации JSR 208. Некоторые поставщики (например, JBoss) используют расширения Java с целью создания систем управления (Java Management Extensions, JMX). Есть и такие компании, в частности, Iona Technologies, которые применяют специализированные SPI.

Тем временем бизнес-приложения двигаются к архитектуре SOA, воплощающей аналогичный принцип модульности. Технология сервисной шины предприятия (Enterprise Service Bus, ESB) обеспечивает API для подключения бизнес-компонентов. ESB поддерживает бизнес-компоненты, ориентированные как на события, так и на сервисы. Кроме того, она поддерживает интероперабельность в гетерогенной среде, а также преобразования и управляемую данными маршрутизацию — основу брокера интеграции.

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

Рекомендации. Отдавайте предпочтение поставщикам, поддерживающим архитектуры микроядра и ESB.

Программные экосистемы

Стратегический прогноз: к 2010 году более 80% крупных и средних предприятий будут участвовать в экосистемах, образованных платформами нескольких поставщиков (вероятность 0,8).

Современная программная среда ведения бизнеса больше не представляет собой набор разрозненных решений с хранением данных в раздельных СУБД, а строится на базе общей инфраструктурной платформы. Признав это, крупнейшие поставщики технологий — включая IBM, Oracle, Microsoft и SAP — ведут отчаянную борьбу за лидерство на рынке платформ. Они расширили свои технологические предложения за счет формирования комплексов платформ и поощряют к их использованию своих партнеров, специализирующихся в той или иной области. Таким образом, поставщики пытаются сформировать «экосистемы» технологий и сервисов, которые объединяются вокруг их платформенных архитектур.

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

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

Организационные и культурные изменения

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

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

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

n изолированные решения в управлении бизнесом порождают фрагментированную бизнес-стратегию и столь же фрагментированную ИТ-среду;

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

Научиться сотрудничать

Стратегический прогноз: к 2010 году более 80% очень крупных и 50% больших предприятий будут иметь экспертные центры по интеграции (вероятность 0,7).

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

Такие изменения облегчаются путем учреждения экспертного центра по интеграции (Integration Competency Center, ICC). Успех корпоративной стратегии SOA в значительной степени зависит от способности предприятия организовать эффективный координационный центр. Для того чтобы приложения начали сотрудничать, сначала должны научиться сотрудничать люди, отвечающие за эти приложения. ICC обеспечивает эффективную организационную структуру для столь необходимых координации и сотрудничества.

ENS (технология) и ICC (организация) повторяют друг друга (рис. 12). У них общая цель: заставить независимые информационные системы работать вместе, позволяя им оставаться достаточно независимыми.

Роль ИТ-отдела в управлении сложностью

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

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

Общие рекомендации

Уясните все варианты программной архитектуры. Одна модель не годится на все случаи жизни, а многие архитектуры дополняют друг друга.

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

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

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

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

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

Ефим Натис — вице-президент исследовательского подразделения Gartner Research. Натис закончил Рижский политехнический институт по специальности прикладная математика. Двадцатипятилетний опыт работы в области корпоративных информационных технологий и участие в целом ряде разработок позволили ему стать «супер-аналитиком» (distinguished analyst) и вице-президентом в исследовательском подразделении Gartner Research. Натис специализируется на вопросах корпоративной программной инфраструктуры, включая такие технологии, как серверы приложений, средства для создания прикладных платформ, интеграционной ПО промежуточного слоя. Его область интересов распространяется и на современные архитектуры, в том числе архитектуры, архитектуры, стимулированные событиями, архитектуры, ориентированные на сервисы, Web-сервисы, а также на поддерживающие их технологии COM/COM+, .NET, J2EE и CORBA.

---