Чуть глубже о SOA

Source: http://www.itblogs.ru/blogs/borkus/archive/2006/11/30/soa.aspx

Влад Боркус

Перечитав все комментарии, которые были сделаны в публикациях про SOA на ИТ Блогз, я обнаружил, что во всей нашей дискуссии был фундаментальный изъян. Начиная говорить про SOA, мы почти немедленно переходили на обсуждение веб-сервисов. В целом это не удивительно -- мы окружены вендорской пропагандой, из которой другой вывод сделать сложно. И все же веб-сервисы и SOA -- это не одно и то же.

И не только потому, что можно построить кучу веб-сервисов, и не внедрить у себя в итоге SOA. Этот тезис, безусловно, совершенно справедлив, но лишь чуть приближает к истине.
И не потому, что SOA -- не равно ESB, о чем тоже много говорилось.

А потому, что SOA -- это вообще не про веб-сервисы. Т.е. как бы совсем не про то.

Если говорить формально, то SOA -- это некоторая концепция реинжиниринга и развития корпоративного программного ландшафта. Упоминания этого термина можно встретить где-то в 1996 году у Гартнера. Тогда эти идеи в практической плоскости соотносились с компонентными технологиями.
С тех пор этот набор идей оброс неким опытом и набором где-то использованных приемов, которые в совокупности носят красивое название SOA Governance.
Появились XML и веб-сервисы, и оказалось, что эти идеи неплохо этой технологией дополняются.

Компоненты SOA

В основе SOA действительно лежит понятие сервиса, хотя не только его. Другими компонентами SOA являются фронт-энды приложений, репозиторий описаний сервисов, сервисная шина.

Ключевым для SOA являются наличие сервисов, ориентированных на деловые задачи. В SOA могут быть и масса других сервисов (трансформации, авторизации, и т.п.), но они вторичны.

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

В CORBA, EJB приложение строится из множества маленьких кирпичей. В SOA -- из малого количества больших.

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

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

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

Ключевым качеством сервиса является его описание. В описании сказано, что за интерфейс (функции) сервис имеет, приведен контракт (на каких условиях возможен доступ), и прочее -- кто его состряпал, какая версия, кто может менять сервис, когда этот сервис доступен, какая у него нагрузочная способность. Это описание совсем не обязательно должно быть на WSDL, например оно может быть на IDL или даже в MS Word. Главное, чтобы оно было.
Естественно, если описание -- в машино-распознаваемом формате, то использовать сервис потом намного удобнее.

Сами сервисы могут быть реализованы в рамках родной инсталляции SOA на разных технологических платформах -- WS, Java, .Net, CORBA. Более того, идея SOA как раз и состоит в том, чтобы обезопасить ИТ-инфраструктуру от смены поколений информационных технологий и стыковать плохо совместимые унаследованные технологии. Скажем, идеологи SOA открыто говорят, что SOAP когда-то отомрет, а ИТ надо будет и дальше жить. Требуется только, чтобы сервисы отвечали формальным требованиям SOA.

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

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

***
Все описания сервисов (описание интерфейса и контракт) обязаны храниться в репозитории.
Если это формальные описания, то система будет более конфигурируемая. Но, стоит заметить, что полноценные репозитории более сложны, а важны больше для B2B-среды, а не контролируемой корпоративной среды.
Но репозиторием может быть, и склад word-документов в файловой системе (это, конечно, экстремальный случай). В конце концов главный элемент в рамках SOA -- это корпоративный разработчик.

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

Последний компонент SOA -- это шина сервисов. Это -- не обязательный компонент SOA. И уж, конечно, совсем не обязательно -- это ESB.

Главной задачей шины является технологическа стыковка систем на ее концах. Т.е. если с одной стороны у нас находится SOAP, а с другой -- CORBA, то шина должна обеспечить преобразование формата вызова от одной системы к другой. Например, коммутацию XML-полей на методы CORBA. Мы это можем сделать, так как у нас есть «нейтральное» описание сервиса.
В принципе, в рамках SOA может существовать несколько параллельных шин, скажем она -- асинхронная, а другая синхронная. Или идентичные шины в географички разных филиалах.

Проблемы

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

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

Есть проблемы, о которых упоминал Анатолий, -- как быть с бизнес-объектами. Хотя самый очевидный путь -- это стандартизовать их на уроне шины. Также бизнес-объекты по сути сами являются готовыми сервисами.

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

Что касается успехов. Есть проекты, причем достаточно большие. Хотя их беглый анализ местами не внушает оптимизма -- в одних исходная задача была относительно простая, в других -- решение получилось кривое, и его переделывают.

****
PS. Написать этот текст меня подстрекал Анатолий, так что вся ответственность за последствия лежит на нем. Особенно если там отдельные вендор будут кидать в меня камнями :))
Но если статью на форуме сочтут приличной, то я ее попробую доработать и пристроить в какой-нибудь ИТ-журнал.

Published 30 ноября 2006 г. 5:21 by Vlad Borkus

Filed under: Мысли, интеграция, SOA

Comments

Давайте формализуем ответственность HR!

Source: http://www.itblogs.ru/blogs/borkus/archive/2006/11/29/hr.aspx

Тема, которую я хочу поднять, -- как бороться с некомпетентностью HR.

То, что наши современные HR в среднем не блещут профессионализмом -- не секрет. Часто от них больше вреда, чем пользы. Как это получается?

