Большие шаги, многовариантность

Иногда прыгать по вершинам скал – самый быстрый путь.

Вот такой вопрос.
Почему мы не отстаем от Америки, от Англии?
Дабы предотвратить встречные вопросы, попытаюсь уточнить, о чем это я. Действительно, этот вопрос без контекста выглядит чудовищно неоднозначным и бесмысленным. Разве мы не отстаем? Еще как отстаем. А в чем не отстаем? Здесь вот… точно отстаем. И т.д.
Итак, контекст в студию.
Лезу в Википедию. Космос, авиация. Россия здесь в лидерах. После всех этих пропавших лет (с начала 90-ых разработки в этих областях практически не финансировались), Россия по-прежнему в лидерах. Самый грузоподемный самолет, Мрия, российский. Самый грузоподемный серийный вертолет – российский. Кто обеспечивает основное снабжение космической станции? Россия.
Для меня вопрос не заключается в последних десятилетиях. Можно посмотреть назад и увидеть очень похожую картину.
Разрушенная войною страна мгновенно выходит в лидеры в ядерной гонке. Потом космос. Раз – и в дамки.
Т.е.страна не в лидерах по уровню жизни, по научным кадрам. Врдуг, раз, и наши разработки в лидерах. Причем в безоговорочных лидерах. Это уже не спишешь на шпионов. Ворованные секреты помогут догнать, но не перегнать.
Не спишешь на концентрацию ресурсов, которую может обеспечить империя на выбранных направлениях. Частично, конечно, можно на это списать, но не все же. ВПК любые ресурсы может переварить без видимых результатов.
Не спишешь на подневольный труд. Или спишешь? Здесь мои либеральные убеждения дают слабину. Оставлю пока этот аргумент открытым.
Вытащу на свет Японию. 1870-ые годы, страна не использует в буквальном смысле колеса. Нет науки, промышленности. 1905 год, Порт-Артур, японский флот топит российские броненосцы.
1950-ые годы, Япония и автомобили? Не смейтесь. 1980-ые – Японские автомобили уже самые надежные в мире.
Теперь Корея. Тот же автопром, электронника. Те же сумасшедшие скачки из грязи в князи.
У всех этих скачков есть одно общее. Это – скачки
Кто-то не стал ждать, пока все созреет до нормального уровня. Как мы можем строить автомобили? Надо сначала научиться их разрабатывать, надо посторить производство запчастей, надо выучить всех этих инженеров, техников, рабочих, воспитать ученых, создать научные школы и т.д и т.п.
Кто-то плюнул на все эти сложности и ввязался в бой. Нет всей инфраструктуры? Сделаем, построим, воспитаем, научим. Нет времени? Купим готовое, наймем ученых, инженеров. Нет денег? Перебросим, ужмемся.
У истоков всех этих прорывов стоит цель. Большая, новая, до сих пор недостижимая.
Менеджмент достижения далекой цели отличается от обычного менеджмента.
В обычном менеджменте мы знаем, мы проходили все предстоящие нам этапы. Мы можем их спланировать, спрогнозировать, посчитать. Мы катимся по известным дорожками, процессам. Мы катимся с горы по дорожкам и они выводят нас к цели.
В менеджменте «большого шага» мы пляшем от цели. Вот он «самый большой и самый тяжелый самолет». Что нам надо, чтобы он стал реальным? Нет шасси? Будем разрабатывать, испытывать, делать. А так как никто не знает – как, то будем пробовать несколько вариантов. Мы не можем класть все яйца в одну корзину. На нашем пути еще много никем не пройденных технологий. Если мы будем зависеть от одной тропинки, мы не пройдем весь путь. Мы пробуем несколько вариантов, несколько тропинок. Это резко повышает наши конечные шансы.
На одной дроге нас ждут, для примера 3 участка с вероятностью успеха 0.3. Общая вероятность успеха будет близка к (0.3 * 0.3 * 0.3) = 0.0027. Если каждый участок продублировать параллельной разработкой, то вероятность, при полностью независимых командах, будет близка к ((0.3+0.3)*(0.3+0.3)*(0.3+0.3)) = (0.6*0.6*0.6)=0.216. Почти на 2 порядка больше. Все условно и математика весьма приблизительна, но и при нормальных статистических методиках получится что-то похожее. Небольшое дублирование многократно повысит шансы на успех. При повышении бюджета «всего» в два раза.

