Адаптивный кейс-менеджмент и основные данные

Перед отпуском я написал серию сообщений о SOA, ESB, EDA и Master Data Management. Потом я написал о том, как собрать это все вместе. А по возвращении из отпуска позволил себе добавить в эту конструкцию еще и BPM. Но честно говоря, я еще не сказал главного, о чем мне и напомнил доклад Анатолия Левенчука “Между проектами и процессами: адаптивное управление кейсами”. Настоятельно рекомендую его послушать.

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

Читать далее Адаптивный кейс-менеджмент и основные данные

Как внести больше смысла в структуры основных данных

На прошлой недели меня пригласили на встречу, организованную для ИТ директоров одним из известных поставщиков решений класса master data management. Значительная часть обсуждения была посвящена вопросу как «продать» бизнес-заказчику MDM решение. Безусловно, у такого рода проектов должен быть именно бизнес-заказчик. Однако, выгоды внедрения новой системы для ИТ тоже должны быть обозначены. Иначе ИТшники будут сидеть и ждать пока бизнес созреет и сам принесет им MDM-проект. Ниже я постарался набросать несколько собственных мыслей на тему зачем нужен MDM ИТ директору.

Читать далее Как внести больше смысла в структуры основных данных

Master Data Management, EDA, ESB, SOA: собираем все вместе

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

 

getBookAuthor(…) и getBookPublisher(…)

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

getBookProperty(authorID,…)

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

getItemProperty(itemID, propertyID,…)

Преимущества такого подхода достаточно очевидны. Впрочем, в дополнение к преимуществам появляются и определенные сложности. Одна из них состоит в необходимости разработки дополнительных функций для получения списка item-ов и списка их свойств. Причем перечни свойств элементов различных типов может не совпадать. Описание структуры данных принято выносить в мета-данные (meta-data management). Т.е. у нас должен появиться справочник, в который мы будем вносить эти данные и программные интерфейсы для чтения этих справочников из приложений. Вот мы и добрались до управления основными данными (master data management, нормативно-справочная информация) о котором говорили в сообщении Интерес к управлению данными возвращается Это станет особенно актуальным если информацию получать мы будем из нескольких разнородных приложений с различными программными интерфейсами. Кстати именно в этом случае нам понадобится ESB и управляемая событиями архитектура (Even-driven architecture) Может показаться, что я противоречу своим более ранним сообщениям. Однако, если разобраться чуть глубже, то станет понятно почему это не так (см. рисунок)

В каждом из унаследованных приложений свои структуры данных и свои программные интерфейсы (в одном книжки, в другом компакт-диски ). В каждом, в лучшем случае, свои справочники свойств или же тривиальный хардкод, что встречается чаще. Первое что нужно сделать – научить приложения уведомлять MDM-систему обо всех изменениях в справочниках (Event Driven стиль). В крайнем случае, можно наладить ETL процесс, который будет регулярно сканировать базу данных на предмет выявления изменений и отражать их в MDM. Для того чтоб получить перечень свойств книг или перечень свойств компакт-дисков, очевидно, не следует вызывать API унаследованных приложений, а следует обратиться к MDM системе. (Подробнее см. Gregor Hohp Programming Without a Call Stack – Event-driven Architectures) И в завершении картинки у нас появляется сервисная шина предприятия (ESB), которая берет на себя функции преобразования запросов из getItemProperty() в реализованный унаследованным приложением getBookAuthor(), а так же маршрутизации запросов между приложениям. Кроме того, ESB окажется полезным и при чтении MDM, например, для сокрытия задержек обновления данных в MDM, кеширования запросов и т.д. Сам процесс обновления данных в MDM системе можно и даже нужно реализовать в ESB, т.к. это позволит нам реализовать достаточно эффективные стратегии управления данными. Не стану углубляться в подробности, т.к. описание данных стратегий потребует некоторого погружения в описание архитектуры Web. Интересующихся отсылаю к диссертации изобретателя стиля RESTful Роя Филдинга (краткое введение в тему RESTful и Enterprise 2.0)

