воскресенье, января 18, 2009

Service-Oriented Enterprise Architecture (SOEA)

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

Проблема в том, что пытаясь использовать SOA как инструмент согласования ИТ и бизнеса, ИТ-специалисты остались в своем мире технологий. Начиная разговор о SOA с бизнес-руководством они быстро сползают в специфику реализации и интеграции систем. А бизнесу это, по большому счету, неинтересно. Совсем. Бизнес хочет получить результат. За определенное время, в рамках соответствующего бюджета, с определенным качеством. Всё. Какие Web-сервисы? Какие шины? Какие компоненты?... Классическая подмена информационных технологий чистыми технологиями.

С моей точки зрения, SOA - не о компонентах, шинах и Web-сервисах. Это все - частные инструменты реализации архитектурного подхода к использованию технологий, одним из которых является SOA. Внедрить SOA нельзя. Так же, как нельзя внедрить middleware, сервер приложений, ITIL или PMBOK. Это все инструменты достижения цели. SOA - архитектурный и даже, в определенном плане, методологический инструмент рещения задач, стоящих перед ИТ.

Но каковы бизнес-задачи, стоящие перед ИТ? Что заставляет ИТ-индустрию создавать такие инструменты как SOA? Таких задач перед ИТ, по большому счету, три:
  1. обеспечить автоматизацию бизнес-процессов, определяющих деятельность организации
  2. предоставить такие технологические средства, которые приведут к инновациям в основной деятельности
  3. облегчить оптимизацию процессов ее деятельности

К сожалению, ИТ чаще всего фокусируется только на первой задаче. Ко второй задаче ИТ чаще всего подходит реактивно, реагируя на сумасшедшие на первый взгляд “хотелки” бизнеса, но так или иначе справляется с этим. А вот третья задача хорошо если “схлопывается” до сбора требований или описания бизнес-процессов, но к сожалению редко когда включает в реальной жизни полноценный анализ и модернизацию сквозных процессов операционной деятельности. Максимум до чего доходят руки – до процессов самого ИТ-подразделения, благо COBIT и ITIL уже аккумулировали соответствующие подходы. Но вот что интересно, берем понятия сервиса, ИТ-сервиса и бизнес-сервиса в ITIL v3:
  • Service
    A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.

  • IT Service
    A Service provided to one or more Customers by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the Customer's Business Processes. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Level Agreement.
  • Business Service
    1. An IT Service that directly supports a Business Process, as opposed to an Infrastructure Service which is used internally by the IT Service Provider and is not usually visible to the Business.
    2. The term Business Service is also used to mean a Service that is delivered to Business Customers by Business Units. For example delivery of financial services to Customers of a bank, or goods to the Customers of a retail store. Successful delivery of Business Services often depends on one or more IT Services.
Смотрим на определение бизнес-сервиса. А вот тут как раз “засада”. С одной стороны, это называется Business Service. С другой – определяется как IT Service (точгда чем он отличается от бизнес-сервиса? Еще одной прослойкой архитектурного пирога?). Проблема заключается в том, что корни ITIL лежат в IT Operations - деятельности по эксплуатации информационных систем и, чего уж греха таить - в первую очередь оборудования и инфраструктуры. Давайте абстрагируемся от ИТ и от первого варианта определения бизнес-сервиса, предлагаемого ITIL v3. Возьмем его второй вариант. И те же E-mail или видеоконференц-связь рассматриваем как доступные бизнес-пользователям бизнес-сервисы, предоставляемые ИТ-подразделением, наравное с тем как тем же пользователям предоставляются соответствующие финансовые сервисы (начисление зарплаты, производимое бухгалтерий) и т.п.. Все сразу встает на свои места. Тогда первый вариант определения необходимо либо отбрасывать, либо интерпретировать как бизнес-сервис, предоставляемый IT, наравне с бизнес-сервисами HR, финансового подразделения, отдела продаж и т.п. Т.е. IT Service в ITIL является на самом деле подмножеством бизнес-сервсов. Проблема ITIL заключается в том (и это видно например по обсуждению в его третьей версии и SOA и Enterprise Architecture), что в большинстве случаев при постановке ITSM-процессов в ИТ-департаментах, создании каталога услуг, бизнес-сервисы интепретируются в соответствии с первым вариантом определения, а не со вторым, ограничиваясь только ИТ и, концентрируясь на системах и инфраструктуре, что естественно, так как речь идет об IT Operartions.