Если все еще раз описать грубыми мазками, то стратегия выглядит так.
1. Ставится высокая, новая для всех, амбициозная цель.
2. Разработка на неизвестных местах ведется многими независимыми командами, каждая использует свои методы и идеи.

В приложении к ИТ стратегия выглядит так же.

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

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

Naming convention for the BizTalk solutions

«Naming convention for the BizTalk solutions»

http://geekswithblogs.net/LeonidGaneline/archive/2009/07/31/biztalk-naming-convention-for-the-biztalk-solutions.aspx

Я не стал переводить эту статью, так как по сути – это готовый документ, который можно и нужно использовать в разработке приложений на BizTalk Server.

В проектах такой документ постоянно используется. У меня он есть в разных версиях. Начал я с »BizTalk Naming Convention. Names of artifacts in Orchestrations«  http://geekswithblogs.net/LeonidGaneline/archive/2006/01/03/64751.aspx .

Было это довольно давно. Я тогда прочитал «стандартное» соглашение по именам, сделанное Scott Colestock http://www.traceofthought.net/misc/BizTalk%20Naming%20Conventions.htm . Стандартное оно было потому, что никакого другого не было и все работали с ним.  Когда я стал разбираться, почему так, а не по-другому, мне захотелось все переделать. Тогда и сделал свое Naming Convention для Orchestrations.

С тех пор я стало еще ленивее, поэтому многие вещи упростил или очень сильно упростил. Плюс добавил имена почти для всех артифактов BizTalk-a, не только для  Orchestrations.

Если есть  предложения, с радостью их выслушаю. Как и любую критику

С уважением,

Леонид Ганелин [BizTalk MVP]

BizTalk Server и для чего он нужен

Вот здесь http://www.gotdotnet.ru/Channel9/303408.aspx интервью с одним из создателей BizTalk – Эльдаром Мусяевым.

Эльдар работал несколько лет, года до 2006 над BizTalk. Интервью старое, но абсолютно актуальное. Все, о чем там идет речь, по-прежнему составляет основу системы. Можно по пальцам перечислить похожие вебкасты, где рассказываются таким простым языком такие основополагающие вещи. HIGHLY RECOMMENDED!

Интервью на русском языке.

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

Работа в Олимпии (Olympia, WA)

Вообще-то работа уже закончилась.

Проработал в общей сложности 2 месяца, контракт был на 3 мес, с 95% вероятностью продления на 1-1.5 года. Так было заявлено на интервью, на столько мне запросили TN-1 визу. Но мы предполагаем, а жизнь идет по-своему.

Кроме меня на контракт набрали еще человек 5 бизнес-аналистов и еще одного BizTalk developer. Так всех кучей и уволили.

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

Зачем столько бизнес-аналистов на 2месячны контракт? Так они делают requirements на годичный контракт? Странно, вроде контрактом только попахивает…

Есть вероятность, что наша компания таким способом сокращала рейты. Одно дело ехать на 2месячный контракт, другое – на годичный. Хорошо, что я не стал жену увольнять и перевозить сюда, хватило ума подождать. А другой девелопер влетел. Приехал с Южной Каролины, привез мебель, жену, взял хорошие аппартменты с хорошим лизом. Придется ему платить за 5 мес.вперед! если уедет сейчас. Мне хоть придется платить за 1 мес.вперед, не так страшно. Хотя и неприятно. Какого черта?… (риторическое чертыхание)

Контракт был из разряда «потратить бюджет». К примеру мой проект такой. BizTalk берет данные у внутреннего веб-сервиса и отдает их через другой веб-сервис. Все, что он делает, это трансформирует формат данных. Спрашивается, почему нельзя сразу данные выдавать в нужном формате через первый сервис? Заказчику я поостерегся такие вопросы задавать, нашим девелоперам, которые это все придумали еще до меня, тоже, дальше напишу почему.

Мне было интересно, т.к.меня поставили на BAM. Есть такой функционал в BizTalk, позволяет собирать данные по всем данным (извиняюсь за тавтологию), проходящим через систему. Раньше я старался с ВАМом не связываться, а тут пришлось разобраться, что к чему. Как ни странно, но – понравилось. Раньше был противником ВАМ, теперь, когда разобрался, стал сторонником. Оказалось, что сдалано все красиво и по уму.

