ИТ-архитектура организации: SOA и управление информационными потоками, часть 2

В первой части статьи на эту тему я выделил следующее определение SOA: использование свободно соединяемых сервисов, построенных так, чтобы обеспечить многократное использование бизнес-процессов, позволяющих устанавливать свободную коммуникацию между системами и создавать цельные приложения внутри организации.
ИТ-архитектура организации: SOA и управление информационными потоками, часть 2
SOA, Service-oriented Architecture – Сервис-ориентированная архитектура - наборов сервисов, которые обмениваются информацией между собой. Каждый из сервисов является самодостаточным и не зависит от контекста или состояния других сервисов.

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

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

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

[Перепечатка материалов 12NEWS.ru разрешается только с предварительного согласования с редакцией или автором. Если вы читаете этот материал на другом ресурсе, пожалуйста, сообщите нам об этом editor@12news.ru]

В этот день у меня была возможность послушать презентации трех вендоров. Я заметил интересную и едва различимую тенденцию. Каждый специалист вендора говорил о волшебстве SOA, и как он мог революционизировать бизнес правительственного поставщика. Все они говорили: «Однажды определив ваши централизованные процессы, у вас будет каталог ваших данных, потом мы … (вставьте особенность уклона вендора)». Когда пришла наша очередь для презентации, я начал с того, что мы не компания SOA как таковые, я спросил, знают ли они все то, что понадобится сделать перед тем, как они смогут внедрять SOA? Именно у нас есть это.

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

Перед обсуждением создания общих процессов, хочу пояснить некоторую ключевую терминологию ИТ, особенно такие понятия как система (Systems), процессы (Processes), данные (Data) и бизнес-правила/требования/регламенты (Business Rules). Схема 1 иллюстрирует внутренние связи между этими понятиями.
 



Схема 1: Связи ИТ- компонентов



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

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

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

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

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

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



David Marco,
Перевод и адаптация 12NEWS
(Translation by 12NEWS)


 



David Marco – международно-признанный эксперт в области структуры предприятий, организации информационных хранилищ и интеллектуальных ресурсов. Он автор Universal Meta Data Models (Wiley, 2004) и Building and Managing the Meta Data Repository: A Full Life-Cycle Guide (Wiley, 2000). Марко преподавал в университете Чикаго и ДеПаула, и в 2004 был награжден престижной наградой Chicago Business «Top 40 Under 40».
Основатель и президент Enterprise Warehousing Solutions, Inc, GSA schedule (EWSolutions.com )
Связаться с автором возможно через редакцию 12NEWS.
 

© Издание 12NEWS (ИП Маринин А.Л.), 2007


Комментарии на публикацию ИТ-архитектура организации: SOA и управление информационными потоками, часть 2

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