Аудит пакета технических заданий

Аудит пакета технических заданий на внедрение систем документооборота и управления аудиторской деятельностью в нефтегазовом холдинге...

ROI от SOA – хочется больше?

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/13/ROI-_3E044204_-SOA-_1320_-_45043E0447043504420441044F04_-_31043E043B044C04480435043F00_.aspx

В августе Nucleus Research опубликовала результаты опроса компаний, применивших методологии SOA во внутрикорпоративных разработках. Исследование очень интересное, и я вкратце решил пересказать те результаты, которые они опубликовали в открытую. На западе оно наделало много шума – в основном на волне критике SOA (теперь это стало модно), хотя, на мой взгляд, оно очень даже позитивное.

Итак:
1) Только 37% компаний достигают положительного ROI от вложений в SOA.
2) SOA увеличивает продуктивность разработчиков, но обычно все ограничивается только 1 проектом на уровне департамента, что уменьшает возврат инвестиций.
3) Только 40% разработчиков использует SOA
4) Те разработчики, кто использует SOA повышают продуктивность на 28%.
5) Больше всего SOA используется в здравоохранении (62% power пользователей против 48% в material companies);

Выявленные проблемы:

• разработчики считают себя творцами кода и не хотят повторно использовать чужие наработки, и поэтому сторонятся SOA;


• для успеха необходимо интенсивнее вкладываться в обучение SOA, нежели делается;


• размер SOA зависит от числа опубликованных в реестре сервисов, но инструменты для реестров дороги и компании их не покупают.

PS. Я бы добавил, что когда программисты просекут, что SOA в конечном итоге делается, чтобы не "плясять" перед ними по каждому пустяку, то они совсем откажутся работать в SOA-проектах. :))

Publised 13 сентября 2007 г. 16:26 by Vlad Borkus Edit
Filed under: SOA

Моя презентация про SOA на конференции «Ассоциации ДокументальнойЭлектросвязи» (repost)

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/12/54191.aspx

Выложил на наш сайт слайды своего выступления об SOA на конференции Ассоциации Документальной Электросвязи, состоявшейся в 12 сентября. Ввиду специфики мероприятия, я попытался объяснить структуру SOA что называется «на пальцах», т. е. дать максимально упрощенное представление.

Так как планировалось делать выступление в компании мировых лидеров (Sun, IBM, Oracle), то надо было придумать «фишку» -- таковой я выбрал тему анархии и порядка в ИТ, и SOA как один из методов для их балансирования.

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

PS.

С мероприятием, где делался этот доклад получилась престранная история. На него меня подрядил Сергей Орлик -- выступить на круглом столе в рамках сессии дабы разбавить ряды вендоров.

Но за день до конференции выяснилось, что нужно не просто «поболтать», а сделать доклад, причем на 10 минут (длительность, что называется "ни туда, ни сюда") – и пришлось в срочном порядке рисовать слайды.

Потом новая беда – на лидеров рынка нашла «черная полоса»: у одного потеряли билеты, которые надо было сдавать в посольство, другой застрял в пробке, а еще пара людей не явилась без видимых причин. Из лидеров выжил только IBM (конечно, Gartner это предсказывал давно, но не в данном контексте :) ))

По итогам – на КОННАСИ (т. е. меня) и IBM распределилось в сумме 1,5 часа вместо запланированных 10+10 минут . Я выступал первым – пришлось принимать на себя большую часть ударов с критикой SOA.

Презентация «SOA: баланс между анархией и порядком для развития ИТ»

В формате PDF:


И для порядка:

Презентация по перспективам SOA в России, сделанная в июне на конференции TIBCO:

В формате PDF:



Статья в PCWeek/RE с трезвым взглядом на SOA («Практическое построение SOA: борьба с мифами»):

В формате PDF:


//Влад Боркус

Published 12 сентября 2007 г. 12:25 by Vlad Borkus
Filed under: SOA

BEA купят, а жаль

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/10/bea.aspx

eWeek сообщил на днях о единодушной уверенности всех западных аналитиков в том, что в ближайшие полгода состоится покупка BEA каким-нибудь из крупных вендоров. Причины – у компании не ладится бизнес в северной Америке и она не добирает оборотов относительно прогнозов. В первом квартале прогнозировали $358, получили -- $342. Акции упали, соответственно с $16 до $11.