Немного про нашу компанию:

 Во главе – индус. Из элиты. Не знаю, какая у него каста, но ведет он себя по-царски. Первый не здоровается, вид важный. При этом – далеко не дурак. С персоналом ведет себя по-барски (или по-русски?). В посторонние разговоры не вступает, держит хорошую дистанцию. Чем сильно отличается от местных начальников, которые не следуют принципу «начальник умнее/лучше подчиненного».
Надо мною непосредств.начальник – тетенька из местных.  Управляет процессом, в технологии не лезет, делает все надежно и правильно. Похоже она себя чувствует виноватой за все эти увольнения, хотя она-то и не при чем. С ней бы я еще поработал.

Разработчики в команде BizTalk-а – все индусы, кроме меня. Сам начальник начинал этот проект, что-то сам делал (к предыдущему вопросу про странную архитектуру). Есть еще парочка ребят. Ребята хорошие. Делают все быстро. Быстно схватывают новое. Им это интересно. Опыта не хватает в BizTalk, что компенсируется задором и энергией. И специфические индусские плюсы: очень контактны, болтливы, веселы и открыты. Что не может не нравится окружающим, в том числе заказчику. Если что, уболтают любой вопрос.

Что-то в последнее время BizTalk девелоперы пошли сплошняком одни индусы. К чему бы это?

По самой Олимпии:

Очень и очень понравилось. 40 тыс.народу. До работы 8 мин езды. Даже обедать домой ездил. Везде озера, заливы и леса. Такое впечатление, что недавно был бум в строительстве, т.к.во многих метах стоят целые кварталы новеньких домов посреди недвано вырубленного леса. Большая часть домов непроданные. Местные программисты живут как короли. К примеру, Джон имеет несколько акров земли, у залива (ойстеры свои %) ), тихое место у Христа за пазухой, домище, при этом до работы – 20 мин. Цены на жилье раза в два ниже, чем в родном Ванкувере. Климат чуть теплее и «континентальнее», чем в Ванкувере. Т.е.летом чуть теплее, чуть меньше «дризлов» и «шауэров» зимой-осенью-весной (это такие дождички, когда капелек почти не видно, такие они маленькие. Висит взвесь в воздухе и делает все влажным.) Общее впечатление от погоды, от природы, от городишка – нравится.

Все, пошел искать следующий контракт

Всем привет!

Получение TN визы

Как я получал TN визу (полное название у нее TN-1 visa) на границе в таможне Peace Arch, Blaine, WA.

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

Это уже вторая моя TN виза. Первую я получал в конце 2007 года в американской таможне аэропорта Vancouver. Может кто не знает, но в некоторых аэропортах Канады располагаются американские таможни. Если летишь в US, то «границу переходишь» прямо в аэропорту, еще не вылетев из Ванкувера.

В 2007 году адвокат, которого нанимала моя компания, настаивала, практически приказывала мне пересекать границу именно в аэропорту. Связано это с тем, что на сухопутной границе офицеры редко имеют дело с выдачей TN, а загрузка у них большая, очереди постоянно. Поэтому вероятность того, что офицеры завернут тебя, довольно высока.  Тогда я получил TN в аэропорту без проблем. Хотя потом пришлось потратиться на рент-кар, т.к.свою машину пригнал в US только через месяц.

А тут еще грянул кризис, рецессия. Везде на форумах американские ребята ругаются на H1B-ишников, что те отнимают у них работу. Президент не раз говорил, что все преференции будут американским работникам.  Это стало заметно, когда пришло время мне искать очередной контракт. В большей части позиций по BizTalk явно указывалось, что нужны только местные специалисты. Рекрутеры, как всегда, не читают резюме, и когда они звонили и узнавали, что мне нужна TN виза, то резко затухали. То есть я сделал вывод, что с выдачей TN тоже будут ужесточать режим.

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

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

Другой офер был из недалека, из Олимпии, что находится чуть южнее Сиэттла, и, кто не знает, как-никак а столица штата. И этот офер я выловил в LinkedIn. Там народ время от времени размещает объявления о найме. Причем в этот раз я наткнулся не на рекрутера, а на человека, непосредственно из компании. Компания девелоперская, небольшая, поэтому рекрутерам с меня ничего не досталось. Ну и не жалко их. Громаднейший плюс для меня тот, что из моего Ванкувера до Олимпии 3,5 часа езды, а не 5 часов лета, как до Флориды.

Так о чем я? О том как визу в этот раз получал.

Долго решал, идти через аэропорт или сушей. Решил, что и там и там – лотерея, поэтому… Суша победила.

В понедельник уже на работу.

Поэтому решил так: в субботу еду на границу, получаю (если все сойдется) TN и сразу возвращаюсь  домой.  А в воскресенье уже с вещами трогаюсь в Олимпию, 3 с половиной часа езды.

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

Поэтому в субботу я поехал домой несолоно хлебавши.

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

У меня такой набор документов:

1. письмо из компании доблестным американским таможенникам-погранцам-офицерам с просьбой выдать мне эту самую TN
2. «эвалюация» моего диплома
3. копия и заверенный перевод диплома
4. копия и заверенный перевод вкладыша к диплому, с оценками
5. копия и заверенный перевод зачетки, т.к. нужны не только оценки, но и количество часов, затраченных на предметы
6. референсы. У меня их парочка от VP Microsoft, т.к. я Microsoft MVP. А к этому призу прилагается и такой вот референс.
7. копии сертификатов. У меня MCAD, MCSD, MCTS (BizTalk)
8. резюме
9. копии разных ID, как то Driever license, BC CareCard, SIN

Я в субботу хотел 2-7, 9 доки только показать, не отдавать. Но офицер сказал, что им нужны эти документы насовсем.

Поэтому я в субботу сделал копии всех этих документов. Их и отдал. Хотя они не были заверенные, но благополучно прокатили.

Все было долго, но просто.

Офицеров внутри таможни в Peace Arch было человек тридцать, посетителей человек пять, хотя на улице очередь машин была минут на 50. Офицеры на меня вытаращились, стали между собою решать, кто займется этим чудом. Явно они с такого рода делами имеют дело чрезвычайно редко. Нашли крайнего, молоденького парнишку. Судя по погонам, совсем зеленый. Но деловой и спокойный.

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

Все, больше вопросов не было. Нее, еще спросили адрес, по которому буду жить. Я сказал, что такого пока нет, что пока есть бронь в отеле, а адрес появится, когда срентую что-нибудь, они удовлетворились адресом компании. Потом заплатил $56. Тут у меня отлегло. Раз деньги берут, значит и TN выдадут.

В общей сложности просидел около часа.

Так я и не понял. Повезло ли мне или никакой удачи, все как и должно быть?

А пока пожелайте мне удачи в Олимпии!

=================================================================
[Дополнения от 2009-08-17]
Отвечаю на вопросы, поступившие в последнее время:

Вопросы:
1. Надо ли письма с прежних мест работы (если контрактор, то от заказчиков), что работали именно Computer System Analyst? При желании ведь это можно проверить в CRA ili CanadaService? Т.е. eсли в своем резюме сам пишешь, что работал именно Computer System Analyst, то какие-то еще бумаги со всех
прежних работ/заказчиков нужны?
+++ у меня не было таких писем. И не знал, что могут понадобиться. Был список референов с фамилиями, телефонами. 4 референса, как положено.

.. вроде пишет, что надо письмо от работодателя в US и дегри, а если нет дегри, то proven work experience as Computer System Analyst. Я понимаю, что сейчас, после 2х официальных работ в US вам канадские работодатели с их письмами не нужны, но самый первый раз как было?
+++ самый первый раз я спрашивал у лойера, нужно ли мне резюме переделывать под Аналиста. Она сказала, чтобы я не заморачивался. Но у меня все равно есть вариант резюме с Аналистом в моем пакете. Я там просто изменил названия должностей и убрал ссылки на языки программирования и на кодирование.

2. Вы показывали оценку WES, а не Trustforte, можно узнать, почему?
WES оценивает наш диплом как BSC (правда до 2000-2001 года оценивал как MSc) a Trustforte kak MSc, так что бачелор – лучше? Вызывал ли какие-то вопросы ваш диплом? Я когда делала себе визу в UK, я отправляла еще и израильскую оценку диплома (по уже указанной причине, place of origin никто не знает).
+++ Я так понял, что им по барабану, была бы фирма-эвалюейтор сертифицированная и все. Мастер или Бачелор? У меня эвалюировано как Мастер, по Бачелору не могу ничего сказать.

