Главный архитектор (chief_architect) wrote,
Главный архитектор
chief_architect

Влияние СОА на бизнес-архитектуру

Статья подготовлена для майского номера журнала "Директор ИТ"

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

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

Кубики сервисов
Сегодня сложно однозначно сказать, откуда пришла идея сервис-ориентированной архитектуры – из бизнеса или из ИТ. Хочется верить, что это были технари, однако у нас достаточно примеров обратного для того, чтобы в этом начать сомневаться. Например, сервис-ориентированная структуризация бизнеса пластиковых карт, возможность выделения услуг обслуживания пластиковых карт и продажа другим банкам услуг обслуживания появились далеко не благодаря, а скорее вопреки присутствию ИТ в этом сегменте. Другим, ярким примером реструктуризации бизнес-процессов и выделения бизнес-сервисов является не так давно появившиеся бюро кредитных историй, которые ведут кредитные истории заемщиков и по запросам предоставляют банкам информацию о заемщиках. В процессе обработки кредитной заявки и принятия решения о выдаче кредита банк может направить запрос в одно или несколько бюро кредитных историй. Информация о заемщике, полученная из бюро, влияет на скоринговый балл, который формируется на основании множества параметров. Отметим, что этот сервис предоставляется банку внешней компанией и является платным. Этот факт должен учитываться при проектировании бизнес-процессов, связанных с обработкой кредитных заявок. Ряд функций очевиден. Например, до отправки запроса в бюро, целесообразно вначале проверить информацию, уже имеющуюся в банке. В том числе, наличие кредитов у заемщика в банке, наличие у заемщика перед банком просроченной заложенности по текущим кредитам. Но гораздо больше здесь менее очевидных решений, связанных, например, с возможной частичной или полной потерей связи с бюро. Банк должен решить, готов ли он нести риски принятия решений на неполной информации, будет ли в этом случае процесс принятия решения и выдачи кредита по прежнему сквозным и непрерывным. Если будет, то с какими ограничениями. В случае более консервативной стратегии ведения бизнеса банк может принять обратное решение ¬—процесс кредитования приостанавливается до восстановления связи с бюро. Это решение может распространяться на заявки, сумма кредита которых превышает определенную сумму. Таким образом, проектирование бизнес-процесса подобно конструированию, в котором процесс собирается из типовых блоков, устоявшихся в банке или предоставляемых внешними компаниями сервисов. После подобной «сборки» модели бизнес-процесса целесообразно выполнить имитационное моделирование для оценки сходимости, устойчивости и производительности процесса, оценки рисков, расчета себестоимости реализации той или иной услуги, ведь только на основании точного расчета этой себестоимости банк может принять решение о величине тарифа на ту или иную услугу.
Очень часто в процессе моделирования изменение порядка вызова отдельных сервисов в бизнес-процессе может неожиданно повлиять на время его выполнения, на его стоимость, на риски и другие ключевые показатели эффективности. В ходе такого проектирования бизнес-аналитик принимает решения о целесообразности автоматизации того или иного сервиса. Далеко не всякая повторяющаяся операция с точки зрения бизнес-аналитика является программной компонентой или реализуется с использованием программной компоненты, но при этом может и должна выделяться и рассматриваться в последующем в виде обособленного сервиса, который может быть повторно использован в других бизнес-процессах. И здесь искусство проектирования бизнес-процесса подобно искусству программирования.

Аналогии проектирования
Не трудно видеть, что проектирование бизнес-процессов сегодня очень похоже на проектирование программных комплексов. Жизненный цикл разработки и внедрения новых услуг во многом перенял черты разработки и внедрения информационных систем – все те же фазы анализа, проектирования, тестирования, внедрения. И даже прекращение продаж продукта или услуги соответствуют фазе вывода информационной системы из эксплуатации. При этом проектирование бизнес-процессов, проектирование бизнес-архитектуры находится на уровень выше, над проектированием информационных систем, проектированием системной архитектуры. Проектирование и управление архитектурой предприятия начинается уже на уровне бизнес-архитектуры.
 Безусловно, все эти виды работ при проектировании бизнес-процессов в том или ином виде выполнялись и раньше. Неправильно утверждать, что раньше не было ни технологических карт, ни функционально-стоимостного анализа. Одного раньше не было точно – не было структуризации бизнеса, не было понятия бизнес-сервисов, как устоявшейся, последовательности бизнес-операций, повторяющейся и используемой в различных бизнес-процессах. Посмотрим хотя бы, на методологию IDEF или на ее прародителя – методологию SADT, которая возникла в конце 60-х годов прошлого столетия в ходе революции, вызванной структурным программированием. Структурный анализ зародился на уровне бизнес-архитектуры и ставил задачи структурной декомпозиции функционала проектируемой системы, при этом зрелость программной индустрии все еще находилась на уровне ниже, на уровне структурного программирования. Однако в то время, в период становления структурного анализа еще не шло никакой речи ни об объектном программировании, ни тем более о сервисах на уровне программирования, на уровне. Даже спустя почти двадцать лет после появления методологии SADT в предисловии к известной книге «Методология структурного анализа и проектирования SADT (Structured Analysis & Design Technique)», написанным в 1986 году Дугласом Т. Россом, он говорит о функциональном моделиовании, но речи про сервисы не идет. Спустя еще десять лет, в 90-х годах в методологии ARIS была сделана слабая и неуклюжая попытка ввести типизацию услуг и операций при реализации продукта, что находит отражение в матрице продуктов-сценариев. Однако эта попытка заканчивается на верхнем уровне, на уровне матрицы, на нижнем уровне, уровне декомпозиции все сценарии различаются, и каждый имеет свое, отличное от других описание и реализацию.
