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

1.3.2Модель Захмана

В1987 году, Джон Захман (сотрудник корпорации IBM) предложил иерархическую модель предприятия, предлагая на каждом уровне представления давать ответы на вопросы: что?, как?, где?, кто?, когда? и почему?

Предложенная модель множество раз модифицировалась и расширялась.

Вконечном итоге она приняла стабильную форму и стала обязательным атрибутом учебных пособий по архитектуре предприятий, например, [13, 14]. Общий вид ее представлен на рисунке 1.10.

Рисунок 1.10 — Архитектурная матрица модели Захмана [14]

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

26

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

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

1.3.3Концепция среды открытой системы

В1998 году, американский Институт инженеров электротехники и электроники (Institute of Electrical and Electronics Engineers, IEEE) выпустил стандарт IEEE Std 1003.23—98 под названием «Стандарт института инженеров по

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

В ноябре 2002 года, Госстандарт России вынес постановление о публикации Рекомендаций по стандартизации Р 50.1.041-2002 под названием «Руководство по проектированию профилей среды открытой системы (СОС) органи- зации-пользователя» [15], где указанная выше концепция представлена как «Эталонная модель СОС POSIX (ИСО/МЭК 14252)».

Идейная основа эталонной модели СОС POSIX состоит в том, что при должном формиро-

вании профилей СОС (OSE, Open System Environment) предприятий, дальнейшее решение осуществляется рынком постащиков программного обеспечения, аппаратных средств и телекоммуникаций.

Про своей сути, Рекомендации по стадартизации Р 50.1.041-2002 [15] являются описанием методики проектирования информационных систем, где на верхнем (концептуальном) уровне выделяются и иерархически размещаются три объектных сущности и два интерфейса:

а) Объект прикладных программных средств;

б) ППИ — прикладной программный интерфейс (API, Application Program Interface);

в) Объект прикладной платформы — объект набора ресурсов, включая

27

технические и программные средства, которые обеспечивает услуги для функционирования прикладных программных средств;

г) ИВС — интерфейс с внешней средой (EEI, External Environment Interface);

д) Внешняя среда.

Выделенные объектные сущности объединяются с помощью четырех служб, как это показано на рисунке 1.11.

Рисунок 1.11 — Эталонная модель СОС POSIX [15]

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

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

28

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

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

1.3.4 Бизнес-парадигма модели SOA

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

Рисунок 1.12 — Бизнес-парадигма архитектуры предприятия [11]

Уровень бизнес-логики — соответствует уровню бизнес-руководителей предприятия, которые генерируют бизнес-процессы и становятся потребителями сервисов (Service Consumer).

Уровень интерфейса сервисов (Service Interface) — уровень взаимодей-

29

ствия бизнес-руководителей и ИТ-специалистов предприятия, обеспечивающий свойства видимости (Visibility), перспектива возможного использования сервисов (Interaction) и фактического получения результата услуги (Real world effect). На этом уровне ИТ-специалисты получают статус провайдеров услуг (Service Provider).

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

а) представлять слабосвязанные или сильносвязанные системы; б) быть распределенными или сосредоточенными системами;

в) соответствовать или несоответсвовать эталонной модели СОС POSIX;

г) принадлежать предприятию или находиться в «облаке» (cloud computing) на аутсорсинге (outsourcing).

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

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

Негативная сторона модели бизнес-парадигмы модели SOA состоит в достаточно высокой степени неопределенности концепции проектирования и реализации уровня приложений.

Бизнес-парадигма модели SOA предполагает быстрое и качественное создание, развертывание и сопровождение сервисов.

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

30