Что останется после ACM и BPMS?

Интерес к системам Business Process Management не может всегда оставаться на высоком уровне. Про термин adaptive case management через пару лет, вообще, никто не вспомнит. ACM и BPM освободят место новым трехбуквенным сокращениям, оставив после себя некоторое количество информационных систем. Хочется надеяться, что унаследованные приложения будут хоть в каком-то виде вписываться в новый корпоративный ИТ-ландшафт. Поэтому, есть смысл уже сейчас смотреть на те компоненты, которые присутствуют в системах обоих типов. Читать далее Что останется после ACM и BPMS?

Работа ИТ архитектора – создание хороших абстракций

bigВ сообщении Как сделать хороший API? я высказал предположение, что разработка повторно-используемых компонент (reusable component) достигается за счет разработки достаточно абстрактных методов, лишенных излишней конкретики, исходящей из текущей задачи. В комментариях к сообщению я привел примеры и получил некоторую критику. В действительности, абстрагирование, конечно же, необходимо не столько для построения хороших интерфейсов, сколько для построения хороших систем. Хороший интерфейс – это следствие хорошей объектной модели системы. Системы, имеющую ясную модель данных и одновременно допускающие её расширения посредством настроек пригодны для повторного использования и не требуят для этого дополнительных доработок. Системы сделанные «на злобу дня» таким свойством не обладают.

Если я правильно помню, то Гради Буч называл программы, разработанные по принципу «сели и начали писать», т.е. без предварительного продумывания (проектирования), зубочистками. Для однократного использования и такой метод сойдет. Для построения собачьей конуры необходимо немножко подумать, наверное, даже чертеж набросать. В спроектированную таким образом конуру вторую собаку мы вряд сумеем поселить, но построить еще один экземпляр собачьей конуры по своим наброскам сможем. А вот запрограммировать скворечник так уже вряд ли получится. Одним словом, подход «сели и начали писать» не подходит для корпоративных информационных систем. Чтобы создать повторно-используемую систему надо провести объектно-ориентированный анализ, разработать хорошую иерархию классов и только потом программировать.

Почему же разработчики корпоративных информационных систем, особенно заказных систем, так не делают? Отчасти ответ на этот вопрос дает Алистер Коберн обнаруживший, что людям больше свойственно заниматься изобретением чего-то нового, чем изучением уже существующего. Другую часть ответа мы найдем у Мартина Фаулера в книге «Архитектура корпоративных программных приложений». Значительная часть этой книге посвящена обсуждению того печального факта, что реляционные базы данных не реализуют механизмы наследования. Т.е. разработав иерархию классов, связанных отношением наследования, программист сталкивается с проблемой запихивания экземпляров этих классов в реляционную базу данных. В одних случаях для хранения экземпляров разных классов используется единая таблица, в других случаях – объекты разносятся по разным. Короче, разработчик предпочитает не заморачиваться объектно-ориентированным подходом и начинает не с создания робастой структуры классов, а с написания таблиц в базе данных. Через пару лет корпоративный ИТ ландшафт превращается в зоопарк редких и исчезающих систем. Я, не задумываясь, насчитаю в нашей компании несколько десятков систем, обрабатывающих разного рода заявки. Естественно, каждая из них реализуют для этого свою уникальную структуру данных, логику и уровень представления. Возможно, от разработчиков и не следует ожидать построения хороших абстракции и это задача, которую предварительно должен выполнить архитектор. Ушел подробнее разбираться в Domain-driven design, надеюсь вернуться оттуда с какими-либо ответами

Как сделать хороший API?

