CC BY-NC-ND
61
О ПОДХОДЕ К АРХИТЕКТУРЕ, ПОСТРОЕНИЮ И РАЗВИТИЮ ИНФОРМАЦИОННЫХ БИЗНЕС СИСТЕМ НА ОСНОВЕ BPM И SOA1
А.В. Самарин,
кандидат технических наук, независимый консультант. Адрес: Pres-du-Marguiller 18, Arzier, 1273, Switzerland, e-mail: samarin@bluemail.ch
Ключевые слова: управление бизнес-процессами, жизненный цикл, активно-гибкая разработка, активно-гибкое развитие.
Актуальность создания гибких информационных бизнес систем
Повышение эффективности предприятия — это постоянная и нетривиальная задача в наше время. Пользователи всегда хотят быстрого совершенствования информационных бизнес систем (ИБС). Довольно часто, небольшие с точки зрения бизнеса изменения оказываются непредсказуемыми с точки зрения 1Т департамента. Чтобы справляться с постоянным потоком таких модификаций, ИБС должна быть надлежащим образом спроектирована и разработана — она должна быть «гибкой».
В настоящее время, существующая практика разработки программного обеспечения не в состоянии обеспечить надлежащее решение этой проблемы. Обычно ИТ приложение создается с
установленным набором функций, и затем оно неоднократно переделывается, чтобы приспособиться под новые требования бизнеса и технологический прогресс.
Не удивительно, что [1]:
♦ «80% стоимости на всем жизненном цикле ИТ приложения приходится на фазу сопровождения», и
♦ «80% сопровождения происходит из-за нереализованных или непредвиденных требований; только 20% происходят из-за ошибок или проблем надежности».
Вышеприведенные данные являются средними — в некоторых случаях разработка ИТ приложения может составить только 5 % от его общей стоимости на всем жизненном цикле. Но более тревожным является то, что эти значения не известны широкому кругу лиц, вовлеченных в ИТ, — последние обычно дают другую оценку (рис. 1).
1 BPM — Business process management — Управление бизнес-процессами SOA — Service oriented architecture — Архитектура, ориентированная на службы
Сопровождение
Разработка
1 — Средняя оценка
по ИТ отрасли
2 — Ситуация у клиента
3 — Распространенное мнение
ИТ специалистов
80%
20%
95%
5%
40%
60%
1
2
Рис. 1. Соотношение затрат на сопровождение и разработку программного продукта на всем жизненном цикле
Сложность создания гибких ИБС состоит в том, что любая ИБС — это сложная социально-техническая система с огромным количеством участников. Такая система будет успешной только в том случае, если будут учтены интересы всех лиц, участвующих на всех этапах жизненного цикла этой системы. Ниже приведены основные группы лиц, вовлеченных в ИБС, как социально-техническую систему; как правило, каждая такая группа работает только с некоторой частью ИБС.
♦ клиенты предприятия
♦ высшее руководство предприятия
♦ топ-менеджеры предприятия
♦ руководители различных подразделений
♦ сотрудники
♦ руководители проектов
♦ бизнес-аналитики
♦ руководители 1Т департамента
♦ архитекторы 1Т департамента
♦ разработчики 1Т департамента
Опыт создания социально-технических систем показывает, что их восприятие людьми зачастую оказывается важнее самой системы. Другими словами, то как Вы делаете, важнее того, что Вы делаете. Поэтому кто-то должен концептуально понимать и уметь доходчиво объяснять любому заинтересованному лицу, как будущая система решит вопросы, волнующие именно его; как система будет работать для этого человека; как система улучшит работу этого человека.
Известно, что наилучший способ обеспечения концептуального единства [2] — это сосредоточить разработку концепций в небольшой архитектурной группе, состоящей из единомышленников. Такая группа переводит требования клиента (например,
высшее руководство предприятия) в осуществимый план (например, построение или развитие гибкой ИБС) и контролирует выполнение этого плана другими (например, 1Т департаментом предприятия или внешними компаниями).
В данной работе предлагается практический архитектурный подход к обеспечению высокого уровня гибкости (способности изменяться не теряя тождественности [3]) ИБС на основе согласованного применения ВРМ и БОА. Использование этого подхода позволяет гарантировать эффективную работу такой архитектурной группы.
Предприятие с точки зрения процессного управления
Для управления производительностью предприятия как сложной системой, большинство предприятий используют принцип обратной связи (рис. 2), позволяющий адаптироваться к внешней бизнес -экосистеме путем выполнения определенной последовательности действий:
1. измерение хода исполнения производственно-хозяйственной деятельности (обычно такие измерения представлены в форме различных метрик или показателей, например, процент возвращающихся клиентов),
2. вычленение из внешней бизнес-экосистемы важных для предприятия событий (например, законов или новых потребностей рынка),
3. определение стратегии развития бизнеса предприятия,
4. реализация принятых решений (путем внесения изменений в бизнес-систему предприятия).
Бизнес-экосистема
Внешние события и внешняя информация
ь
с
©
Бизнес-система предприятия
Управляющая часть
©
Изменения
>
© ©
ч
Показатели
г Исполнительная часть
Ч У
Выход
Рис. 2. Применение принципа обратной связи в рамках предприятия
В соответствии с классической рекомендацией Эдварда Деминга [4], все усовершенствования должны осуществляться циклично, непрерывно и с
3
конкретной проверкой на каждом цикле. Степень и частота этих усовершенствований зависят от конкретной ситуации, но рекомендуется делать такие циклы достаточно компактными.
Эффективная реализация таких усовершенствований требует рационального построения предприятия, а наиболее современной концепцией организации работы предприятия является процессное управление. Мир бизнеса давно понял (см. такие методики, как TQM, BPR, Six Sigma, Lean, ISO 9000, а также [5]), что службы и процессы — это основа функционирования большинства предприятий. Множество предприятий используют процессное управление для организации своей производственно-хозяйственной деятельности, посредством портфолио бизнес-процессов и методов управления ими.
Процессное управление, как управленческая концепция, постулирует целесообразность координации деятельности отдельных служб предприятия с целью получения определенного результата при помощи явно и формально определенных бизнес-процессов. При этом, службы — это операционно независимые функциональные единицы; у предприятия может быть много элементарных нано-служб, которые организованы в мега-службу (собственно предприятие) как показано на рис. 3.
Бизнес-экосистема
i
Реализвация улучшений
Описание процесса
Бизнес-система предприятия 4 Управляющая часть '•.
Решение по улучшениям
Описание процесса
, Исполнительная '■. часть
Координация процесса
Описание процесса
I : : —■ —>
п □ □ о Службы —
Выход
Рис.3. Образец обратной связи для процессно-управляемого предприятия
Системная точка зрения на предприятие
Предприятие, как сложная система, — это динамичная совокупность большого количества различных артефактов. Дополнительно к упомянутым выше процессам и службам, необходимо отметить такие артефакты как правила, события, данные, показатели производительности, роли, документы,
и т. д. (В этой статье автор концентрируется прежде всего на артефактах, непосредственно связанных с бизнес-процессами, то есть не рассматриваются типичные технические артефакты, такие как серверы, базы данных, операционные системы, сети, и т. д.).
Любоее предприятие подвержено различным потенциальным изменениям в различных аспектах: политика и приоритеты руководства, организационные структуры, бизнес-процессы, внешние обязательства (отраслевые нормативы), технология, уровень компьютеризации в пределах предприятия, акционеры, культура пользователей, размер и сложность решаемых задач и т.п. Большинство этих изменений выливаются в изменения различных артефактов. С системной точки зрения, беспроблемное развитие предприятия означает, что любой артефакт можно легко изменить, не вызывая отрицательных эффектов в других местах системы.
Поскольку артефакты взаимозависимы, то необходима архитектура, которая бы руководила построением, использованием и развитием всех артефактов и взаимозависимостей между ними. Таким образом, развитие предприятия — это управление развитием всех его артефактов и взаимозависимостей между ними одновременно как целостной системой. Более полный и более точный охват взаимозависимостей между артефактами позволяет получить больше знаний о реальном функционировании предриятия, принимать более рациональные решения и проводить более глубокую оптимизацию.
Архитектурные принципы построения гибких ИБС
Для достижения высокого уровня гибкости ИБС, автор предлагает использовать следующие основные архитектурные принципы.
Любой артефакт может иметь много версий для отражения изменения артефакта в течении его жизненного цикла.
Все артефакты постоянно улучшаются или усовершенствуются:
артефакты переводятся в электронную форму (то есть оцифровываются);
артефакты экстернализируются, то есть становятся доступными как отдельные и явные элементы (для каждого артефакта хотелось бы знать правила его именования, его владельца, сложность, объем, частоту модификаций, потребности в защите, отсле-живаемость и, вообще, полный жизненный цикл); артефакты виртуализиризуются, то есть становят-
ся независимыми от специфических ИТ ресурсов, таких как серверы, базы данных, форматы, браузеры, и т.д. (что необходимо для того, чтобы транспортировать некоторые артефакты с целью их использования в других артефактах).
Все взаимозависимости между артефактами моделируются явным образом, то есть с использованием языков и методов моделизования, явно использующих эти артефакты.
Все модели делаются исполняемыми, то есть такая модель формально переводится в работающую программу, анализ работы которой является основой для утверждения правильности модели.
Применение этих приципов направлено на выявление всех скрытых взаимозависимостей и их структурирование. Ниже рассматривается один из примеров взаимозависимости между артефактами.
Бизнес процессы как сложные взаимозависимости между артефактами
Бизнес-процесс работает с несколькими типами артефактов, которые можно быстро идентифицировать, анализируя общеизвестное определение процесса: кто (роли) делает что (объекты), когда (координация действий), почему (правила), как (действия) и скакимрезультатом(показатели производительности). Таким образом, бизнес-процесс — это сложная и динамическая взаимозависимость между многими артефактами.
Как уже упоминалось выше в секции 2, бизнес -процессы, ассоциируются с областью знаний «Управление бизнес процессами», или BPM. Однако, в настоящее время, не существует устоявшегося общего понимания, что же такое BPM. Автор считает [6], что BPM охватывает три различные концепции (рис. 4):
1). Дисциплина BPM — организация функционирования и развития предприятия на основе явных бизнес-процессов, которая позволяет моделировать, автоматизировать, выполнять, контролировать, измерять и оптимизировать потоки работ, охватывающие программные системы, сотрудников, клиентов и партнеров в пределах и вне границ предприятия. Дисциплина BPM рассматривает все операции с бизнес-процессами (моделирование, исполнение и т.п.) как единое целое.
2). BPM-система предприятия — портфолио всех бизнес-процессов предприятия, а также методов и инструментов разработки, исполнения и развития этого портфолио.
3). BPM Suite или BPMS — новый класс корпоративного программного обеспечения для создания BPM-системы предприятия.
На предприятии всегда есть какие-то зачатки ВРМ-системы, но как ее индустриализировать?
Рис. 4. Три концепции ВРМ
Таким образом, бизнес-процессы дожны быть явными и исполняемыми (what you model is what you execute). Кроме этого, должно использоваться единое описания бизнес-процессов, которое одновременно используется как:
4- модель при проектировании системы,
♦ основа для технологического плана при создании системы,
♦ исполняемая программа при координации работ, и
♦ документация, легко понимаемая всеми вовлеченными в бизнес-процесс сотрудниками.
По существу, явные и исполняемые бизнес -процессы являются тем артефактом, на котором сходятся точки зрения бизнеса и ИТ.
Гибкие ИБС как необходимое условие индустриализации BPM-системы предприятия
Разработанный автором [7-14] архитектурный подход для обеспечения высокого уровня гибкости ИБС основывается на совместном использовании BPM и архитектуры, ориентированная на службы, или SOA. Последняя предлагает наилучшую (на сегодняшний день) виртуализацию и определяется следующим образом: SOA — это архитектурный стиль для построения сложных программных систем в виде набора универсально доступных и взаимозависимых служб.
Говоря о совместном использовании BPM и SOA (рис. 5), необходимо подчеркнуть, что BPM, выявляя артефакты и взаимозависимости между ними, обеспечивает необходимый контекст для определения служб (например, степень их детализации). SOA, в свою очередь, обеспечивает рекомендации для реализации, выполнения и руководства службами.
Другие важные характеристики этого архитектурного подхода перечисленны ниже.
Процесс как явная координация служб Литература
1. Pressman, R.S.: Software Engineering: A Practitioner's Approach, 1992, McGraw Hill
2. Brooks, F.P.: The Mythical Man-Month. Reading, MA: Addison Wesley, 1995.
3. Regev, G., Wegmann, A.: A Regulation-Based View on Business Process and Supporting System Flexibility, Proceedings of the CAiSE'05 Workshop, p. 91-98.
4. www.deming.org.
5. Harmon, P.: Future of BPM, www.bptrends.com/ publicationfiles/IIR-HarmonTalk-5-08.pdf.
6. Самарин, А.: Эталонная модель BPM, Открытые системы, №1, 2009 (http://www.osp.ru/ os/2009/01/7195011/).
7. Samarin, A.: ISO: integrating the WEB and document management, presentation at Documation conference, Paris, France, 2001 (http://www.improving-bpm-systems.com/pubs/OT-documation.pdf).
8. Samarin, A.: Agile SOA Framework For Process Automation And Integration, www.ebizq.net, 2004 (http://www.improving-bpm-systems.com/pubs/ article-ebizq-AS.pdf).
9. Samarin, A.: From agile development to agile evolution of enterprise systems, presentation at EuroPython Conference, Geneva, Switzerland, 2006 (http://www.improving-bpm-systems.com/pubs/ From-agile-development-to-agile-evolution-of.pdf).
10. Samarin, A.: Three pillars of a practical architectural framework: BPM, SOA and ECM, presentation at the Open Group's enterprise architecture practitioners conference, Lisbon, Portugal, 2006 (http://www. improving-bpm-systems.com/pubs/Conf2006.pdf).
11. Samarin, A.: Architecting enterprise BPM systems for optimal agility presentation at «Architecture and Process» conference www.architecture08.com, April 2008, Washington DC, USA (http://www.improving-bpm-systems.com/pubs/Architecting_enterprise_ BPM_systems_for_optimal_agility.pdf).
12. Samarin, A.: How to simplify the evolution of business process lifecycles In conjunction with CAiSE'08. The 9th Workshop on Business Process Modelling, Development, and Support BPMDS'08 Business Process Life-Cycle: Design, Deployment, Operation & Evaluation. 16-17 June 2008, Montpellier, France (http: //www.improving-bpm-systems.com/ pubs/AS-BPMDS08.pdf).
13. Samarin, A.: Architecting enterprise BPM systems for optimal agility a keynote presentation at the «Architecture World 08», 18-19 June 2008, Bangalore, India (http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote. pdf).
14. Samarin, A.: Towards executable models within BPM a track presentation at the «Architecture World 08» 18-19 June 2008, Bangalore, India (http://www.improving-bpm-systems.com/pubs/AS-AW08-track.pdf).
15. OMG (www.omg.org) specification: Business Process Modelling Notation, 2008
I— Службы, используемые процессом
Рис. 5. Процессы и службы
♦ Использование архитектуры для уменьшения сложности путем структирирования взаимозависимостей между артефактами.
♦ Предложение по эталонной модели BPM.
Внимание на наиболее сложный аспект построения ИБС, которым являются люди
♦ Процедура моделирования бизнес-процессов в BPMN [15] для их быстрого макетирования.
♦ Правила и рекомендации для согласованного использования различных информационные технологий: ECM, BEM, BI, BRM, MDM, ESB, BAM, ITIL и т.п.
♦ Связь с корпоративной архитектурой и интеграция с практикой управления проектами.
Заключение
Данный архитектурный подход использовался для сопровождения производственной системы, автоматизирующей производство приблизительно 3 000 сложных электронных продуктов ежегодно (среднее время подготовки продукта составляло несколько лет). Эта производственная система включала около 50 сотрудников, более 50 типов работ, 3 производственные линии, 40 ИТ-служб и 6 хранилищ данных и документов. Она развивалась в течение нескольких лет, в течении которых были проведены многочисленные функциональные расширения и несколько успешных и нетрудоемких замен версий основных ИТ продуктов. Обслуживание и развитие этой производственной системы потребовало в несколько раз меньше ресурсов, чем при традиционном подходе. ■
