Творческие транзакции

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/07/30/19545.aspx

Транзакции, описываемые свойствами ACID по настоящему креативных людей уже давно не удовлетворяют. Сначала возникли "долгоиграющие" транзакции, которые растянули понятие до предела, но еще сохраняли представление о транзакции, как он некоторой целостностной операции. А теперь, похоже, новый этап эволюции термина. Вот такие достижения предлагает нам новейшая концепция BPM 2.0, согласно одному из блогов:

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

Конечно можно попутно задуматься -- не поменять что-то в «консерватории» ? Какая эффективность от workflow в процессе, длящемся 5 лет и постоянно меняющемся? Учет шагов, конечно важен, но формализация такого процесса выглядит как overkill.
Но меня поразило больше то, что это теперь уже называют транзакцией. Правила выполнения «транзакции» кроятся в ходе ее же исполнения. Куда ушли старые добрые транзакционные принципы? Вероятно, настоящий творец должен делать транзакцию руками, меняя все на ходу -- включая код. :))



Published 30 июля 2007 г. 13:23 by Vlad Borkus

Filed under: Брюзжание

Microsoft, отдай назад кадру!

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/07/17/Microsoft_2C00_-_3E044204340430043904_-_3D043004370430043404_-_3A0430043404400443042100_.aspx

Последние пару дней поднялась волна обсужденийна тему того, что Microsoft оголяет рынок кадров в России, переманивая их у партнеров. Проблема не нова -- она возникла несколько лет назад, когда вендор начал расширять свой офис. Скажем, год назад я задавал вопрос на эту тему Биргеру Стену (генеральный менеджер по России) на пресс-конференции Microsoft по итогам года, куда был приглашен как независимый аналитик.В прошлом году скорость укрупнения офиса Microsoft только выросла и проблему все стали  ощущать сильнее. Осложняет ситуацию то, что MS пре6дпочитает брать на работу людей, уже имеющих опыт внедрений ее продукции и хорошо в ней разбирающихся (желательно сертифтицированных).  Но где таких людей брать? Только у партнеров -- больше их нигде нет.

Для специалистов это хорошо (в смысле денег) -- ни один партнер не может сравниться по вознаграждению и социальным гарантиям с западным вендором. Но так как людей экстра-класса всегда мало, то возникает проблема оголения "фронтов" у партнеров. Грубо говоря под человека взяли проект, а он "свалил" в Microsoft Consulting.Биргер Стен тогда отбился, заявив, что вообще Россия полна талантов, а в Microsoft здесь всего 500 человек, уж как-нибудь наберутся... но видимо не набрались. Вот очередные стоны партнеров MS транслирует CNEws (http://www.cnews.ru/news/top/index.shtml?2007/07/17/259117), причем стонут уже "большие" компании, а не "мелюзга".Надо сказать, что практика переманивания сотрудников у "друзей" считается в мире плохим тоном. Например, нескольких моих знакомых не взяли в SAP только потому, что они работали либо у партнеров, либо даже у заказчиков. Поэтому Microsoft действует не совсем этично и даже не совсем разумно, так как разрушает свою же экосистему. И все же ... точка зрения "талантов много, кадры вырастут" также имеет право на жизнь. Собственно таланты и растут-то только тогда, когда для них открываются возможности, т.е. новые позиции. А уход людей в Microsoft такие позиции и открывает.
//Влад Боркус
Published 17 июля 2007 г. 15:31 by Vlad Borkus Edit
Filed under: Microsoft

Comments

Новый арсенал "серебрянных пуль"

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/07/09/18921.aspx

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

EDA расшифровывается как Event Driven Architecture, т.е. архитектура, построенная на обработке событий. События рождаются в одних системах, попадают на шину доставки и потребляются другими системами. Получается, что EDA -- это наследница технологий MOM (Message Oriented Middleware). Собственно, и программное обеспечение, через которое распространяются события EDA -- это, как правило, шина на базе JMS (Java Messaging Service), т.е. самый что ни на есть MOM.

Есть в EDA, правда, и некоторые добавочные вещи, например, повсеместность событий (сервисы могут генерировать события), возможность по событию инициировать вызов сервиса (т.е. синхронной коммуникации) или запуск делового процесса, возможность мониторинга событий (в том числе через агрегаторы типа dashboards), средства интеллектуальной корреляции событий (Complex Event Processing (CEP).

Например, BPM-система TIBCO iProcess Suite может автоматически генерировать события по завершению каждого шага делового процесса. Другие инструменты TIBCO могут находить соответствия в цепочках событий, и, например, создавать новое событие, которое запускает деловой процесс. (Аналогичные возможность есть в ПО Oracle и других.). И все же сказать, что EDA -- вещь абсолютно новая, сложно.

Для привязки вызовов сервисов к событиям одной MOM уже мало, нужны средства ESB (Enterprise Services Bus). Продукты ESB (Enterprise Service Bus) и дополнительные к ним модули основных производителей -- BEA, Fiorano, IBM, Oracle, Sonic, TIBCO -- поддерживает EDA «из коробки». Но среди вендоров пока нет терминологического согласия на тему, является ли EDA частью SOA или нет. Например, TIBCO считает, что является, а Oracle, что это уже «больше, чем SOA».

Есть еще один набирающий популярность термин/набор стандартов -- SCA (Service Component Architecture, архитектура служебных/сервисных компонент). Суть здесь состоит в создании сборок сервисов, описания интерфейсов которых отделены от инфраструктурной составляющей.

В системе выделяются компоненты, решающие какие-либо бизнес задачи, и для каждой из них задается интерфейс внешнего доступа в виде группы сервисов. Изменить данные в компоненте можно только через эти сервисы. Сами сервисы и компоненты описываются терминах именно бизнеса, а не технологий. Иначе говоря, если в SOA (по мнению некоторых) может фигурировать "сервис обновления таблицы БД", то в рамках SCA может быть исключительно сервис «обновить данные о клиенте» в объекте «клиент».

Существенно, что такую компоненту/интерфейс потом можно при помощи деклараций привязывать к конкретному технологии -- Java, COBOL, PHP, XML-языки (BPEL) и т.п. В ходе жизненного цикла, можно менять технологический слой компоненты, не трогая интерфейс. SCA индифферентна к тому используются ли синхронные или асинхронные вызовы, а обращающиеся к компоненте системы в технологическом плане могут быть оформлены весьма различно.

Подобная «высокоуровневая» объектная ориентированность позволяет разработчику компоненты инкапсулировать в ее описании все зависимости данного сервиса от других сервисов. В итоге упрощается применение в сервисам политик доступа, политик доставки, обеспечение транзакционности -- они задаются декларативно на уровне SCA, а не в рамках программного кода. Также управлять жизненным циклом компонент проще, чем жизненным циклом «кучи» сервисов. В общем, новое есть. Некоторые называют все это «SOA NextGeneration/2.0», хотя, наверное, это чересчур оптимистично.

PS. Замечу, что SCA также опирается на технологию SDO (Service Data Objects, служебные объекты данных) для передачи параметров и возвращаемых значений. Это инструмент для универсального описания объектов данных (в терминах графов) и интерфейсы для манипулирования ими.
PPS. В настоящее время SCA поддерживают продукты BEA, IBM, Oracle, TIBCO и несколько более мелких вендоров. Работы по SCA ведутся в рамках проекта «открытая SOA» (www.osoa.org)
//Влад Боркус, www.konnasi.ru
Published 9 июля 2007 г. 16:08 by Vlad Borkus Edit
Filed under: SOA

Comments

Про SOA на конференции TIBCO Software

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/07/03/soa-tibco-software.aspx

На днях выступил на мини-конференции WelcomeEvent, посвященной представлению компании TIBCO Software в России, -- сделал доклад с анализом состояния и перспективах в России методологии построения композитных приложений SOA (ServiceOrientedArchitecture), а также технологии управления бизнес-процессами BPM(BusinessProcessManagement). TIBCO только-только зарегистрировала свой офис, набирает народ, тормошит партнеров. Но вот уже до аналитиков/консультантов добралась.

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

Так, на российском рынке можно найти практически любые программные продукты для построения SOA, а также экспертизу по их использованию. Хотя законченных проектов построения сервисно-ориентированного ИТ-пространства  на сегодня в России нет, тем не менее имеются проекты внедрения технологий, связанных с идеями сервисной ориентации, таких, как корпоративные шины сервисов ESB (Enterprise Services Bus). Ряд отечественных подрядчиков имеет опыт интеграционных проектов класса Enterprise Applications Integration (EAI) и MessageOrientedMiddleware (MOM), и постепенно набирает экспертизу в SOA. На рынке также присутствуют западные вендоры и консалтинговые компании, имеющие готовые методологии развертывания SOA.

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

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

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

Для тех, кто заинтересуется, поместил слайды здесь: ссылка 

http://www.konnasi.ru/wp-content/uploads/_files/Borkus_Konnasi_BPM_and_SOA_in_Russia.pdf 

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

Published 3 июля 2007 г. 13:01 by Vlad Borkus
Filed under: SOA, TIBCO

Comments

ИТ-страсти малого бизнеса

Source: http://www.itblogs.ru/blogs/borkus/archive/2007/07/03/_180422042D004104420440043004410442043804_-_3C0430043B043E0433043E04_-_3104380437043D04350441043004_.aspx

Истории, леденящие душу, поступают ко мне от самых разных людей. Вот рассказали недавно случай, если можно так выразится, довольно классический. Дело происходило в небольшой московской компании, работающей в высококонкурентной, но и доходной отрасли. Компания небольшая (человек 15), но с вполне приличными для такого числа сотрудников оборотами. В ней трудился сплоченный коллектив, состоящий из людей, знающих друг друга не один год. Но вот пришла беда: к конкурентам стали  утекать данные о клиентуре компании. Причем утекать регулярно, что начало наносить вполне конкретный ущерб.

Подозрение пало на каждого -- база клиентов велась на Access и через сетевой доступ была доступна всем. Никакого разграничения прав доступа на уровне данных не было -- по паролю каждый видел все данные базы. Соответственно, любой мог их слить. И все же экспресс-расследование, проведенное владельцем, показало, что это дело рук системного администратора. Получая примерно по $1500 в месяц, мужичок прирабатывал еще на $300 помогая бизнесу конкурентов. В общем ситуация типичная, если бы, конечно, все не знали друг друга многие годы. Горячие головы предлагали проучить мерзавца, но решили его в итоге просто выгнать. Хотя история не о только об этом.

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

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

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

На проект было выделено $10K и неделя. Исполнителей, как всегда искали через знакомых. И нашли. Человека грамотного, но пьющего. Естественно, пообещал сделать в срок, но возникли другие дела, праздники и все затянулось. В общем, недели через четыре от него решили отказаться, так как результатов не проявилось.

Вывесили объявление в интернет. И начали приходить звонки от удивительных людей, народных умельцев. Наиболее оригинальным был один парень из Тулы, который утверждал, что лично переписал на Access программу 1С, и теперь в Туле никто 1С не пользуется, а пользуется его разработкой. Предание интересное, но парня завернули на том основании, что слова ODBC и SQL он не знал. Возможно, что для разработчика на Access они и не к чему, но доверия не вызвал. В итоге нашли мужика лет 65-ти, который вроде бы многое чего в ИТ повидал и запросил меньше денег. Теперь он с базой и возится, хотя чем его работа закончится -- неведомо.

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

Published 3 июля 2007 г. 12:50 by Vlad Borkus
Filed under: Проекты

Comments