ArchimateAbstractВ предыдущем сообщении Event-driven architecture я позволил себе заметить, что сервисная шина (ESB) не является необходимым условием построения сервис-ориентированной архитекутры(SOA). О том, что сервисы должны предоставляться именно приложениями много говорят в SOA School Томаса Эрла, используя термин Intrinsic interoperability На занятиях мы довольно долго пытались его корректно перевести и, по-моему, остановились на «врожденной способностью к взаимодействию». Этот принцип, кстати, вошел в СОА-манифест в формулировке «Intrinsic interoperability over custom integration»
Одним словом, речь идет о том, что задача предоставления [ре]юзабильных повторно-используемых программных интерфейсов отводится именно бизнес-приложениям, а не интеграционной среде. (Под юзабилити я понимаю именно юзабилити, а не эргономику. Чем отличается одно от другого см. Юзабилити глазами архитектора)
Вопрос в том, как такие интерфейсы построить.

Вариант 1. Обнаружить стандарт, описывающий данную предметную область (домен). Я не говорю о стандартах вида WS-* они описывают совершенно другие вещи. Речь идет именно о стандартах CMIS, OSS/J и пр.
Вариант 2. Если стандартов нет, и все знания о предметной области локализованы в головах нескольких посвященных соответствующего тайного ордена, то интерфейс придется разрабатывать. И обычно это делается неправильно. Разработчик системы спрашивает, какие данные вам нужны и предоставляет что-то похожее на то, что вы попросили. В результате получаются хранимые процедуры типа:

СуммВырчкНаУтроGF-ЧудесСтрДураков(Кол-воЗолотых)

О повторном использовании таких сервисов говорить, разумеется, не приходится. Очевидный способ построения повторно-используемых интерфейсов – абстрагирование. Про абстрагирование сказано практически во всех работах по программной инженерии от «Программисткого камня» (рекомендую прочитать эту книжку целиком) до классических работ Г.Буча «Объектно-ориентированный анализ и проектирование», но сказано как-то не очень внятно. Поэтому, вопрос как построить хорошую объектную модель, а значит и reusable API остается открытым. Я тоже не знаю полного ответа на этот вопрос, но готов поделиться некоторыми частными, глубоко субъективными наблюдениями:

  • REST лучше чем SOAP, так как оперирует с данными, а не с поведением, а это всегда проще.
  • Референсные модели предметной области, по крайней мере такие, в которых нормальный человек может разобраться, имеют право на жизнь.
  • Что-то чуть более конкретное, чем «Object-Relations» (см. рисунок, предложенный разработчиками ArchiMate).
  • Семь плюс-минус две сущности. Для того, чтоб понять что такое, например WordPress, достаточно посмотреть на структуру его базы данных. В системах, написанных за деньги и на заказ разобраться в структуре данных практически нереально.
  • Классы предметной области и отношения между ними не должны присутствовать в сигнатурах методов. Они должны вести в справочниках, доступных через тот же самый API. Тогда интерфейс становится самоописанным.

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

Event-driven architecture

В 2006 году Gartner закрыл аналитическую группу, которая занималась управляемой событиями архитектурой (Event-driven architecture, EDA). Термин EDA предложил аналитик Gartner Roy W. Schulte тремя годами раньше в работе The Growing Role of Events in Enterprise Applications Обзор работы на русском языке можно посмотреть в статье EDA – архитектура, управляемая событиями До какого-то момента SOA и EDA в сознании аналитиков шли рука о руку (см., например 2.0 The Mission and Future of Integration), но потом управляемая событиями архитектура впала в немилость и была забыта. Может быть, концепция была слишком революционной, а может идея Complex event processing (CEP) отвлекла на себя основной внимание, но из-за задержки внедрения таких технологий как RFID ушла в тень, прихватив с собой и EDA, не важно. Для нас важно другое:

  • во-первых, в отличии от SOA, EDA – это действительно архитектура, т.е. определенный подход к построению информационной системы предприятия;
  • во-вторых, концепция управляемой событиями архитектуры объясняет, почему сегодня интерес к сервисной шине предприятия (ESB) опережает интерес к SOA (см. ссылки в сообщении Forrester: SOA жив и здоров)

Читать далее Event-driven architecture

OSS/J, MTOSI и другие

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

