23. Aplikační integrace

Aplikační integrace, vazba na podnikatelské procesy, podnikatelské přínosy, přístupy a prostředky pro vnitro-podnikovou a mezi-podnikovou integraci, zhodnocení, vývoj v dané oblasti.

Předpoklady: Máte ve vaši firmě za úkol navrhnout způsob integrace s vaším velkým dodavatelem.

Zadání: jaké informace pro tuto volbu potřebujete, kde je získáte, jaké alternativy budete uvažovat, jak se rozhodnete.

• Takže máme nějaké podnikové aplikace (tj. složité, podporující životně důležité funkce podniku) a chceme je integrovat neboli propojit tak, aby komunikovaly mezi sebou a s uživateli a s partnery atd.
• Naši klienti považují naší firmu za jednolitý podnik a očekávají, že s námi bude rozumná komunikace jako člověk s člověkem, nikoli jako člověk s miliónem nepropojených aplikací (podnikové procesy jdou napříč odděleními, skrze všemožné aplikace).
• Nejsou na to standardy, je to komplexní problematika, zasahuje mnoho úrovní abstrakce, různé druhy aplikací, různé systémy, nad kterými třeba ani nemáme úplnou kontrolu
• Mezi celkovou vizí integrace aplikací a samotnou implementací je velká díra, kde chybí metodiky, standardy, návrhové vzory atd.
• Většina literatury je vágní, nebo se věnuje určitému výrobci a konkrétní technologii (a la MS BizTalk atd.)
• Hodně se mluví o standardech, ale nejsou best practices
• A architektů, který rozumí integraci aplikací je jako šafránu

• založena na standardizaci (formátů, komunikace, postupů …)
• integrace hardwarová, datová (ETL, EII, FDZ), softwarová (aplikační, viz dále, EAI, SOI(SOA, XML, Web Services)), uživatelského rozhraní, interních podnikových procesů (horizontální, vertikální), integrace s okolím (zákazníci CRM, dodavatelé SCM), integrace vizí a metodik

• sjednocení prostřednictvím technických standardů (sběrnice, rozhraní, USB, TCP/IP sítě, Wi-Fi)

• ETL - export, tranformace, load - dávkové, pracné
• EII - enterprise information integration - společná datová základna
• FDZ - federalizovaná datová základna - řada úložišť s centrálními indexy a číselníky - mnohonásobná synchronizace

• EAI - enterprise application integration - speciální middleware
• SOI - service oriented integration, integrace služeb (služba s business rozhraním, např. rezervace letenek) pomocí SOA, XML, Web Services (standardizace API)

Poznámka: S integrací na vyšší úrovni (kód ⇒ EII ⇒ EAI ⇒ SOI) roste nákladnost, náročnost na implementaci, ale jsou volnější vazby, asynchronnost, nezávislost na platformě, dodavateli, roste standardizace (až na SOI, kde to není ještě vyspělé)

Sjednocení principů komunikace s uživatelem pro všechny aplikace - jednotné ovládání (jednotný význam funkčních kláves, jednotná forma návratu v komunikaci,…), jednotný grafický design, trend: prohlížeč jako jednotné uživatelské rozhraní, uživatelské portály (webové intranety).

• Cíl - zefektivnění podnikových procesů, maximalizaci přidané hodnoty zákazníkovi, zkrácení doby procesů, rychlejší reakce podniku na externí události, minimum podnikových zdrojů, maximální kvalita produktu nebo poskytované služby.
• Horizontální integrace = propojování podnikových procesů a aplikací IS/ICT určité úrovně podnikového řízení, např. integrace prodej-sklady-výroba-nákup
• Vertikální integrace = propojování procesů a aplikací IS/ICT operativní, taktické a strategické úrovně podnikového řízení, např. agregace dat TPS a MIS do EIS
• nástroje: BPM a BPEL nástroje – integrují: workflow, integraci aplikací (na bázi SOA), business rules, performance management dashboards

• strategická úroveň – výběr partnerů, dohoda o kooperaci
• taktická úroveň – propojení obchodních procesů s partnery
• operativní úroveň - koordinace obchodních procesů
• úroveň IS/ICT – propojení aplikací, sdílení společných dat

Integrace pohledů vrcholového vedení podniku na význam a priority IS/ICT, vedení informatiky, v rámci koncernu, s partnery v řetězci (Business Activity Monitoring, ROI analýzy, Strategické aliance, Fúze a akvizice, Monitoring SLA a hodnocení dodavatelů)

Propojení všech metod, technik a nástrojů, které se používají při řízení podniku a řízení IS/ICT tak, aby na sebe logicky navazovaly a aby vytvořily jednotnou metodiku vývoje IS/ICT (např. MMDIS)

• vyexportovat, třeba do COBOLem čitelných souborů
• načíst do cílového systému
• výhody: dobrá fyzická nezávislost, nezávislost na jazyku a systému
• nevýhody: není to okamžitý přenos dat, systémy nejsou synchronizované, obrovské množství dat