Потребовалось еще несколько лет, чтобы Организация по распространению открытых стандартов структурированной информации ввела определение СОА: «Сервисно-ориентированная архитектура — это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение». Однако и здесь мы видим, что сервисная ориентация архитектуры покрывает и остается все же на уровне системной архитектуры, не затрагивает уровня бизнес-архитектуры.
И только с появлением BPEL в начале уже нового столетия концепция сервиса расширилась – появилась оркестрация для «гранулирования» мелких сервисов в более крупные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов.
К сожалению, большинство архитекторов, использующих СОА, до сих пор видят и понимают лишь технический термин – термин уровня системной архитектуры, рассматривают понятие сервиса как повторно используемой функциональности прикладной компоненты на уровне системной архитектуры. Немногие архитекторы решаются сделать еще шаг и подняться на уровень бизнес-архитектуры, которая является по своей сути первичной по отношению к системной архитектуре. Именно бизнес-архитектура диктует требования к системной архитектуре, а не наоборот. Однако оставаясь на уровне системной архитектуры, проектировщик остается вечным заложником бизнес-архитектуры и узкой интерпретации термина СОА. Поднимаясь на уровень выше, перерастая в бизнес-проектировщиков мы начинаем с проектирования эффективных бизнес-процессов и, как следствие, эффективных продуктов и услуг, одновременно с продуктами и процессами разрабатывая систему ключевых показателей эффективности продуктов и процессов. Нельзя гарантировать должного уровня качества обслуживания клиентов, оставаясь только на уровне информационных систем. Для этого необходимо подняться на уровень продуктов, услуг и бизнес-процессов.

Проектирование XXI века
В докризисный период экстенсивное развитие вполне удовлетворяло потребности бизнеса, поэтому не всегда находилось время, силы и желание, чтобы заниматься реструктуризацей бизнеса, выделением бизнес-сервисов, их оптимизацией. Во время кризиса и в настоящее время, в посткризисный период сокращение бюджетов обуславливает, вынуждает задуматься над поиском решений, позволяющих эффективно повторно использовать уже имеющиеся не только ресурсы в виде приложений и баз данных, но скорее элементов бизнес-процессов, бизнес-операций.
И опять на мы можем легко наблюдать взаимное проникновение бизнеса и ИТ. В последней редакция ITIL 3 основной акцент делается на том, что одиночные ИТ-процессы не дают достаточных гарантий успеха для бизнеса. Наибольший эффект от ИТ-процессов достигается, когда процессы полностью охватывают стратегию Бизнеса и напрямую взаимосвязаны с его  результатами. В разрезе деловой ценности выделяется объединение целей бизнеса и ИТ, интеграция ИТ-сервисов в бизнес и восприятие ИТ в качестве бизнеса. Развитие методологии ITIL стала ответом на новые потребности участников бизнес- и ИТ-сообщества.
Таким образом имея сегодня достаточно хорошо структурированную библиотеку лучших ИТ практик, нам не нужно «с чистого листа изобретать велосипед», а достаточно рассудительно и грамотно воспользоваться уже имеющимся знанием и отстроить процессы на уровне бизнеса по образцу и подобию. «Деловая ценность» сервиса, являющаяся основным критерием существования сервиса, применима не только и не столько к ИТ-процессам, но и к бизнес-процессам. Каталог сервисов преломленный на уровне бизнес-архитектуры в Каталог банковских продуктов, услуг и тарифов уже давно используется бизнес-аналитиками. Здесь степень взаимопроникновения достаточно высока. Каждый продукт и услуга имеют описание в виде паспорта с установленными тарифами и с четко определенными показателями эффективности и качества. Разработку и внедрение новых банковских продуктов и услуг следует вести в соответствии с утвержденным регламентом, который по свой структуре и содержанию является отражением регламентов проектирования и разработки информационных систем.

Виктор Галактионов В. И., АКБ «РосЕвроБанк», с автором можно связаться по электронной почте: V.Galaktionov@roseurobank.ru
Tags: СОА, бизнес-архитектура
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments