вторник, 5 декабря 2006 г.

Кто «круче»: CIO или «Директор по ИТ»?

Source: http://www.itblogs.ru/blogs/borkus/archive/2006/12/05/cio.aspx

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

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

Для продвижения проекта нам было необходимо одобрение хотя бы части из этих людей. И мы с ними говорили.

Вспомнить я хочу знакомство с одним из таких лиц, принимающих решения. Оно выделялось тем, что не прошло гладко -- я сделал ошибку, которая чудом не привела к катастрофе. А именно: когда он представился, как CIO, дав визитку с указанием какой-то другой должности, я пробормотал что-то типа «сейчас модно быть CIO» или что-то в том же духе. Сморозил, короче говоря, глупость некстати. Дело, напомню, было пять лет назад, когда этот термин еще не был широко распространен. Лицо моего собеседника резко напряглось, выдавая все его чувства, и мне потом стоило невероятных усилий, чтобы проблему загладить. Удалось это не до конца, хотя потом я, естественно, был аккуратней в высказываниях. (В оправдание могу много чего сказать, но это не важно, т.к. больше так не ошибаюсь.)

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

Проект мы успешно завершили, потом у него было развиие. У организации вскоре появился самый главный начальник по ИТ, который уже и формально назывался CIO. Иностранец.

Но вот вопрос. Что же такого в аббревиатуре CIO, что она считается круче, чем «Директор по ИТ», «Заместитель гендиректора по ИТ»? (Хотя, кажется, все же не круче, чем «вице-президент по ИТ».)
Лэйбл CIO в нашей стране сейчас дает явно большую капитализацию специалиста, чем «Директор по ИТ». Для многих CIO названия со словом «директор» теперь звучат как шаг вниз по карьерной лестнице. (Это наблюдательный факт). Хотя, реальное наполнение и в обоих случаях зависит от размера компании.
В чем магия слова?

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

Published 5 декабря 2006 г. 14:04 by Vlad Borkus

Filed under: ,


Comments



понедельник, 4 декабря 2006 г.

Приколы из ТЗ

Source: http://www.itblogs.ru/blogs/borkus/archive/2006/12/04/10077.aspx

Разбирал тут одно ТЗ на программную систему (аппаратная часть, конечно тоже была). Понравился момент

п. x.x.x.x "Должна быть допустима влажная протирка поверхностей для очистки от загрязнений (при отключенном электропитании)."

До каких, однако, тонкостей приходится иногда опускаться разработчику!

Published 4 декабря 2006 г. 22:50 by Vlad Borkus



Comments



воскресенье, 3 декабря 2006 г.

Сказание (былина) о Microsoft

Source: http://www.itblogs.ru/blogs/borkus/archive/2006/12/03/microsoft.aspx

(C) Владислав Боркус, 2006
(Все аналогии случайны и не содержат злого умысла)

В далеких, безрадостных странах,
Где травки почти никогда,
Пингвины большущею стаей
Собралися в Редмонд-луга.

Но Мягкий охотник не дремлет!
Он пороху утром нюхнет,
Да кучку пингвиньего сала
Себе на обед принесет.

Гигант же, храпящий спокойно,
Вдруг глазки открыл и сказал:
«Эй! Здеся я! Мне бы немного!»
Но вновь в свою спячку он впал.

Им радость: кислотное Солнце,
Что так омрачало покой,
Почти уже скрылось за самой,
Зеленой на свете горой.

Но недруг все рыщет, и Фрукты
Сумел втихаря расплодить...
Вот как за такое нахальство,
Ему бы хребет перебить?

Другой же злодей, что в Пророки
Подался на ранней заре,
Гриба утащил свой кусочек,
И лает, засевши в норе.

Кромсайте ж побольше софтины,
Чтоб денежка к вам поплыла!
Нам дайте же глюков покруче,
Чтоб жизнь веселее была!

***
Стих -- подарок на новый год коллективу Макрософт Рус. Точнее не сам стих, а лицензионная копия стиха. Можете спокойно распространять, но только целиком, и указывая авторство. :)))
***
Противопоказания: тем, у кого нет чувства юмора читать стих категорически запрещается.
***
Мысль. Вот оно -- наркотическое влияние web 2.0, говорил Елашкину.
Наверное этим стихом рискую похоронить свой профессиональный имидж аналитика и консультанта, но песне на горло не наступишь. :)))

Published 3 декабря 2006 г. 14:48 by Vlad Borkus
Filed under: ,





Comments



четверг, 30 ноября 2006 г.

Чуть глубже о 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


Comments



среда, 29 ноября 2006 г.

Давайте формализуем ответственность 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: , ,


Comments



среда, 1 ноября 2006 г.

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

01/11/2006

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

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

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

четверг, 31 августа 2006 г.

Закончен проект по анализу рынка систем электронного архива

31/08/2006

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

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

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

На следующей фазе, специалисты КОННАСИ помогли заказчику в анализе и сравнении собранных коммерческих предложений. В настоящее время система выбрана и внедряется.