Начнем с OSS through Java Initiative (OSS/J). Эта инициатива стартовала в 2000г. в рамках Java community с целью разработки интерфейсов для взаимодействия систем поддержки операций телекоммуникационной компании. OSS/J изначально ориентировалась на работы TMForum, с его shared information/data model(SID), развесистыми картами бизнес-процессов и приложений оператора связи, что предопределило её достаточно абстрактный характер. Естественно OSS/J платформо-зависимая спецификация. Изначально в ней присутствовали два типа взаимодействия приложений: RMI и обмен XML сообщениями через очереди посредством JMS. В 2006 году OSS/J присоединилась к TMForum. Сейчас кроме java интерфейсов OSS/J поддерживает для ряда API и SOAP веб-сервисы.

Multi-Technology Operations System Interface (MTOSI) это базирующийся на XML интерфейс, выросший из задачи управления сложными гетерогенными сетями. По мнению TMForum стандарты дополняют друг друга, тем не менее, задачи, решаемые OSS/J и MTOSI, довольно сильно перекрываются. Насколько я понимаю, в TMForum-е неустанно работают комитеты, гармонизирующие эти стандарты.

Вернемся к OSS/J. В основе этих стандартов лежит вполне здравая идея отделения уровня данных (inventory) от уровня бизнес-процессов: обработки заявок на подключение (order management), обнаружения и устранения неисправностей (fault management), технической поддержки (trouble ticketing). На текущий момент системы поддержки операций таким разделением не обладают. Т.е. в одной и той же системе сосредоточены планы строительства, заявки на проведение работ, отображение результата (построенной сети). Так как сети разные, то таких систем много и в каждой зашита специфика конкретной сети. Естественно, доступ к данной информации возможен только через пользовательский интерфейс конкретного приложения, а задача объединения inventory в телекоме признана нерешаемой.  В какой-то момент это превращается в настоящий кошмар для служб эксплуатации и развития.

И потому рано или поздно приходится задумываться о SOA.

Forrester: SOA жив и здоров

Примерно таким заголовком анонсировали интернет издания мартовское исследование Forrester SOA Adoption 2010: Still Important, Still Strong Оказывается 71% опрошенных компаний уже используют SOA или собираются это сделать в течении 2011 года. То же самое говорит почти половина средних и малых компаний. Организации довольны результатами, получаемыми от сервис-ориентированной архитектуры и не собираются от неё отказываться. Безусловно, определенная часть опрошенных просто не понимает о чем говорит, но единодушие в ответах респондентов показывает, что «пациент скорее жив, чем мертв».

Не менее интересное исследование появилось в конце апреля The Forrester Wave™: Enterprise Service Bus, Q2 2011. Рынок ESB продолжает неплохо расти. Кроме вполне привычных для ESB задач, таких как маршрутизация сообщений и преобразование данных 35% компаний используют ESB непосредственно для разработки сервисов, а 14% для прикладной разработки на BPEL (28% используют BPEL для оркестровки). Кстати, с языком исполнения бизнес-процессов WS_BPEL ситуация тоже интересная. 2-3 года назад только ленивый не говорил о том, что SOA и BPM – браться на век. Затем из лагеря BPM стали отчетливо слышаться голоса, что BPEL not for people. В ответ могу попрекнуть разработчиков BPMS в монолитности архитектуры их флагманских продуктов. Далеко не все BPMSы, те который для людей, а не так называемый IC-BPMS, отвечают принципам сервис-ориентированной архитектуры, потому как сервисов они не предоставляют. В итоге, у больших вендоров в линейке присутствуют как минимум по два продукта: один для быстрого рисования процессов и пользовательских интерфейсов к ним, а другой для интеграции в корпоративную информационную систему, т.е. интероперабельный. Читать далее Forrester: SOA жив и здоров

Услуга интеграции приложений для оператора связи

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

Потребности оператора связи в интеграции приложений можно условно разбить на следующие группы: Читать далее Услуга интеграции приложений для оператора связи