Забудем об IT Operations, но вспомним о разработчиках. Они привыкли мыслить в терминах систем и интерфейсов (конечно, а данном случае имеются в виду API, а не user interface). И используя понятие сервиса, разработчики понимают под ним интерфейс, удовлетворяющий определенным правилам единого описания (по-сути контракта) и технологического (программного) обращения к нему. В таком контексте система несет определенный функционал, а интерфейс системы определяет сервис, предоставляемый системой по автоматизации определенных бизнес-процессов, в рамках соответствующего соглашения - контракта. Тут и возникают ESB, EDA, asynchronous messaging, Web-services (как одна из возможных технологий стандартизации доступа к интерфейсам) и т.п. Но является ли такой вариант интерпретации бизнес-сервисом? Нет. Понятен ли он бизнесу? Категорически нет. Обсуждая SOA, под сервисом в большинстве случаев понимается технологический интерфейс доступа к функциональности системы, а не бизнес-сервис, предоставляемый структурным подразделением или организационной единицей бизнес-пользователям. Вот здесь и лежат корни проблемы превращения SOA в buzzword, описанной в самом начале.

Давайте теперь посмотрим на SOA с другой точки зрения. SOA с самого начала разивалась (пусть и стихийно) для решения одной важной проблемы – описания архитектурного подхода, решающего первую задачу ИТ – автоматизации тех комплексных или корпоративных бизнес-процессов, которые охватывают разные структурные подразделения и поддерживаются разными информационными системами, требующими тесной, но в то же время гибкой интеграции. Но так как речь идет о создании, по-сути единой информационно-технологической инфраструктуры, обеспечивающей деятельность бизнеса, мы естественным образом приходим к тому, что обсуждаем ИТ-часть корпоративной архитектуры предприятия (или как говорят ИТ-архитектуры). И корпоративная архитектура содержит тесно связанные между собой бизнес-архитектуру и ИТ-архитектуру, включая комплексные бизнес-сценарии, бизнес-сервисы, бизнес-процессы, функциональные системы, обеспечивающие автоматизацию бизнеса, а также технологический уровень реализации ИТ-инфраструктуры. Приоритезация функциональных систем, как и выбор технологий и продуктов для их реализации, основан на приоритетах, значимости и других характеристиках предоставляемых бизнес-сервисов и реализуемых бизнес-процессов.

В то же самое время, бизнес-сервисы являются ключевым элементов бизнес-архитектуры, где мы оперируем сквозными бизнес-процессами (бизнес-сценариями), организационной структурой, cost-центрами и другими бизнес-понятиями. Но если мы обсуждаем деятельность ИТ как информационно-технологическую деятельность, значит мы должны четко для себя разделять бизнес-архитектуру и ИТ-архитектуру, информацию и данные, модель бюджетирования со стоимостью сервиса и т.п.

Можно возразить, что SOA как раз о технологиях. Но тогда может не стоит приплетать сюда бизнес и логично опустить бизнес риторику? И честно поставить SOA в один ряд с OOP, AOP, DCE и другими чисто ИТ-шными понятиями.

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

Собственно, в результате такого рода анализа я и пришел к тому, что называю

SOEA – Service-Oriented Enterprise Architecture

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

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

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

Элементы SOEA
(кликните для загрузки диаграммы)


Сервисный взгляд на деятельность организации представляет собой такое видение, в котором ресурсы четко разделены и последовательно представлены в терминах бизнес-сервисов, обеспечивающих выполнение бизнес-процессов с четким распределением ответственности между различными подразделениями и ролями. Этот подход отражает один из ключевых принципов корпоративного управления – separation of duties (разграничение полномочий).

Модель SOEA
(кликните для загрузки диаграммы)

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

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

Реализация бизнес-сервисов и автоматизация выполняемых ими бизнес-процессов обеспечивается функциональными системами.

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

Интеграционная модель в SOEA
(кликните для загрузки диаграммы)


Безусловно, используемые в моей модели SOEA термины имеют и синонимы, которые кому-то более привычны, а для кого-то будут красной тряпкой (все зависит от источника соответствующей интерпретации). Язык определяет сознание. Именно поэтому я собрал термины и их эквиваленты в краткий глоссарий SOEA. Конечно, использование терминов часто определяется контекстом. Не хочу (и, кстати, крайне не приветствую) порождение флейма или тем более религиозных войн. Разные подходы, разные термины – разные системы координат. Я попытался поделиться своей – SOEA.

Ярлыки: , , ,

