BizTalk bij Estro Groep Hugo Brouwer
Introductie Estro Groep Aanleiding project Wat doen we met BizTalk Architectuur integratie omgeving Vragen aan jullie Agenda
Landelijke kinderopvang groep 9 merken 600 lokaties 6600 werknemers De markt is in beweging, actie is vereist! Estro Groep
Doel: kostenreductie door schaalvergroting en verhoging van efficiency per 1 janari 2012 Hoe: Centralisatie van stafdiensten in een Shared Service Center (SSC). Centralisatie van ICT middelen en beheer Samenvoegen van meerdere financiele administraties in een Aanleiding van het project
Fasering Elan UK B4Kids Octopu s Catalpa Kiddy World
Fasering Elan UK B4Kids Octopu s Catalpa Estro Services Kiddy World
Fasering Estro Services
Doelstellingen Faciliteren van applicatie en infrastructuur consolidaties Faciliteren van acquisities Faciliteren van verwachtte wijzigingen in het applicatie landschap (vervanging van applicaties) Reductie van handmatige import/export Afgerond: SSC project, FIM, SharePoint, tijdschrijven, verlof, kasboek Onder handen: integratie nieuwe bedrijven, portals, consolidaties Wat doen we met BizTalk
Distributie van stamgegevens (pub/sub) Verwerken van transacties (asynchroon) Uitvoeren systeem overstijgende processen (async) EAI van en naar backend applicaties EDA & pub/sub over de applicaties heen WCF services buiten BizTalk om in IIS (raadplegen) Wat doen we met BizTalk
IT werkplek ICT beheerprocessen inclusief beheertools VPPCRMFinanceHRMOverige Service bus (gegevensuitwisseling, procesbesturing over applicaties heen) Generieke faciliteiten (netwerk, intranet, fileservers, mailservers etc.) Hosting (ASP, SAAS, Cloud etc.) Applicatie distributie Scope infra project Internet (websites + portal) Scope applicatie Integratie en services project = gegevensuitwisseling= gebruiker werkt met applicatie
BizTalk applicaties
Medewerker en OE interfaces
Kasboek interfaces
Verlof en tijdschrijven
Onderwerp: applictie partitionering Aanpak: per backend systeem 1 BizTalk applicatie Issues: Pro: lijnt vaak uit met systeem eigenaars en cycli Pro: beperkt aantal applicaties met duidelijke samenhang Pro: na vaststellen van canonical (contract binnen ESB) is parallel ontwikkelen mogelijk Con: voor end-to-end processen moeten meerdere apps aangepast worden Con: wijzigingen aan het canonical raken meerdere apps en vereisen redeploy van de hele omgeving Vraag: Hoe doen jullie dit? Vragen aan jullie (1)
Onderwerp: detecteren van wijzigingen in backend die dit niet zelf als event kan publiceren Aanpak: triggers en/of change tracking toevoegen Issues: Teveel berichten in de service bus Detectie van relevante wijzigingen lastig zonder veel specifieke code Vraag: Hoe doen jullie dit? Vragen aan jullie (2)
Vragen?