Во первых, HR -- одно из трех магистральных направлений, по которым распространяются выпускники психологических факультетов. Два других -- это PR/реклама и околомедицские дела. Алена (Aliona) еще упоминала в блоге тренеров (видимо, преподавателей психологии), возможно, это еще одна стезя.
Но выпускников-то этих много. Только в Москве порядка 100+ заведений готовят дипломированных специалистов. И ясно, что качества образования в среднем ожидать не приходится.

Есть и другие проблемы.

Мы установили в дискуссии с Аленой на ее блоге (http://itblogs.ru/blogs/hr/archive/2006/11/27/9563.aspx), что 70% из выпускников еще при поступлении обладают всевозможными комплексами, которые переносят на своих «пациентов». Чтобы излечить эти комплексы, они и пошли в психологи. У тех у кого нет комплексов, обычно их приобретают по жизни, особенно на такой работе.
Из 30% оставшихся часть глупы, другая часть саботировала обучение и кое-как получила диплом. В итоге полезного контингента набирается 5-10%.

Если эти непрофессионалы уходят в PR и рекламу, то риск для приютившей их компании в основном небольшой. Все равно PR находится под пристальным оком генерального директора или президента. Он все и поправит.
Хуже, если они уходят в HR. Тогда от них зависит благополучие внутренней жизни и эффективность компании.

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

***
Последнее время HR стали образованные и используют тесты, как словесные, так и всевозможные проективные методики. Все эти методики созданы в основном в Америке и четко отражают американский менталитет. То, что большинство HR этого не понимают -- гигантская проблема.

Примеры я на форуме приводил. Вопросы из огромного теста (GMAT, кажется) : «Если вас остановил на дороге милиционер, то может ли это быть, что он хочет получить с вас взятку?», «Вас в троллейбусе пнули. Допускаете ли вы, что человек мог сделать это намеренно?», «Нравится ли вам хорошо выглядеть?», «Нравится ли вам хорошо одеваться?». Далее тест автоматически выдает профессиональную ориентацию, а может и медицинский диагноз поставить.
Понятно, что для некомпетентного психолога -- это убедительный документ. Этот тест до сих пор используют в представительствах, использовали у крупных интеграторов.
Алена, kenzo, Миша Елашкин приводили на форуме и другие примеры.

Получается, что чтобы попасть на работу, кандидат должен обмануть тест. Скажем цветовые тесты Люшера не наврав (заучив ответы) кандидат пройти не может, так как сам тест настроен на другую ментальность, чего бы там не пел сам Люшер. Я не говорю про зависимость восприятия цветов от освещения.
Иначе говоря первое сито -- насколько эффективно кандидат может обмануть фирму, поступая туда на работу.
Такое вранье можно, конечно, тоже рассматривать как тест на гибкость, но нужно ли оно на позиции программиста?

Некоторые выдающиеся личности используют и тесты Роршаха с его же интерпретацией, которая, уже лет 50 известно, что не работает. Вопросники Айзенка -- тоже великое открытие. Они даже на родине во времена Айзенка не работали, но у нас используются. Еще есть психологические типы Юнга... Отечественные проективные тесты на сангвиников и холериков...
И так далее, чего это все перечислять. Напридумывали много.

****

Что во всем этом смущает? Ответственность HR за результат непонятна. Т.е. ему дают задачу найти кандидата, но вот по каким параметрам оценивать деятельность самого HR? Это я и предлагаю обсудить.

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

Иначе говоря, помимо постижения личности самого HR, его нужно загнать в формальные рамки.
Говоря еще более формальным языком, нужно заключить контракт между нанимателем и провайдеров HR-услуг: соглашение о качестве обслуживания (SLA), в котором прописать процесс и ответственность за результат. Такой SLA может, по крайней мере теоретически, ограничить влияние измеряющего субъекта (HR) на результат измерений и улучшить ситуацию в компании.

Что должно определять соглашение?
а) распределение обязанностей между HR и другими участниками процесса;
б) Формальные шкалы оценки человека HR’ом при приеме на работу («не жулик, не псих, способен черти на что»);
в) Ответственность HR провайдера за действия сотрудника (если он в результате украл, завалил проект по психологической причине еще что-то);

Теперь вопрос. Насколько реально такую штуку формализовать? Алена, что вы на этот счет думаете, как профессионал? Что оно должно включать?
Насколько будет эффективно? Что думают об этом клиенты HR службы, т.е. уважаемые руководители? Кто-нибудь наверняка такое делал.

PS. Это мой первый опыт блогописания, так что если чего не так, то прошу извинить. Я в общем-то сам не знаю, нужны ли мне блоги. А «пост» по теме HR в особенности. Но Миша Елашкин потратил полгода на приведение убедительных аргументов в том, что блоги полезны. А он знает в этом деле толк. Аленина дискуссия навела меня на мысли. И я решил попытаться начать блоггерствовать.

Published 29 ноября 2006 г. 4:14 by Vlad Borkus

Filed under: кадры, Мысли, HR

Comments

У исследовательской группы КОННАСИ - новый сайт

01/11/2006

С каждым годом объем информационного шума, связанного с ИТ-технологиями, удваивается, и ориентироваться в нем CIO и ИТ-директорам становится все сложнее. Поэтому растет и спрос на профессиональных специалистов, способных разобраться в предложениях продуктов и услуг на ИТ-рынке, оценить их качество, сильные и слабые стороны. Исследовательско - консалтинговая группа КОННАСИ специализируется как раз в этой области, предоставляя услуги в области независимой аналитики и проектного консалтинга.

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

Сайт разработан и внедрен дизайн-студией Integrate, одним из лидеров российского рынка Web-дизайна.