Архитектура предприятия

Архитектура приложений

Разбить на страницы
Показывать лекцию целиком

Архитектура приложений

Контекст и основные элементы архитектуры приложений

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

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

В Архитектуре приложений, как правило, выделяют две основные области [4.3]:

  • формирование и управление портфелем прикладных систем предприятия;
  • разработку прикладных систем.
  • (рис 6.1) Две области Архитектуры приложений предприятия

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

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

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

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

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

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

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

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

    (рис 6.2) Контекст управления портфелем прикладных систем

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

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

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

    Модели и инструменты управления портфелем приложений

    Существуют различные способы оценки портфеля и различные классификации прикладных систем предприятия. Одной из возможных моделей оценки портфеля прикладных систем является оценка их по двум критериям – ценность с точки зрения бизнеса и техническое состояние, что проиллюстрировано на рис. 6.3 [4.19].

    (рис 6.3) Оценка портфеля прикладных систем по критериям "бизнес-ценность" и "техническое состояние"

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

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

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

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

    Ниже даны краткие характеристики каждой категории систем в соответствии с этой классификацией:

  • Вывод из эксплуатации (замена) или консолидация (низкая ценность для бизнеса и плохое техническое состояние). Эти прикладные системы являются кандидатами на вывод из эксплуатации или замену. Хотя надо иметь в виду, что стоимость замены некоторых унаследованных и бэк-офисных систем может оказаться неоправданно высокой и будет иметь весьма ограниченную ценность с точки зрения бизнеса.
  • Провести переоценку или перепозиционировать (низкая ценность для бизнеса и отличное техническое состояние). Как правило, это прикладные системы, которые были недавно запущены в эксплуатацию в соответствии с рекомендациями, принятыми в рамках архитектуры предприятия. Однако объем и характер решаемых ими задач или ограниченность области применения в рамках каких-то узких организационных функций таковы, что их вклад в достижение ключевых бизнес-результатов незначителен. В этой ситуации рекомендуется идентифицировать и проанализировать возможности использования этих приложений или их компонент в рамках остальных бизнес-процессов и организационных структур предприятия.
  • Развивать инфраструктуру прикладной системы (высокая ценность для бизнеса и плохое техническое состояние). Эти прикладные системы исправно обслуживают ключевые бизнес-функции, но создают существенные проблемы, когда речь идет об эксплуатации и сопровождении этих систем, когда возникает необходимость использования информации из них где-либо еще и когда требуется интеграция этих систем с другими прикладными системами предприятия. Рецептом здесь является постепенный переход на использование более адаптивной архитектуры приложения (компонентный подход, n-уровневая архитектура, основанные на пересылке сообщений интерфейсы и т.д.).
  • Обеспечить сопровождение и развитие (высокая ценность для бизнеса и отличное техническое состояние). Эти системы критически важны с точки зрения бизнеса и спроектированы в соответствии с современными представлениями об архитектуре прикладных систем.
  • Этот же способ оценки назван Матрицей оценки состояния прикладных информационных систем (Health Grid) [4.14]. Графическое расположение систем на матрице, кроме двух параметров – ценность с точки зрения бизнеса и техническое состояние, – может нести в себе еще и дополнительную информацию. Во-первых, каждой прикладной системе соответствует круг, диаметр которого пропорционален общей стоимости информационной системы, с учетом стоимости приобретения, эксплуатации и сопровождения (стоимости обновлений). Во-вторых, круги окрашиваются в один из пяти цветов, характеризующих реальную важность системы, а не просто потенциальную ценность для бизнеса (например, система в данный момент может считаться малоценной для бизнеса, но достаточно важной, поскольку ценность ее может быть повышена в будущем за счет обновления и обеспечения доступа к накопленным данным через Интернет).

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

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

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

  • Название системы.
  • Описание системы.
  • Список технологических компонентов. Это важно, поскольку они могут использоваться независимо для построения других решений. При этом основные компоненты должны быть отдельно описаны, включая их функции и техническое состояние.
  • Область применения с точки зрения бизнеса, т.е. функциональные возможности (например, CRM, финансы, управление кадрами, каналы продаж через Интернет и пр.).
  • "Владелец" системы со стороны бизнеса.
  • Оценка пользы прикладной системы для бизнеса.
  • Ответственный со стороны ИТ-подразделения.
  • Оценка технического состояния.
  • Оценка возможностей по обеспечению новых потребностей бизнеса.
  • Дата обновления этой информации.
  • Для оценки портфеля прикладных систем может быть также использована модель, предложенная Gartner [4.20].

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

    Интересно то, что совершенно разные авторитетные источники – Gartner, META Group, а также Уэйл и Броадбент в своей книге "Использование возможностей инфраструктуры. Как лидеры рынка получают преимущества от информационных технологий" [4.20], [4.19], [4.14] – дружно выделяют три категории прикладных систем, правда, используя для обозначения этих категорий несколько разные определения. Однако критерии отнесения прикладных систем к той или иной категории при этом полностью совпадают.

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

  • базовые транзакционные (или вспомогательные, обеспечивающие, обслуживающие – utility);
  • информационные (дающие преимущества);
  • инновационные (стратегические).
  • (рис 6.4) Анализ ценности портфеля приложений на основе категоризации

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

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

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

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

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

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

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

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

    (рис 6.5) Портфель ИТ и цели инвестиций в различные активы

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

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

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

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

  • Критически важное для предприятия в целом (mission-critical). Приложение чрезвычайно важно для осуществления всей миссии компании, нарушения в работе приложения могут повлечь катастрофические последствия для бизнеса. Пример: система биллинга оператора мобильной связи или система управления движением в аэропорту.
  • Критически важное для бизнеса (business-critical). Приложение важно для поддержки отдельного направления бизнеса или обеспечивающего бизнес-процесса. Нарушения могут повлечь серьезные затруднения в бизнесе. Пример: система приема заказов через Интернет.
  • Вспомогательное (utility). Некритичное приложение, решающее частную, вспомогательную задачу. Пример: система резервирования помещений для переговоров.
  • Средства офисной автоматизации (office productivity). Это приложения, используемые для автоматизации повседневной работы. Типичный пример: офисные пакеты и средства подготовки презентаций.
  • Заметим, что для разных компаний одни и те же "стандартные" приложения, такие, как электронная почта или система приема заказов, могут относиться к различным уровням в данной классификации. Уже упомянутая выше система приема заказов через Интернет будет относиться к категории критически важного для предприятия в целом (mission-critical) у магазина интернет-торговли книгами типа Amazon.com и к категории вспомогательного (utility) у крупной нефтяной компании. Кстати, наличие приложений "всех уровней" вовсе не обязательно! Например, в одном из встретившихся на практике случаев (для нефтедобывающей компании) выяснилось, что приложений уровня mission-critical там вообще нет! Как отметили сотрудники компании в анкетах, "в случае сбоя информационной системы, мы все отчеты считаем вручную и передаем в головную компанию по телефону. И такое запаздывание никак не влияет на результаты деятельности организации".

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

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

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

    Влияние архитектуры приложений на инфраструктуру

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

    Например, компания Delta Air Lines построила свою "Нервную Систему", которая использует при работе с данными принцип "публикации и подписки" для управления операциями и работы с клиентами. Эта инфраструктура работает так, что каждый, кому это необходимо, будет получать точную информацию о статусе полета, экипажах и пассажирах. Однако архитектура этой инфраструктуры не обеспечивает адекватные возможности по созданию прикладных систем для таких задач, как планирование прибыли, что является критически важной проблемой для обеспечения прибыльности операций и распределения ресурсов, или развертывания ERP-системы для управления административными процессами. Таким образом, различные бизнес-процессы требуют разную по характеру среду информационных технологий, отличающуюся производительностью, надежностью и пр. Для решения этой проблемы в компании Delta Air Lines была сформулирована концепция "архитектурного стиля", которая определяет архитектурный стиль как некоторую совокупность корпоративных технологий и операционных сред, ориентированных на обслуживание определенного класса бизнес-процессов [4.21].

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

    С этой точки зрения, оправдана следующая классификация прикладных систем [4.21], [4.22] с пятью различными архитектурными стилями:

  • Приложения, обслуживающие большое количество транзакций (Transaction Processing). Примеры: биллинг у телекоммуникационных операторов, резервирование авиабилетов, обработка транзакций по кредитным картам.
  • Операции в реальном времени (Real-Time Operations). Примеры: транспортные операции в аэропорту, мониторинг пациентов в клинике.
  • Аналитические приложения, бизнес-аналитика, поддержка принятия решений (Analytical and Business Intelligence). Примеры: интенсивный анализ больших массивов данных в поисках закономерностей, прогнозирование, принятие решений о выдаче кредита.
  • Приложения поддержки совместной работы (Collaborative). Примеры: средства асинхронного взаимодействия (электронная почта, дискуссионные форумы, групповые календари), средства синхронного взаимодействия (мгновенный обмен сообщениями – instant messaging), средства управления контентом и библиотечные сервисы ( каталогизация и поиск информации, создание электронных библиотек и цифровых архивов документов и пр., портальные сервисы для внутреннего использования служащими).
  • Корпоративные и обслуживающие (Utility) приложения. Этот стиль характерен для многих стандартных систем, таких как ERP, CRM, системы управления персоналом, системы расчета заработной платы.
  • Такая категоризация, возможно, не является бесспорной, но она дает некоторую основу для обсуждения набора тех прикладных систем, которые требуются организации, а также тех базовых, инфраструктурных технологий, которые должны поддерживать эти приложения.

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

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

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

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

    На практике ключевыми должны являться такие вопросы, как:

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

    Требования и характеристики основных типов прикладных систем
    Процессы с большим количеством транзакций Операции в реальном времени Аналитические процессы и бизнес-аналитика Совместная работа Корпоративные (обслуживающие)
    Стратегические потребности
  • Предоставление услуг
  • Время реакции системы
  • Способность дать объяснение
  • Поддержка принятия решения
  • Распространение знаний
  • Скорость
  • Инновации
  • Надежность
  • Низкая стоимость с точки зрения ИТ
  • Бизнес-требования
  • Обслуживание клиентов
  • Уменьшение затрат
  • Работа 24*7
  • Целостность данных
  • Экономичность и безопасность
  • Работа 24*7*365
  • Повышение эффективности и производительности, наглядность представления информации
  • Скорость выпуска услуг
  • Повторное использование знаний
  • Экономичность
  • Улучшения в процессах
  • Отличительные характеристики
  • Низкая стоимость (на одну транзакцию)
  • Надежность
  • Масштабируемость
  • Производительность
  • Резервирование
  • Сканирование и фильтрация потока данных
  • Приоритезация запросов
  • Надежность
  • Публикация и подписка на данные
  • Механизм аналитики
  • Мощность обработки
  • Объединение данных
  • Простота использования
  • Надежность
  • Высокая пропускная способность
  • Обмен данными "по горизонтали"
  • Стандартные процессы
  • Кандидаты на аутсорсинг
  • Интегрирующие технологии
  • Системы интеграции корпоративных приложений
  • Специально разработанный программный код
  • Хранилища данных
  • Совместно используемые данные и обмен данными
  • Стандартные интерфейсы (API), XML
  • Результатом такого подхода может быть более высокая операционная эффективность, уменьшение общих затрат, большая гибкость ИТ-систем в плане реакции на потребности организации, большие возможности с точки зрения организации совместной работы и распространения информации и знаний внутрь и за пределы предприятия.

    Страницы:

    Архитектура приложений

    Контекст и основные элементы архитектуры приложений

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

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

    В Архитектуре приложений, как правило, выделяют две основные области [4.3]:

  • формирование и управление портфелем прикладных систем предприятия;
  • разработку прикладных систем.
  • (рис 6.1) Две области Архитектуры приложений предприятия

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

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

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

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

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

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

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

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

    (рис 6.2) Контекст управления портфелем прикладных систем

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

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

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

    Модели и инструменты управления портфелем приложений

    Существуют различные способы оценки портфеля и различные классификации прикладных систем предприятия. Одной из возможных моделей оценки портфеля прикладных систем является оценка их по двум критериям – ценность с точки зрения бизнеса и техническое состояние, что проиллюстрировано на рис. 6.3 [4.19].

    (рис 6.3) Оценка портфеля прикладных систем по критериям "бизнес-ценность" и "техническое состояние"

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

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

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

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

    Ниже даны краткие характеристики каждой категории систем в соответствии с этой классификацией:

  • Вывод из эксплуатации (замена) или консолидация (низкая ценность для бизнеса и плохое техническое состояние). Эти прикладные системы являются кандидатами на вывод из эксплуатации или замену. Хотя надо иметь в виду, что стоимость замены некоторых унаследованных и бэк-офисных систем может оказаться неоправданно высокой и будет иметь весьма ограниченную ценность с точки зрения бизнеса.
  • Провести переоценку или перепозиционировать (низкая ценность для бизнеса и отличное техническое состояние). Как правило, это прикладные системы, которые были недавно запущены в эксплуатацию в соответствии с рекомендациями, принятыми в рамках архитектуры предприятия. Однако объем и характер решаемых ими задач или ограниченность области применения в рамках каких-то узких организационных функций таковы, что их вклад в достижение ключевых бизнес-результатов незначителен. В этой ситуации рекомендуется идентифицировать и проанализировать возможности использования этих приложений или их компонент в рамках остальных бизнес-процессов и организационных структур предприятия.
  • Развивать инфраструктуру прикладной системы (высокая ценность для бизнеса и плохое техническое состояние). Эти прикладные системы исправно обслуживают ключевые бизнес-функции, но создают существенные проблемы, когда речь идет об эксплуатации и сопровождении этих систем, когда возникает необходимость использования информации из них где-либо еще и когда требуется интеграция этих систем с другими прикладными системами предприятия. Рецептом здесь является постепенный переход на использование более адаптивной архитектуры приложения (компонентный подход, n-уровневая архитектура, основанные на пересылке сообщений интерфейсы и т.д.).
  • Обеспечить сопровождение и развитие (высокая ценность для бизнеса и отличное техническое состояние). Эти системы критически важны с точки зрения бизнеса и спроектированы в соответствии с современными представлениями об архитектуре прикладных систем.
  • Этот же способ оценки назван Матрицей оценки состояния прикладных информационных систем (Health Grid) [4.14]. Графическое расположение систем на матрице, кроме двух параметров – ценность с точки зрения бизнеса и техническое состояние, – может нести в себе еще и дополнительную информацию. Во-первых, каждой прикладной системе соответствует круг, диаметр которого пропорционален общей стоимости информационной системы, с учетом стоимости приобретения, эксплуатации и сопровождения (стоимости обновлений). Во-вторых, круги окрашиваются в один из пяти цветов, характеризующих реальную важность системы, а не просто потенциальную ценность для бизнеса (например, система в данный момент может считаться малоценной для бизнеса, но достаточно важной, поскольку ценность ее может быть повышена в будущем за счет обновления и обеспечения доступа к накопленным данным через Интернет).

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

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

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

  • Название системы.
  • Описание системы.
  • Список технологических компонентов. Это важно, поскольку они могут использоваться независимо для построения других решений. При этом основные компоненты должны быть отдельно описаны, включая их функции и техническое состояние.
  • Область применения с точки зрения бизнеса, т.е. функциональные возможности (например, CRM, финансы, управление кадрами, каналы продаж через Интернет и пр.).
  • "Владелец" системы со стороны бизнеса.
  • Оценка пользы прикладной системы для бизнеса.
  • Ответственный со стороны ИТ-подразделения.
  • Оценка технического состояния.
  • Оценка возможностей по обеспечению новых потребностей бизнеса.
  • Дата обновления этой информации.
  • Для оценки портфеля прикладных систем может быть также использована модель, предложенная Gartner [4.20].

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

    Интересно то, что совершенно разные авторитетные источники – Gartner, META Group, а также Уэйл и Броадбент в своей книге "Использование возможностей инфраструктуры. Как лидеры рынка получают преимущества от информационных технологий" [4.20], [4.19], [4.14] – дружно выделяют три категории прикладных систем, правда, используя для обозначения этих категорий несколько разные определения. Однако критерии отнесения прикладных систем к той или иной категории при этом полностью совпадают.

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

  • базовые транзакционные (или вспомогательные, обеспечивающие, обслуживающие – utility);
  • информационные (дающие преимущества);
  • инновационные (стратегические).
  • (рис 6.4) Анализ ценности портфеля приложений на основе категоризации

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

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

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

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

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

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

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

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

    (рис 6.5) Портфель ИТ и цели инвестиций в различные активы

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

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

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

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

  • Критически важное для предприятия в целом (mission-critical). Приложение чрезвычайно важно для осуществления всей миссии компании, нарушения в работе приложения могут повлечь катастрофические последствия для бизнеса. Пример: система биллинга оператора мобильной связи или система управления движением в аэропорту.
  • Критически важное для бизнеса (business-critical). Приложение важно для поддержки отдельного направления бизнеса или обеспечивающего бизнес-процесса. Нарушения могут повлечь серьезные затруднения в бизнесе. Пример: система приема заказов через Интернет.
  • Вспомогательное (utility). Некритичное приложение, решающее частную, вспомогательную задачу. Пример: система резервирования помещений для переговоров.
  • Средства офисной автоматизации (office productivity). Это приложения, используемые для автоматизации повседневной работы. Типичный пример: офисные пакеты и средства подготовки презентаций.
  • Заметим, что для разных компаний одни и те же "стандартные" приложения, такие, как электронная почта или система приема заказов, могут относиться к различным уровням в данной классификации. Уже упомянутая выше система приема заказов через Интернет будет относиться к категории критически важного для предприятия в целом (mission-critical) у магазина интернет-торговли книгами типа Amazon.com и к категории вспомогательного (utility) у крупной нефтяной компании. Кстати, наличие приложений "всех уровней" вовсе не обязательно! Например, в одном из встретившихся на практике случаев (для нефтедобывающей компании) выяснилось, что приложений уровня mission-critical там вообще нет! Как отметили сотрудники компании в анкетах, "в случае сбоя информационной системы, мы все отчеты считаем вручную и передаем в головную компанию по телефону. И такое запаздывание никак не влияет на результаты деятельности организации".

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

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

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

    Влияние архитектуры приложений на инфраструктуру

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

    Например, компания Delta Air Lines построила свою "Нервную Систему", которая использует при работе с данными принцип "публикации и подписки" для управления операциями и работы с клиентами. Эта инфраструктура работает так, что каждый, кому это необходимо, будет получать точную информацию о статусе полета, экипажах и пассажирах. Однако архитектура этой инфраструктуры не обеспечивает адекватные возможности по созданию прикладных систем для таких задач, как планирование прибыли, что является критически важной проблемой для обеспечения прибыльности операций и распределения ресурсов, или развертывания ERP-системы для управления административными процессами. Таким образом, различные бизнес-процессы требуют разную по характеру среду информационных технологий, отличающуюся производительностью, надежностью и пр. Для решения этой проблемы в компании Delta Air Lines была сформулирована концепция "архитектурного стиля", которая определяет архитектурный стиль как некоторую совокупность корпоративных технологий и операционных сред, ориентированных на обслуживание определенного класса бизнес-процессов [4.21].

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

    С этой точки зрения, оправдана следующая классификация прикладных систем [4.21], [4.22] с пятью различными архитектурными стилями:

  • Приложения, обслуживающие большое количество транзакций (Transaction Processing). Примеры: биллинг у телекоммуникационных операторов, резервирование авиабилетов, обработка транзакций по кредитным картам.
  • Операции в реальном времени (Real-Time Operations). Примеры: транспортные операции в аэропорту, мониторинг пациентов в клинике.
  • Аналитические приложения, бизнес-аналитика, поддержка принятия решений (Analytical and Business Intelligence). Примеры: интенсивный анализ больших массивов данных в поисках закономерностей, прогнозирование, принятие решений о выдаче кредита.
  • Приложения поддержки совместной работы (Collaborative). Примеры: средства асинхронного взаимодействия (электронная почта, дискуссионные форумы, групповые календари), средства синхронного взаимодействия (мгновенный обмен сообщениями – instant messaging), средства управления контентом и библиотечные сервисы ( каталогизация и поиск информации, создание электронных библиотек и цифровых архивов документов и пр., портальные сервисы для внутреннего использования служащими).
  • Корпоративные и обслуживающие (Utility) приложения. Этот стиль характерен для многих стандартных систем, таких как ERP, CRM, системы управления персоналом, системы расчета заработной платы.
  • Такая категоризация, возможно, не является бесспорной, но она дает некоторую основу для обсуждения набора тех прикладных систем, которые требуются организации, а также тех базовых, инфраструктурных технологий, которые должны поддерживать эти приложения.

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

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

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

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

    На практике ключевыми должны являться такие вопросы, как:

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

    Требования и характеристики основных типов прикладных систем
    Процессы с большим количеством транзакций Операции в реальном времени Аналитические процессы и бизнес-аналитика Совместная работа Корпоративные (обслуживающие)
    Стратегические потребности
  • Предоставление услуг
  • Время реакции системы
  • Способность дать объяснение
  • Поддержка принятия решения
  • Распространение знаний
  • Скорость
  • Инновации
  • Надежность
  • Низкая стоимость с точки зрения ИТ
  • Бизнес-требования
  • Обслуживание клиентов
  • Уменьшение затрат
  • Работа 24*7
  • Целостность данных
  • Экономичность и безопасность
  • Работа 24*7*365
  • Повышение эффективности и производительности, наглядность представления информации
  • Скорость выпуска услуг
  • Повторное использование знаний
  • Экономичность
  • Улучшения в процессах
  • Отличительные характеристики
  • Низкая стоимость (на одну транзакцию)
  • Надежность
  • Масштабируемость
  • Производительность
  • Резервирование
  • Сканирование и фильтрация потока данных
  • Приоритезация запросов
  • Надежность
  • Публикация и подписка на данные
  • Механизм аналитики
  • Мощность обработки
  • Объединение данных
  • Простота использования
  • Надежность
  • Высокая пропускная способность
  • Обмен данными "по горизонтали"
  • Стандартные процессы
  • Кандидаты на аутсорсинг
  • Интегрирующие технологии
  • Системы интеграции корпоративных приложений
  • Специально разработанный программный код
  • Хранилища данных
  • Совместно используемые данные и обмен данными
  • Стандартные интерфейсы (API), XML
  • Результатом такого подхода может быть более высокая операционная эффективность, уменьшение общих затрат, большая гибкость ИТ-систем в плане реакции на потребности организации, большие возможности с точки зрения организации совместной работы и распространения информации и знаний внутрь и за пределы предприятия.

    Вернуться к учебному плану