• Všechny aplikace sdílí jednu velkou databázi
• výhody: konzistence dat, tvorba reportů
• nevýhody: integrace dat, ne business funkcí, problém společné reprezentace dat pro všechny aplikace

• jedná aplikace vzdáleně volá přímo funkci jiné aplikaci
• potřebná data jsou přenesena v rámci dotazu a výsledek je zabalen do odpovědi
• výhody: výměna dat on-demand, integruje i business funkce, nejen data
• nevýhody: funguje dobře s malým počtem systémů, křehká stavba (pevná vazba), výkon?

• posílání zpráv na sběrnici, nebo do fronty
• k odebírání zpráv se může zaregistrovat více subjektů
• messaging nabízí hodně dodavatelů “EAI” middleware - IBM WebSphere MQ, TIBCO, WebMethods, Java Messaging (JMS), Microsoft .NET System.Messaging, Asynchronous Web Services
• výhody: přenos dat on-demand, integrace business funkcí, volné vazby, asynchronní provoz
• nevýhody: zatím ne tak obvyklý postup, obtížnější testování, někdy je potřeba i synchronní odpověď

• service oriented architecture, web services
• integrace na úrovni služeb, ale moc tomu nerozumím, a mám pocit, že se o tom víc kecá, než aby se něco dělalo

Messaging se stará o několik úloh. Následuje výběr návrhových vzorů podle knihy Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions od Gregor Hohpe a Bobby Woolf (online verze). Nejedná se o žádnou metodiku, standard, kompletní řešení ani jazyk, jde jen o vzory, kterými disponují různá konkrétní řešení zahrnující právě messaging, často proprietární, drahá a s různým názvoslovím (každý tomu říká jinak, dává tomu hogo-fogo marketingový název, ale v zásadě je to totéž).

1. Transport zpráv ⇒ Channel Patterns
   • Message Channel - asynchronní spolehlivý přenosový kanál, který drží zprávy dokud není příjemce k dispozici
   • Point-to-Point Channel - přímý kanál jeden odesílatel - jeden příjemce
   • Publish-Subscribe Channel - jeden odesílatel, libovolný počet příjemců zprávy (zaregistrují se), multicast
2. Design zpráv ⇒ Message Patterns
   • Return Address - obsahem zprávy zpáteční adresa, kam má být zaslána odpověď
   • Correlation Identifier - obsahem zprávy je unikátní identifikátor, aby bylo možné spárovat zprávu s odpovědí
3. Směrování zpráv k cíli ⇒ Routing Patterns
   • Message Router - komponenta směrující zprávy k různým cílům (na základ náhody, obsahu, času, záteže atd.)
   • Recipient list - přesně určený seznam příjemců, kterým se řídí message router
   • Splitter - rozděluje zprávy na části, každou směruje jinam jako samostatnou zprávu
   • Aggregator - spojuje více zpráv do jedné
   • Auction - jedna zpráva je odeslána více příjemcům (PubSub, nebo Recipients), jejich odpovědi jsou spojeny do jedné odpovědi (Aggregatorem)
4. Transformace zpráv do různých formátů ⇒ Transformation Patterns
   • Data Enricher - obohacení zprávy o další části/informace, které odesílatel nemá k dispozici
   • Content Filter - vyfiltrování zajímavé části zprávy, odstranění nepodstatných/nevhodných částí zprávy
   • Check Baggage - odložení části obsáhlé zprávy stranou, po zpracování opět obohacena u původní data (aby se ušetřila zátěž)
5. Produkování a konzumace zpráv ⇒ Endpoint Patterns
   • Messaging Gateway - prostředník pro napojení aplikace na messaging
   • Polling Consumer - klient messagingu, který pravidelně jednou za čas vyzvedne zprávy
   • Event-driven Consumer - klient řízený událostmi
6. Řízení a testování messaging systému ⇒ Management Patterns
   • Message store - úložiště prošlých zpráv, např. pro potřeby pozdější analýzy, reportingu
   • Test message - testovací zpráva, vpravená do ostré komunikace v určitém místě a opět odchycená na jiném - umožňuje testovat vybrané části systému, identifikovat chyby

• Wikipedia Enterprise_application_integration
• článek o Enterprise application integration
• článek o integraci podnikových procesů
• http://www.enterpriseintegrationpatterns.com/toc.html

• jaké informace pro tuto volbu potřebujete, kde je získáte, jaké alternativy budete uvažovat, jak se rozhodnete.

Velký dodavatel si bude patrně diktovat podmínky, takže na vedení je zjistit (dohodnout) na jaké úrovni chtějí integraci (procesy, služby, nebo jen určité aplikace), co chtějí integrovat (patrně SCM), a jakými technologiemi (SOA, messaging (ESB?), nebo jenom databáze). CIO pak ručí za vypracování úvodní studie (proveditelnost) a určení nákladů, aby bylo možné se rozhodnout, zda se to ekonomicky vyplatí - tedy tři možnosti:

• implementace podle představ dodavatale
• ztráta dodavatele
• konzervace současného stavu