В разговорах об архитектуре информационных систем мы много внимания уделяем таким вопросам, как техники моделирования процессов и данных, принятие и контроль решений, создание общей картины системы – информационной или более общей. При этом мы практически ничего не говорим об основной, изначально присущей архитектуре деятельности – придумывании абстракций данных и поведения. Архитекторов всегда ценили именно за это умение: придумать общую функцию, которая избавит разработчиков от нудной работы, сделать компонент, поведение которого задается файлом конфигурации, инкапсулировать сложное взаимодействие в простой программный интерфейс. Ведь именно это позволяет нам создавать повторно используемые (reusable) компоненты. И это крайне важно как для уменьшения сложности, так и для сокращения трудоемкости и времени доработки решений. В этом блоге я, по-моему, писал об этом только однажды, в заметке Работа ИТ архитектора – создание хороших абстракций, да ведь и тема не особо простая. Ну вот как сесть и начать придумывать эти самые хорошие абстракции?
Искушенный читатель скажет, что повторное использование достигается применением архитектурных паттернов. А я вот с этим не согласен. Когда у вас есть понимание, как сделать повторно используемый компонент, вы садитесь и пишете некоторый абстрактный класс, из которого другие смогут потом наследовать свои частные решения. А если в таком понимании чего-то не хватает, то вы пишите текст с описанием некоторой идеи и примерам. А другие программисты потом делают свой вариант реализации. Какое же это повторное использование?
Еще больше путаницы в этот вопрос вносит сервис-ориентированная архитектура. Во времена повышенного внимания к SOA обсуждалось повторное использование фрагментов бизнес-процессов, оформленных в виде сервисов. Если говорить языком трехуровневой архитектуры («данные – бизнес-логика – презентационный слой»), SOA призывала искать сервисы на уровне бизнес-логики. Но именно на уровне бизнес-логики представляются наименьшие возможности для обобщения и абстрагирования. Именно здесь нас преследует наибольшая вариативность и частые изменения. В любой крупной организации у заказчика всегда есть добрый десяток правил того, как он работает, и двадцать пять исключений из этих правил. Причем выявляются они в ходе эксплуатации системы и влекут за собой постоянные изменения. Сервис-ориентированную архитектуру можно рассматривать как некоторый вызов, призыв к бизнесу унифицировать процессы и операции, но не как решение. Какое уж здесь повторное использование, если нам постоянно приходится что-то дорабатывать?
Намного больше возможностей для создания reusable компонент лежит в уровне презентации. Это может быть дедовский способ генерации экранных форм на основании мета-данных или более утонченный способ, применяемый в лентах сообщений и мобильных приложениях. Подробнее об этом см. в заметке Mobile Human Task Application. Сейчас уже много об этом говорят. Посмотрите интересную статью Конец приложений, какими мы их знали или почитайте про Яндекс.Острова, выдающие экранные формы в результатах поиска. Очевидно, что здесь уже практически все придумано и остается только следить за тем, чтоб разработчики не хардкодили метаданные в пользовательский интерфейс.
Ну а что все же делать с бизнес-логикой? На мой взгляд, на техническом уровне эта задача вообще не решается. Если у вас есть требования, то вы будете реализовывать именно их. При этом вы не сможете выйти за пределы модели, которая была в голове написавшего эти требования аналитика. Возможно, заказчик потенциально и готов к обобщениям, но если разговаривавший с ним аналитик этого не прочувствовал, то возможность сделать что-то повторно используемое утрачена навсегда. Приведу простой пример. Многим аналитикам нравится диаграмма состояний (например, см. статью Григория Печёнкина Самые главные диаграммы). На мой взгляд, если аналитик сидит и придумывает состояния, то значит Главный архитектор уже лажанулся. Если вы хотите унифицировать процессы, то необходимые пользователю новые состояния должны не добавляться, а наследоваться из состояний эталонной модели процесса. Еще раз: аналитик не может придумывать новые состояния. Ему разрешено лишь сказать, что у некоторого состояния процесса/ресурса есть некоторый частный случай. Иначе вы никогда не сумеете собрать модели в единое целое, а интеграция между процессами (хореография) превратиться в нескончаемый процесс отображения состояний и переходов, реализованных в одной системе, в состояния и переходы, придуманные в другой системе. Это как реляционные базы данных и объектно-ориентированный подход. ООП появился как ответ на неуправляемый рост количества табличек в базах данных. Как только нам требовалось добавить к некоторому объекту новое свойство или отношение, мы создавали в БД новую сущность (или уродовали старую, добавляя новое свойство сразу ко всем объектам). С появлением классов, благодаря механизму наследования, мы можем действовать более тонко. А механизм полиморфизма позволяет расширять не только структуру объекта, но и его поведение. Но это все происходит на технологическом уровне. А на уровне рабочих процессов и бизнес-логики, если об этих механизмах кому-нибудь и известно, то знание это чисто теоретическое.
Представьте себе процесс, нарисованный в красивой BPMN нотации. Как вы станете его расширять или конкретизировать? (Под «конкретизировать» я понимаю создание частного случая процесса. Впрочем, под «расширять» я понимаю примерно это же.) Правильно! Добавляя новые активности и ветвления в уже существующий процесс. Это не повторное использование, это переработка. И такое действие несет все присущие переработке компонента проблемы. Надо разобраться, что следует исправить, найти, где это сделать, протестировать, ошибиться с версиями при развертывании и т.д. Хорошо еще, если вы знакомы с техникой Алистера Коберна и думаете о процессе как о наборе расширений основного сценария. А если в вашем представлении процесс – это граф, то уже никакой process mining не поможет.
Возможно, я сгущаю краски и у кого-то из читателей есть свой рецепт изобретения SOA-сервисов. Может, я чего-то не понял или какую-нибудь важную книжку не прочитал. Если это так, то убедительно прошу поделиться своими соображениями.
Кстати, картинка из этой статьи, по мотивам которой сделан логотип BPM Conference, это “Композиция с красным, синим и желтым” абстракциониста Пита Мондриана
“Как придумывать SOA-сервисы” – elementary – just use BPM (as a trio discipline, tools and practices/architecture) correctly.
A few hints.
“повторное использование достигается применением архитектурных паттернов. А я вот с этим не согласен.” Patterns offer another type of re-useability than services. The latter are supposed to be re-used as-is. The former gives a solution (as a piece of knowledge) which is adjustable in accordance with your needs. Patterns are like cooking recipes – try them and then make variations in accordance with you taste.
“Во времена повышенного внимания к SOA обсуждалось повторное использование фрагментов бизнес-процессов, оформленных в виде сервисов.” a mixture of two things:
1) Unique business processes (across enterprises and industry sectors) are built from a set of common process patterns, e.g. Delegation of Authority Matrix (DAM), Approval, etc. These patterns must be understood and used for business process modelling.
2) Each activity in a business process is supported by 1 or 2 services. Instead of thinking about re-use of these unique services, it is necessary to make them easy to change. Usually, these services are composites.
“Но именно на уровне бизнес-логики представляются наименьшие возможности для обобщения и абстрагирования.” At this level, it is necessary to use DSLs (for processes, business rules, events, roles, etc.). They help you to find business patterns.
“Сервис-ориентированную архитектуру можно рассматривать как некоторый вызов, призыв к бизнесу унифицировать процессы и операции, но не как решение. Какое уж здесь повторное использование, если нам постоянно приходится что-то дорабатывать?” Again, the trick is how to implement unique business processes from standard components, quickly and without breaking a production version.
“Ну а что все же делать с бизнес-логикой? На мой взгляд, на техническом уровне эта задача вообще не решается.” Sure, an architectured combination of various tools and methodologies is required (as in the chess game).
The main question “на техническом уровне” is how to make composites.
Thanks,
AS
Александр, я и хочу увидеть конкретные примеры того как BPM или какая-либо другая дисциплина позволяет придумывать reusable компоненты. Выше я привел пример компонента, используемого для сбора и отображения сообщений. Мы можем сделать хранилище сообщений, пользовательский интерфейс для их поиска и просмотра и программный интерфейс для добавления. Если мы абстрагируемся от содержания сообщения и, например, позволим добавлять через API не только текст, но и экранные формы в HTML, то получим достаточно универсальный компонент. Такой компонент можно использовать в нескольких решениях без дополнительных доработок. Единственный пример аналогичного повторно используемого решения для процессов, который я знаю – это business rules engine. Можете ли Вы привести еще какой-нибудь пример?
Спасибо.
OK. We work between two universes – unique processes (in the mind of business) and standard&reusable services (in the hand of IT). Obviously, it is necessary to add some “lubrication” between these universes. I think that patterns serve as such a lubrication:
1) Provide a library of process patterns and their implementations
2) Model unique business processes with patterns (which are adaptable) – see http://improving-bpm-systems.blogspot.ch/2011/06/practical-process-patterns-dip.html
3) Provide a library of standard services to implement process patterns
4) Provide a standard mechanism for composing standard services into process-specific services
BRE or decision management is a proven coordination technique with its DSL. Another useful DSL is BPMN (although there is no standard API). Yet another candidate is EPN (or dispatch service).
Thanks,
AS
Я на практике использовал 2 метода для выявления сервисов:
Предварительные замечания:
Методы не претендуют на полноту и универсальность, но их применение я считаю необходимым условием движения в сторону SOA.
Здесь под архитектором предприятия понимается роль, ответственная за общую IT-архитектуру предприятия, некое подмножество функций полноценного Enterprise Architect.
Опыт, описанный в каждом разделе описывается в среде не IT-компании и не традиционно выскотехнологичных секторов бизнеса – коммуникации, финансы.
1) Выявление близости функций по используемой информации
В отсутствии какой-то сколько-нибудь общей модели информации говорить о SOA бессмысленно.
Связь между сервисами через общие информационные сущности случается раньше, чем использование сервисами других сервисов.
Если работать в подходе моделирования данных концептуальная – логическая-физическая архитектура данных, то обычно архитектор предприятия опуститься
ниже концептуальной + верхнеуровневой логической модели просто физически не успевает, однако и на этом уровне прекурсоры к общим сервисам бывают вполне видны.
Предполагается, что архитектор решения/системный аналитик владеет логической схемой своего решения и совместно с архитектором предприятия могут выявить общие поведенческие элементы, использующие общую информацию
Таким образом удавалось выявлять и создавать общие сервисы, при том, что в явном виде никакого SOA проекта не существовало.
2) Использование версий реализации сервиса
Обычно проанализировать сверху вниз весь бизнес нет возможности, поэтому при подходе снизу вверх, близком к agile, на практике оказалась полезна изложенная ниже схема:
Разделяется понятие сервиса и версии сервиса. Делается правдоподобное предположение о том, что функционал сервиса со временем в основном расширяется.
Для новых потребителей сервиса, которым требуется расширение его возможностей, выпускается новая, расширенная, версия.
Все остальные потребители остаются на своих версиях и мигрируют на более новые версии по необходимости/при возможности.Так как возможности сервиса в основном расширяются,реализация сервиса остается одна на все используемые версии, для старых версий она работает в режиме обратной совместимости.
Таким образом достигается общее использование сервиса через частное использование его различных версий
Игорь, спасибо за то, что поделились опытом. На мой взгляд, методы полезные.
При использовании первого метода не сталкивались ли Вы с тем, что в разных системах набор свойств и отношений одного и того же объекта довольно разный? Например, сотрудник в учетной системе характеризуется должностью, зарплатой, позиционным уровнем. А в системе управления проектом тот же сотрудник характеризуется ролью, списком задач и т.д. Иногда эти данные пересекаются, например, человек в отпуске, иногда нет. Идея общих сервисов данных витает в воздухе и порой приземляется в проект MDM. Но помогает ли это повторному использованию не информации, а функционала?
Модель данных МДМ может служить основой всей корпоративной модели данных.
Отслеживание используемых в постановке исходных задач сущностей до исходных мастер-данных позволяет выявлять потенциальные пересечения
по функциональности между приложениями/сервисами. Если, например, мастер-данные собираются использовать в новой системе в режиме обогащения – исходные мастер-данные + нечто бизнес-специфичное, необходимо проверить, с какой и чьей точки зрения эти данные там ведутся, а далее возможны варианты.
Чтобы не теоретизировать, рассмотрим какую-нибудь условно-конкретную ситуацию:
Например, имееются мастер-данные:
физ.лицо ->сотрудник компании (-> по аналогии с Archimate обозначим наследование)
Пусть уже имеется использование его данных в HR системе тестирования HRSystem1
сотрудник компании -> тестируемый
тестируемый уже считаем за границами мастер-данных, специфическая для HR роль.
Приходит заявка на передачу данных в очередную, например планируемую к разработке/закупке/внедрению HR систему HRSystem2.
И тут начинаются самые разные варианты:
Если, например, HRSystem2 также является системой тестирования, и функции систем ничем значимо не отличаются, становится вопрос о повторном использовании сервисов, предоставляемых этими приложении только в одном из них.
сотрудник компании -> тестируемый
Если HRSystem2 является системой оценки, то возникает вопрос о необходимости координации систем тестирования HRSystem1 и оценки HRSystem2. И здесь в завивмости от требований возможна и репликация результатов опроса
HRSystem1->HRSystem2, и координация формализованных бизнес-процессов средствами BPM. Это при условии, конечно, что в компании в данной области имеет место процессное управление.
сотрудник компании -> оцениваемый сотрудник
Возможны и более сложные варианты – первая система может тестировать по Методике 1, вторая – по методике 2, на этом месте с моделью данных имеем спецэффект:
сотрудник компании -> тестируемый->тестируемый по методике 1 (HRSystem1)
сотрудник компании -> тестируемый->тестируемый по методике 2 (HRSystem2)
И тут развертывается широкий спектр возможностей потенциальной реализации на сервисном уровне в зависимости от ответов на ряд вопросов, которые возникают вокруг потенциального использования сущности тестируемый:
Как выбирается методика тестирования методологически/инструментально?
Кто пользователь общего результата, какие у него инструменты?
Кто и как инициирует процедуру тестирования?
Здесь, в зависимости от требований и имеющегося IT-окружения возможны и композитные сервисы, и сервисы уровня представления, и хореография.
Ну и еще раз, общая модель данных – это одно из средств для выявления сервисов, но далеко не единственная. Она становится единственной при отсутствии конкретных ответственных за ведение списка сервисов, их повторное использование и развитие, а также реальной поддержки SOA-инициатив со стороны руководства.
На тему Service Identification в свое время не писал только ленивый, в качестве иллюстрации пример от IBM:
https://www.ibm.com/developerworks/data/library/techarticle/dm-0803sauter/