Основных покупателей два: Oracle и Hewlett-Packard. Руководство Oracle не скрывает, что хочет сделать это приобретение, но просто ждет подходящего момента. HP тоже в покупке заинтересовано, но у нее хуже с деньгами – она не может выплатить такую же премию за акции, как Oracle. (См. http://www.eweek.com/print_article2/0,1217,a=213246,00.asp)

Мне, как аналитику в этой области, искренне жаль. Программный комплекс BEA был построен очень грамотно и качественно. Вряд ли наиболее вероятный покупатель (Oracle) сохранит платформы WebLogic и AquaLogic как они есть. Middleware – не ERP, и ситуация с PeopleSoft вряд ли повторится. Скорее всего будет взят курс либо на полную ликвидацию этого ПО, либо на его унификацию с аналогичными линейками Oracle (SOA Suite, BPM Suite), возможно с сохранением лишь отдельных продуктов.

Как бы то ни было, но ухудшение состояния BEA указывает на изменение спроса на рынке middleware, где все меньше возможностей остается для независимых поставщиков «тяжелых» платформ.

//Влад Боркус

Published 10 сентября 2007 г. 13:28 by Vlad Borkus
Filed under: SOA

Comments

Математика рисков ИТшника: нужна ли нам автостраховка?

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/03/20383.aspx

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

Цена страховки = (вероятность наступления случая)*(стоимость случая) +(прибыль страховщика).

Так как прибыль страховщика всегда больше ноля, то мы в среднем всегда в накладе – страховка это «разводка». Но может есть в этом деле потаенный смысл? Провел опрос знакомых на предмет покупают ли они КАСКО и окупается ли это?

Артур. Первый год вождения. Страховку не покупал. Несколько мелких инцидентов общей ценой менее $1000. Баланс цена страховки/ремонт: $2500(теоретическая)/$1000.

Марина, Купила страховку. Стаж вождения 15 лет. Цена страховки $1500. За пять лет несколько инцидентов общей ценой $1000. Баланс страховка/ремонт -- $7500/$1000. В итоге сомневается в нужности страховки.

Михаил. Сторонник страховки. Считает, что она убыточна, но покупается просто спокойствие. Денежной составляющей не раскрыл.

Ольга – покупает страховку 5 лет по цене $1200. Стаж вождения 10 лет. За это время 4 камня в лобовое стекло (замена ценой $350) плюс авария с ремонтом на $5000. Баланс страховка/ремонт: $6000/$6400. Ее брат – взял назад стоимость страховки в нескольких авариях, теперь его отказываются страховать. Баланс за пять лет: $12000/$20000.

Татьяна – стаж 10 лет. Машину не страхует. За 7 лет использования машины мелкие проблемы на менее чем $1000. Баланс: $7500(теоретическая)/$1000.

Андрей -- машину не страхует (не считает выгодным, так как работает в страховой компании :)). За пять лет проблем на $2000. Баланс: $7500(теоретическая)/$2000.

Есть, в общем, повод задуматься. Вероятно, страховать от угона все же для спокойствия нужно, так как стоимость случая получается большая, а цена страховки ($250 в год) мала. А вот страховать от аварий, кроме как по ОСАГО получается как-то не очень обоснованно.

Вопрос: это у всех так или выборка такая? Кто чего думает?

//Влад Боркус

Published 3 сентября 2007 г. 14:03 by Vlad Borkus Edit
Filed under: Жизнь

Comments

IBM: ESB мешает SOA

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/09/03/ibm-esb-soa.aspx