Зачетку показывать обязательно? У меня ее нет, когда мы уезжали, хорошо хоть дипломы отдали и grades list.
+++ Зачетка у меня переведена. Копия оригинала и перевода составляют значительную часть моего пакета документов. Все оригиналы у меня были под рукой. FYI Зачетку выдают из Архива института через 7 лет после окончания. Оригинал на руках – это хорошо всегда.

У … вроде написано про degree and grades list, forеign degree evaluation. У вас зачетку на границе потребовали или вы просто сами решили показать, чтобы диплом сомнения не вызывал? Degree evaluation разве не достаточно?
+++ Больше = лучше. Зачем лишние вопросы?

3. Программистcкие сертификаты. Что-то я читала по англо-язычным форумам, что никакого намека на программисткие заслуги не показывать, ато не пустят. У меня сертификаты старые, уже устарели, а в Канаде я обленилась и сертификаты запустила. Если сертификаты дадут какой-то плюс, то я засяду делать, если на границе их лучше прятать, то это не срочно тогда. Хотелось бы определиться.
+++ У меня сертификаты по BizTalk плюс грамоты по BizTalk MVP. Плюс рекомендательное письмо от Microsoft Vice President (такое положено всем MVP). Все в копиях. Работало это или нет – не знаю, но в пакете все было.

+++ Самое главное: пакет должен быть ТОЛСТЫМ (см вые список доков, которые у меня в пакете). Они сами сказали, «пакет, что останется у нас, должен быть ТОЛСТЫМ». В этом случае им проще прикрыть свою задницу, если каким-то проверяющим не понравится их решение дать вам визу. Это очевидно. Поэтому все копии надо делать на одной стороне листа. Надо вначале приложить список документов в пакете. Еще у меня были копии страниц паспорта, ID (SSN, SIN). Пакет толстый.