Комментарии: 9:

Blogger arkanoid сказал(а)...

Ну да, все именно так и должно быть. Я бы сказал, в этом-то, вроде, и была (есть) изначальная идея SOA, которая потом слегка потерялась за технологическими частностями?

вс янв. 18, 11:49:00 ПП  
Blogger Roman Oksyukovski сказал(а)...

Хорошая статья. Сергей, встречали ли Вы реальные примеры использования "правильного" подхода к построению бизнес-архитектуры и alignment'а с ИТ? С удовольствием почитал бы case studies.

пн янв. 19, 05:08:00 ПП  
Blogger Swab сказал(а)...

Сергей, Вы абсолютно правы. Но не совсем :) Давайте отринем условности и расскажем правду.
Что развивает бизнес ? Иновации ? Отнюдь! Бизнес - это продажи! А тут уж все способы хороши. На тесном рынке продать товар , потребительские свойства которого слабо отличаются от конкурирующих, крайне сложно. Так почему бы не выдвинуть рекламный слоган, который позволит продать один продукт под видом другого, более привлекательного? Особенно когда вода мутна и в ней мечется потребитель чуть ли не мгновенно устаревающего продукта, каковым считается ИТ-продукт. В погоне за оптимизацией расходов потребитель способен заглотить любой новый bid, который посулит ему снижение издержек.
К чему я клоню ? Сначала была идея, но она выхолостилась по пути к продукту. Идея структуризации шагов и артефактов проектирования ИТ-систем превратилась в маркетинговый сленг, под чьим соусом продаются залежавшиеся на складе решения. На мой взгляд - SOA нужна поставщикам решений , а не бизнесу-потребителю. Уж сколько раз твердили миру - то "Business on demand", то "Be green", то "Smarter planet". Не удивительно , что потребитель насупился и орет голосом Кубы Гудинга (х/ф Jerry Maguire)- "Show me MONEY!!!!" .
А ему в ответ продавец - "Посмотрите на "гартнеровский квадрат". Видите - наши решения в правом верхнем углу!"

C уважением,
Максим К.

вт янв. 20, 09:05:00 ПП  
Blogger arkanoid сказал(а)...

Ооо, Gartner. И заказчик уходит просветленным, хотя a) Gartner туфта и b) все это, на самом деле, очередной способ заставить клиента забыть, с какой стороны прилавка он стоит.

ср янв. 21, 06:44:00 ДП  
Blogger Сергей Орлик сказал(а)...

2 arkanoid: мне кажется с самого начала используя один и тот же термин SOA, специалисты разделились на два лагеря - те кто рассматривал это в терминах бизнеса (меньшая часть), и те кто рассматривал это в терминах технологий, но все равно пытаясь говорить с бизнесом о "космических кораблях, бороздящих..." - их большинство. Как результат - бизнес ничего не понял, кому-то денег дал, а корабли в подавляющем большинстве случаев не взлетели, потому как посчитать _прямую_ отдачу в деньгах (а именно это обещали многие, начиная продавать идею на основе заимстованных у вендоров с TCO-калькуляторов) можно без излишнего лукавства лишь для очень небольшого числа интеграционных проектов. Вот и получилось то что получилось в восприятии SOA - причем и того и другого, потому как слово одно и шлейф уже тянется.

2 Roman Oksyukovski: один пример приведен в следующем посте про опыт HP. Видел пару других живьем. Существенно о большем - читал. Про свои проекты говорить рано, потому как либо делал лишь элемент мозаики (т.е. использовалась моя модель, но я не участвовал в реализации от и до), либо что-то находится еще в процессе. Но если бы не был уверен в определенной, пусть и опосредованной на первых порах отдаче, поверьте, не писал бы этом :)

2 Swab: безусловно без вендорских интересов здесь не обошлось, как и вообще в мире технологий. но всегда ли это плохо? развитие новых технологий происхоодит на какие-то деньги - и этот цикл непрерывен и продажи финансируют и research и development. Приведу аналогию из автомобильной индустрии - есть концепт-кары, есть модели, которые ставятся на конвейер. К сожалению не всякий блестящий концепт становится столь же блестящей моделью. С SOA произошел похожий случай, как если бы все сказали - о! кроссоверы! но один производитель назвал сделал ьбы его не в формате кашкая, а патрола, другой не куги, а фьюжена, а третий бы зарегистрировал торговую марку кроссовер и сделал бы его трех-колесным... Просто теперь когда мы говоим SOA надо сразу задавать контекст - мы говорим о технологической архитектуре, подходе к интеграции приложений, уточняя детали (шина ли, веб-сервисы ли, адаптеры ли и т.п.) или бизнес-сервисы как развитие фукнционального подхода к организационной модели, как это связано с бизнес-процессами и т.д.