Несколько лет, когда технология ESB (Enterprise Services Bus) была «коньком» фирмы Sonic Software, корпорация IBM ее недолюбливала. Но потом, когда ESB была разрекламирована Garnter, то IBM резко сменила позицию и выпустила свой ESB-продукт. Но вот недавно на сайте DeveloperWorks появилась статья о том, что увлечение ESB мешает правильному пониманию концепций SOA, подменяя внедрение архитектуры внедрением программного продукта. (http://www.ibm.com/developerworks/webservices/library/ws-soa-esbarch/index.html)

Многие блоггеры восприняли статью как знак того, что IBM «сдает» ESB, хотя внимательное чтение показывает, что это не так. Скорее IBM подводит читателя к мысли, что помимо покупки ESB стоило бы приобрести и консалтинг в области SOA.

Главных тезисов по ESB и SOA всего два:

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

(На мой взгляд ESB – это просто продолжение технологий EAI, т.е. в общем хорошая технология, дающая пользу в умелых руках и бесполезная в руках неумного архитектора. Но, конечно, реклама обещает большее.)

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

• Не создавать системы «на будущее».
  
• Внедрять только то, что уже нужно бизнесу;
• Стыковать потребности бизнеса и ИТ-решение.
  

Эти мысли не новы, но любопытно их слышать от крупного вендора. При восприятии массами они могут не в лучшую сторону сказаться на объемах продаж.

Published 3 сентября 2007 г. 0:01 by Vlad Borkus
Filed under: SOA, ESB

KM-2007 Обзор персональных систем сбора информации и управления знаниями

Основные результаты исследования опубликованы в еженедельнике PCWeek/RE, здесь же приводятся некоторая дополнительная методическая информация.

Ограничение ответственности

Приводимые данные представляются «как они есть». В них могу содержаться ошибки, хотя мы и предприняли все разумные шаги, чтобы эти ошибки устранить. Сведения приводятся в том виде, в каком они были использованы группой для выбора закупаемого продукта. Объем исследования также диктовался одной целью -- выбрать продукт для своих нужд. Оценки могут содержать субъективизм -- иначе и быть не может. Мы снимаем с себя любую ответственность, за тот выбор, который может сделать потребитель, ознакомившись с приводимыми данными. Вместе с тем мы гарантируем, что прилагали все усилия, чтобы сделать обследование максимально объективно и достоверно.

 

Рассмотренные системы

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

Лидеры (системы, имеющие функционал наиболее полно отражающий сформулированные потребности):

• Macropool GMBH WebResearch. Лучше всего организовано сохранение из Web;


• Kinook Ultra Reсall. Обладает самыми развитыми механизмами классифкации;


• WJJSoft MyBase. Наиболее удобна с точки зрения построения базы, связанной гипертекстом.

(Замечание. Метрика обновлена на 16.05.2007 для отражения некоторых новых требований).

Другие изучавшиеся продукты:

AskSam (www.asksam.com), MDE Infohandler (www.mdesoft.com), eGems Gemteque Software (www.egems.com), Personal Knowbase (www.bitsmithsoft.com), Baltsoft General Knowledge Base, TreePad фирмы Freebyte (www.treepad.com), EverNote, Knowledge Workshop (www.lmsweb.com), Inquiry Professional (metaproducts.com), ScrapBook for Firefox, WikiD, ConnectedText и другие Wiki-системы, IBM Lotus Domino, Microsoft SharePoint Portal/WSS и еще пара десятков других, менее интересных продуктов.

Методика анализа

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

На наш взгляд система должна поддерживать такие сценарии, как:

Сценарии использования («высокоуровневые»)

С1. Интенсивное накопление "знаний" в ходе исследовательского проекта.

Особенности: меньший объем информации, узкая и интенсивная направленность ее потока, мелкая детализация классификатора.

Типовые операции: накопление документов и вырезок в ходе проекта, интенсивная обработка (удаление мусора, выделение главного); создание связанных заметок формирование из этих заметок нового документа (например: высказываний товарищей при формировании требований, накопление собственных мыслей (заметок), их привязка к документам).

С2. Фоновое (медленное и длительное) накопление "знаний".

Особенности: большой объем информации, широкий разброс тем, низкая плотность информации по темам. А стало быть и более грубый классификатор.

Типовые операции: накопление документов и вырезок на долговременной основе, минимальная обработка;

С3. Выемка информации по теме.

Сценарии использования («низкоуровневые»):

• «мгновенное» сохранение Web-страницы;


• захват выделенной части Web-страницы;


• захват вырезок из не Web-содержимого;


• импорт файлов из файловой системы;


• классификация содержимого по иерархическому рубрикатору;


• классификация по ключевым словам;


• отнесение документа к разным разделам классификатора;


• создание и редактирование заметок и документов;


• связывание документов перекрестными ссылками;


• поиск документов;


• печать и экспорт.

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

Перечисленные сценарии должны реализовываться максимально эргономичным образом. Экономия усилий и времени пользователя на проведение рутинных операций -- это главный стимул приобретения подобных программ.

Самым существенным качеством, различающим системы является примененная в них метафора классификации, так как именно она определяет совместимость или несовместимость со стилем мышления пользователя. Иначе говоря, система с одной метафорой будет казаться ему логичной, а с другой -- нет. Помимо всего перечисленного, система должна полностью поддерживать русский язык, а также быть устойчивой к сбоям программного и аппаратного обеспечения. А для использования в рабочих группах она должна поддерживать сетевой доступ и разграничение прав доступа. В приведенных выше сценариях много всевозможных тонкостей, и при их детализации набралось примерно 150 требований (www.konnasi.ru/wgkm_compare.htm). При анализе рынка был просмотрен широкий спектр кандидатов, но значительная их часть по разным причинам отпала уже на первых его этапах.

Описание проекта можно посмотреть здесть (сохраненная копия PCWeek/RE)

 

Основные результаты

Исследование не выявило продукта на 100% удовлетворяющего наши потребности, несмотря на то, что был рассмотрен по меньшей мере десяток из них. Три продукта Macropool GMBH WebResearch Professional (www.macropool.com), Kinook UltraRecall (www.kinook.com), WJJSoft MyBase (www.wjjsoft.com) в наибольшей степени приближаются в понятию оптимальной системы. Для временного использования мы выбрали первую из перечисленных систем, несмотря на ее заметные недостатки в области классификации информации. Мы с интересом будем наблюдать за эволюцией рассмотренных решений.

Рабочие документы

Оценка систем Macropool GMBH WebResearch, Kinook Ultra Recall 3.0 Professional, WJJSOFT MyBase 5.3 по метрике

Итоговые диаграммы.

Степень соответствия группам ключевых (наиболее важных) требований

Степень соответствия группам всех (как важных, так и неважных) требований

Таблица. Интегральные оценки систем по группам критериев метрики, с учетом весов.

Таблица. Сильные стороны систем

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