В первый раз я все копии переслал по и-мейл адвокату. Та их подшила и поставила свою печать, типа «подшитому – верить». И все подшитое вместе с письмом от фирмы-работодателя прислали мне. Так все и сдал на таможное.
Второй раз мне прислали одно письмо (по шаблону, ссылку на который я ж им и дал http://www.canadatotwincities.com/visa.html Образец они передрали один к одному, не заморачиваясь.) Никаких адвокатов не присутствовало в процессе.
Т.е.процесс в первом случае клиенту стоил м.б.и 5-значную сумму (по их словам), во втором случае – ноль. Результат одинаковый.

Фотографии с Microsoft Global Summit MVP [Most Valuable Professional] 2009

 

Всем привет,

Я сделал несколько фотографий на

Microsoft Global Summit MVP [Most Valuable Professional] 2009 March 1-4, Seattle, Redmond.
В основном это BizTalk и Connected Systems MVPs.

http://public.fotki.com/leogan/cities_and_countries/usa/2009-microsoftgloba/

Наверняка BizTalk девелоперы посещают MSDN форумы и знают многих BizTalk MVP, таких как Stephen W. Thomas, Alan Smith, Saravana Kumar, Joao Pedro Martins, Ben Cline.

Stephen W. Thomas, Alan Smith, ?, Saravana Kumar, Joao Pedro Martins, Ben Cline

 

Здесь MVPs из России.

MVPs из России.

А здесь Microsoft Fellows. Отвечали на наши вопросы.

Microsoft Fellows

Microsoft Fellows

Был еще Steve Ballmer, куча вице-президентов.

Было весело.

BizTalk и развитие систем

Рассмотрю пример, показывающий, чем нам может быть полезен BizTalk Server.

На нашем виртуальном предприятии есть несколько связанных между собою основных систем: Бухгалтерия, Склад, CRM. Есть еще система отчетов.

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

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

Представьте себе комбайн, к которому подключено многочисленное навесное оборудование. Соединяется комбайн с оборудованием разными проводами с разнообразными разъемами. Выдернуть все провода, заменить старый комбайн на новый и заново воткнуть все провода не получится. Все разъемы на новом комбайне другие, некоторых просто нет, другие разъемы объединенные и т.п. Сигналы управления, идущие от нового комбайна тоже изменились.
Что же делать? Неужто придется менять и комбайн, и все оборудование вместе с ним?

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

Возвратимся к нашей системе отчетов. Все данные соединим через промежуточный слой. Теперь поставим новую систему рядом со старой и начнем потихоньку, без спешки переключать один разъем за другим. В порядке готовности. Сделать это просто, так как данные могут с одного входа подаваться сразу на несколько выходов. К одному выходу подключена старая система в рабочем режиме, к другому выходу подключаем новую систему и отлаживаем ее. Я сильно упрощаю реальность, но мне главное объяснить, как мы с помощью промежуточного слоя передачи данных добиваемся отмены требования «менять систему сразу и безошибочно«.

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

BizTalk Server и Xml

 На днях мне на глаза попалась инструкция по формированию файла данных. Эти данные нужны для передачи информации от 1С партнера в фирму 1С, небезызвестную российскому IT народу. Инструкция занимала четыре листа, на которых подробно описывались форматы различных полей данных.

[

...

Кодировка текстового файла - WINDOWS;

Строка отчета соответствует одной строке текста;

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

Строковые значения заключаются в кавычки. Например: "ООО".

Кавычки внутри текста удваиваются. Например: "ООО ""ПоларисКуб""";

Числовые значения представляются "как есть";

Дата представляется в фиксированном строковом формате "ДД.ММ.ГГГГ"

Например: "30.04.2007" - правильно, "30.04.07", 30.04.2007, "04.30.2007" — неправильно.

...

]

У меня сразу зачесались руки, как это всегда случается при виде какого-то старого кода, который можно сильно усовершенствовать, не затрачивая при этом много времени и труда.

Ну конечно, все эти словесные описания должны быть заменены Xml схемой! Какая разница? Было описание данных, получится тоже описание данных.

Но разница есть. Xml схема используется готовыми Xml парсерами, входящими в операционную систему Windows [MSXML http://msdn.microsoft.com/en-us/xml/bb291077.aspx]. Парсер проверит данные на соответствие предложенной схеме. Теперь нам не надо писать свою программу, чтобы проверить данные на соответствие формату. Порядок данных, форматы сложных и простых типов данных, соответствие набору кодов и т.п.

Старая модель верификации данных:

Поставщик данных готовит подробное описание формата данных в виде документа. Потребитель данных пишет парсер для ввода данных в свою систему.

[...

Например: "30.04.2007" - правильно, "30.04.07", 30.04.2007, "04.30.2007" — неправильно.

...

]

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

Xml модель верификации данных

Поставщик данных решает использовать формат данных Xml [http://www.w3.org/TR/xml11/ ]. Он описывает данные в формате Xml схемы (Xsd формат [http://www.w3.org/TR/xmlschema-1/, http://www.w3.org/TR/xmlschema-2/ ]). Потребитель данных использует эту схему для ввода данных в свою систему. Он использует один из существующих парсеров для верификации данных.

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

Использовать ли стандарт Xml для передачи данных?

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

Пример: передача данных за пределы своей организации.

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

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

Пример: передача данных между разными программами.

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

Уверены? А что будет, если пользователь через пару лет соберется заменять одну из программ на программу другого производителя? Вам придется переписывать программку верификации заново. Не факт, что в это время вы будете работать рядом. Не факт, что к тому времени не будет утеряно описание формата. Простая задача выльется в долгие и утомительные согласования, чреватые ошибками.

Пример: передача данных в рамках одной сетевой программы.

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

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

Если при этом удается избежать сериализации данных, то использование Xml может привесит к неоправданному усложнению. К примеру, программы, написанные на .NET Framework могут использовать множество технологий для обмена данными: MSMQ, named pipes, COM+ и т.д. Не факт, что использование Xml приведет к нужным результатам.

BizTak Server и использование Xml

Вы спросите, какое отношение все эти рассуждения имеют к BizTalk?

Может быть дело в том, что BizTalk это одна из первых серьезных, крупных систем, базирующаяся на Xml?

BizTalk работает с данными в форме сообщений. При этому внутри BizTalk все сообщения представлены в формате Xml. Точка.

На входе и выходе BizTalk данные могут быть во множестве форматов: текстовых, SQL, Xml, форматов определенных программ, таких как SAP/R3, C:Предприятие… Но все эти форматы на входе/выходе BizTalk преобразуются в формат Xml.

Это приводит к замечательным последствиям.

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

Имея промежуточный слой в виде BizTalk, нам придется обеспечить только N * 2 преобразований.

При этом неправильные данные не попадут в систему. Они будут отсеяны парсером Xml на этапе ввода в систему.

Заключение

Как там… «партия и Ленин – близнецы-братья»? А у нас «BizTalk Server и Xml – близнецы-братья.

Архитектура BizTalk

Здесь английская версия статьи: http://geekswithblogs.net/LeonidGaneline/archive/2006/12/18/101541.aspx

———————————-

Когда я начал работать с BizTalk, я начал строить в голове разные модели того, что происходит с сообщениями внутри BizTalk. С каждой новой итерацией получалась другая модель.
[Далее я не перевожу на русский язык основные термины BizTalk-а: Receive Location, Send Port, Orchestration, MessageBox и т.д. Иначе получится полная мешанина, когда вы обратитесь к документации BizTalk.]

 

Все началось с традиционной модели:

Назовем эту модель «Принять – Передать».

Ясно, что речь здесь идет об отправлении и приемке сообщений.
Выглядит, как будто Receive Locations – это приемники сообщений, Send Ports – передатчики сообщений, а Orchestrations являются одновременно приемниками и передатчиками. Правильно?
Неверно. Все объекты являются как приемниками, так и передатчиками.
Receive Locations получают сообщения из «внешнего мира» и потом отправляют их в Message Box.
Send Ports получают сообщения из Message Box и передают их дальше, во «Внешний мир».
Orchestrations получают сообщения из Message Box и передают их дальше. Куда? Опять в Message Box.
Message Box получает сообщения от Receive Locations или от Orchestrations и передает их в Send Ports или снова в Orchestrations.

В BizTalk Help есть описание другой модели, Издатель-Подписчик (Publisher-Subscriber). Но большая часть внимания в Help уделена именно модели Принять-Передать.
Термины передать и принять продолжали смущать меня.

Для иллюстрации неоднозначности терминов принять и передать в контексте BizTalk, посмотрим на цитату из книги «Pro BizTalk 2006», написанной George Dunphy и Ahmed Metwally, страница 119:
« … The left side shows the sender configuration, which consists of a static one-way send port to send the business document or message and a static one-way receive port to receive BizTalk Framework 2.0 delivery receipts. The right side shows the receiver configuration, which contains a static one-way receive port to receive the message and a dynamic one-way send port that… »
В переводе:
« …Левая часть показывает передающую конфигурацию, которая состоит из статического одностороннего передающего порта и статического одностороннего принимающего порта. Эта конфигурация получает BizTalk Framework 2.0 подтверждения доставки. Правая часть показывает принимающую конфигурацию, которая состоит из статического одностороннего принимающего порта и динамического одностороннего передающего порта…»
(Я выделил смущающие меня термины.)

 

Вас не смущает то, что передающая конфигурация и предает, и принимает сообщения? Так же, как и принимающая конфигурация.
Хорошо, давайте обсудит эту неоднозначность. Термины передать и принять означают… Хмммм, они означают одно и то же.
Мы передаем сообщение? Да. И ОДНОВРЕМЕННО мы принимаем сообщение.
Эти термины имеют смысл ТОЛЬКО, если они используются ВМЕСТЕ с субъектом или объектом операции.
Сообщение передается? В этом вопросе нет смысла. Мы отправляем сообщение в приемник и из передатчика.
Сообщение принимается? Нет смысла. Сообщение принимается от передатчика и в приемник.

Попробуем использовать другие термины, такие, как публиковать и подписываться.
Эти термины в контексте BizTalk всегда означают «относительно MessageBox».
Термины передать и принять не имеют такого смысла.
Я не хочу полностью отказываться от этих терминов. Но они должны использоваться только вместе с объектом или субъектом операции, соответственно.

 

После того, как я сделал изменения, получилась вторая версия модели:

Здесь я выдвинул термины Subscriber и Publisher на первое место модели.

Эта модель явным образом «Message Box – центрированная», если можно так выразиться.
Publishers передают сообщения в Message Box. Subscribers принимают сообщения из Message Box.
Все действия происходят вокруг Message Box.
Publishers передают сообщения с определенным типом в Message Box. Тип сообщения в BizTalk определяется, как объединение значений namespace и имя корневого узла (namespace + root_node). Речь идет, конечно, о сообщении в формате XML, так как все сообщения внутри BizTalk имеют формат XML. Subscribers принимают из Message Box только те сообщения, которые проходят через фильтр конкретной подписки (Filter expression).
В этой модели Receive Locations и Send Shapes в Orchestrations размещаются в группе Publishers, а Send Ports и Receive Shapes размещаются в группе Subscribers.

 

Давайте посмотрим, как термин Binding накладывается на эту модель.

Я получил такую модель.

Binding = неявная подписка

 

[the Binding = the Implicit Subscription]

 

Подписка для Binding создается за сценой. В большинстве случаев Publishers ID используется как Filter expression.
Термин Binding используется здесь для описания связи между Orchestration и Port.
Насколько я понимаю, этот термин был создан для упрощения модели, для автоматизации работы с созданием наиболее простой и наиболее часто используемой операции, когда сообщения передаются из одной четко определенной точки в другую точно определенную точку. Binding создает 1-1 связь, когда один Publisher должен передать сообщения одному Subscriber. Binding делает шаг в сторону от «чистой» модели Publisher-Subscriber (издатель-подписчик), которая заложена в основе BizTalk, и реализует один из часто используемых шаблонов передачи сообщений (Direct Link).
Publishers и Subscribers в чистой модели Publisher-Subscriber не знают ничего друг о друге и не должны знать. Publishers отправляют сообщения в Message Box, а Subscribers извлекают сообщения из Message Box, опираясь на параметры подписки.
Binding делает модель более сложной. Binding упрощает выполнение одной конкретной операции, но при этом усложняет модель.
Чистая Publisher-Subscriber модель в BizTalk доступна с помощью так называемого Direct port.

 

Ниже очередная версия модели:

Здесь я изобразил Orchestration из двух частей. В предыдущей модели Send и Receive Shapes были в одной Orchestration, что неправильно.
Я изобразил Shapes и Port/Locations одинакового размера. Я чувствую, что Orchestrations не должны быть «больше», чем Ports.
Я добавил «Внешний мир» («Outer World»). Почему бы нет!?
Теперь это Publisher-Subscriber model.

Выводы:

• * Модель «Принять – Передать» резко усложняет восприятие архитектуры BizTalk. Не используйте термины отправить и принять (Receive и Send) для описания движения сообщений. Лучше используйте термины издать и подписаться (Publish и Subscribe).
• * Подходите критически к BizTalk Help, так как там термины receive и send используются бессистемно.
• * Binding надо использовать на втором уровне обучения BizTalk. Этот термин усложняет вещи, когда используется для маскировки Publisher-Subscriber модели. Описание операций с сообщениями без использования этого термина облегчает жизнь.

Пример применения Microsoft BizTalk Server: аптечная сеть

Пример применения Microsoft BizTalk Server: Аптечная сеть

——————————————-

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

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

Различные архитектурные решения

«По течению»
Автоматизация бизнес процессов делается по мере появления требований. К примеру потребовалось передавать какой-то документ из аптечной программы в складскую программу. Для этого делается отдельная программа, которая согласовывает формат передачи данных, синхронизирует передачу данных. Потребовалось передать другой документ – пишется другая программа.

Преимущества данного подхода в том, что он достаточно оперативен, не требует системного подхода, часто самый дешевый.

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

Корпоративный стандарт
Утверждается набор стандартов. Стандарты для форматов данных, стандарты на используемые технологии, стандарты на используемые в разработке и в работе программы.
Например, для передачи данных определяется стандартный формат сообщений. Каждое сообщение дополняется служебной информацией: уникальный идентификатор сообщения, время создания сообщения, параметры передающей стороны (ФИО создателя документа, адрес, дата, время и т.п.), параметры адресата и т.п.
Создаются стандартные программы, работающие со стандартными сообщениями. К примеру, программы, передающие сообщения в локальных сетях и в интернете, кодирующие сообщения с соблюдением корпоративных стандартов безопасности.
Утверждаются технологии, разрешенные к использованию. К примеру, разрешается использование в разработке только Visual Basic .NET, .NET версии 2.0, Веб-сервисы asmx. Разрешается использование стандарта SOAP 1.1. Разрешается использование Microsoft SQL Server 2005 для баз данных.

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

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

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

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

Недостатки этого подхода в том, интеграционная платформа требует значительных начальных финансовых и технических затрат. Покупка готовой интеграционной платформы, такой как IBM WebSphere или Microsoft BizTalk Server помогает максимально быстро запустить в работу промежуточный интеграционный слой.

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

При оценке внедрения можно использовать следующую методику расчета затрат:
Стоимость системы = (затраты на покупку ПО и оборудования) * (4..6)