Pár námětů na zamyšlení pro produktové manažery v Microsoftu ohledně rozšiřování BizTalku 2004 a "evangelizaci" jeho schopností a hranic. Jedná se o moje zkušenosti z prezentace možností BizTalku u jednoho klienta a dále z obecné konzultace o integraci aplikací přes XML. Posluchači byli z vyššího IT managementu. Konzultace většinou žádné nedělám, ale o projekt na BizTalku bych měl velký zájem, takže jsem udělal výjimku.;)

Výsledky jsou ale z mého pohledu tristní.

1. Největší zájem o BizTalk mají pobočky zahraničních firem, které chtějí integrovat nebo nahradit kvanta pidi aplikací na Lotus Notes.
2. Někteří zákaznící si myslí, že BizTalk=XML a XML vyléčí během jednoho dne všechny potíže při výměně dat s partnery. Bez námahy, programování atd.
3. Jiní zákaznící považují BizTalk za CASE nástroj pro návrh procesů, protože obsahuje Orchestration Designer!
4. BizTalk je v mysli mnohých také spjat s řízením projektů. Možná by mohl Microsoft zapracovat na posílení povědomí o svých serverových produktech a prodal by minimálně pár licencí na MS Project Server.
5. Také zaznělo, že BizTalk je nástroj pro vytváření OLAP kostek. Sice v něm tuto funkčnost naleznete, ale asi nikdo si nebude BizTalk kupovat jen kvůli OLAPu.

Konzultace se většinou nesly v duchu seznamování se základními principy SOA, webových služeb, "enterprise" integrace aplikací a většinu přítomných to evidentně zaujalo, hlavně když zjistili, že, jak již předtím instinktivně tušili, SOA a a potažmo BizTalk jim pomůže vyřešit jejich problémy s integrací mnoha a nejen Lotus Notes aplikací.

Pro mě je zřejmé, že potenciál k rozšiřování BizTalku v Čechách je, jen Microsoft zatím nedostatečně u zákazníků zmiňuje všechny přednosti a hlavní rysy BizTalku. A myslím, že si to tak skvělý produkt jako je BizTalk opravdu nezaslouží:(

Dneska jsem skoro celý den strávil na semináři o BizTalku 2004. Dorazil jsem sice s hodinovým zpožděním, protože jsem ráno musel na tradičně neodkladnou analytickou schůzku  se zákazníkem, ale díky ní jsem nakonec přišel o zahajovací  marketingovou masáž. Štestí v neštěstí. Celý dnešní blok přednášek byl zajímavý, i když vzhledem k rozsahu tématu a nutnosti vysvětlit jej v pouhých dvou dnech je citelně znát, že přednášející odříkává své věty  v presu a že všechny vlastnosti BizTalku bez ohledu na jejich složitost musí vysvětlit na jednom zjednodušujícím slidu prezentace. Škoda, ale samostudium technologií je stejně dobrodružnější. ;)

Na BizTalku je nejzajímavější abstrahování od nízkoúrovňových implementačních záležitostí, jakými jsou ruční návrh XSD schémat nebo infrastruktura pro business procesy. Ve vizuálním režimu se dá navrhnout většina typických transformací a translací dat, je snadné rychle rozehrát sladěný orchestr různých business procesů, aniž bych musel měsíce trávit vývojem a testováním potřebných komponent.

Kdy a proč jsem se začal o BizTalk zajímat? Prvotním motivem bylo zjištění, že naší zákazníci si pod pro mě jednoznačnou zkratkou CRM představují systém, do nějž budou integrována všechna jejich data z přehršle různých systémů pracujících nad různými databázemi, které si každé oddělení firmy nechalo z vlastní ďábelské iniciativy vyvinout. Když ale chce top management firmy vidět souhrnná data o zákaznících ze všech systémů, tak se teprve ukáže, že ďábelská iniciativa nezbytně formuje jen celofiremní SW peklo. Jak data ze systémů získat? Kam je uložit? Jak zajistit jejich konzistenci? Není lepší datové sady i za cenu vyšší časové náročnosti integrovat online na požádání uživatele? To jsou jen jemné náznaky nepříjemných problémů čekajících na řešení.

Pro náš CRM systém E-Dirigent jsem navrhl snadno rozšiřitelnou vrstvu datových konektorů s jednoduchým veřejným rozhraním, ve které jsou všechny rozdíly při komunikaci s heterogenními datovými zdroji centralizovány, a zbylé vrstvy aplikace si nejsou vědomy, že komunikují například s WWW službou místo s výchozím MSSQL serverem. Problémy, které se musí řešit při online komunikaci s datovými zdroji nejsou příjemné - jen namátkou:

1. Jak provést JOIN nad zdrojem, jenž JOIN nepodporuje?
2. Co s agregačními funkcemi, které mají pracovat nad více datovými zdroji?
3. Jak zajistit aktualizaci údajů napříč datovými zdroji v jediné transakci?

Nakonec funkční a relativně jednoduchý návrh vznikl. Protože si ale samozřejmě nemůžeme dovolit vyvinout úplně univerzální řešení, tak je návrh prošpikován kompromisy (tohle slovo opravdu nemám rád), a proto jsem se stále více přikláněl a přikláním k tomu, že na takové záležitosti je lepší u zákazníka nasadit vyzkoušený a fexibilní BizTalk. Mohu se ale mýlit. Budu rád, když mě poučí někdo, kdo BizTalk na Enterprise integrace používá. Je vůbec v Čechách někdo takový?