P.S. А я вот Forrester еще читаю - это очень плохо? ;)))

пт янв. 23, 12:15:00 ДП  
Blogger Swab сказал(а)...

2 Сергей Орлик :
Возможно, я заблуждаюсь. Но обучать бизнес методологии перестроения своего орг. дизайна не дело ИТ-вендоров. Для этого существуют бизнес-консалтеры . А они не проявляют интереса к продаже этой мотодологии. Точнее, не так. Они имеют уже не первый десяток лет свои методолгии, которые потом заново изобрели как SOA (пример - PWC со своими BCM и последующей SOMA). Основной довод при продаже SOA - "в эпоху динамичности бизнеса нельзя его стеснять костной инфраструктурой, надо так построить бизнес процессы и их автоматизацию, что бы не было мучительно больно при их изменениях. "
И я когда-то выдавал подобные сентенции. А потом, все же, решил посмотреть внимательно на обустройство того бизнеса, куда продавал, и причину изменчивости. Крупные бизнесы, которые построены по механистической модели и базируются на бизнес-процессах, не так уж и часто меняют свои привычки. Они не меняют продукты как перчатки, не перестраивают орг. дизайн. Сталь варят уже которое тысячелетие по проверенной карте технол. процесса. Телекомы конвергируют услуги, но предоставляют их по правилам, предложенным еще Беллом . В конце концов, даже тот же телеком выработал практически ШАБЛОН своего бизнеса и обозвал его по-детски откровенно - eTOM. Так что всем этим бизнесам интереснее говорить о ИТ-состовляющей SOA, они заинтересованы в интеграции OSS и BSS инфраструктур, а не в перестройке бизнес-модели.
А какой бизес вынужден выкручиваться и выживать в условиях динамики? Правильно, SMB!!!! А где Вы встречали SMB, построенный по механистической модели со специфицированными процессами ? Наоборот, они стараются жить по органическому принципу, и их уклад - проект. Т.е. по определению их процессы перестраиваются еже-проектно и так, что бы не иметь большого количества внеоборотных средств, создающих накладные расходы. То, что продают вендоры, и есть для покупателя внеоборотные средства.
Проиллюстрирую и при этом сам же себе попротиворечу %)
На SECR08 представителям Люксофта после их доклада (http://secr.ru/?pageid=4548&submissionid=5262) задали вопрос - А почему было принято решение разрабатывать свою интеграцию ALM-продуктов , вместо того что бы взять стройную линейку готовых продуктов класса Борланд, Телелоджик, ИБМ. Они честно ответили - а мы понятия не имеем , в какой проект мы вляпаемся в следующем месяце. А перестраивать бизнес и квалифицировать проекты на входе, как осуществимые в устоявшейся методике , мы не намерены. Нам проще отказаться от методики, чем потерять клиента. И так же не намерены понижать свой ROA, "складируя" невостребованную инфраструктуру.
Резюмирую - продавать SOA как бизнес-методологию можно крайне ограниченной целевой группе и делать это могут именно бизнес-консультанты. А ИТ-составляющая слишком дорога для тех, кто в ней ДЕЙСТВИТЕЛЬНО нуждается.
С уважением ,
Максим Коренев

ЗЫ
Вот такой я пессимист :)
ЗЗЫ Все написанное - исключительно мой взгляд и никак не может быть отеждествлено с политикой и мнениями моих работодателей (прошлых и настоящих) :))))))

вт янв. 27, 02:10:00 ПП  
Anonymous Оптимист сказал(а)...

Этот комментарий был удален администратором блога.

вт февр. 10, 10:25:00 ПП  
Blogger arkanoid сказал(а)...

А чем REST лучше? Это ж какбе "SOA без SOAP и WS-*". Я пока плохо понимаю, какая с этого радость.

вт февр. 10, 10:30:00 ПП  
Anonymous Оптимист сказал(а)...

Этот комментарий был удален администратором блога.

ср февр. 11, 09:50:00 ДП  

Отправить комментарий

Подпишитесь на каналы Комментарии к сообщению [Atom]

Ссылки на это сообщение:

Создать ссылку

<< Главная страница