Tilstede Hakon gruppen Systek Ragnvald Blindheim, CTO for ICA Ahold Bjørn Sloth Johannes Brodwall, Arkitekt Aaron Sevivas, Arkitekt

Organisasjonsmessige behov ICA/Hakon/ICA Ahold har vært gjennom mange fusjoner Selskapet eies nå 50% av Ahold (verdens 3. største eier av matvarer, etter Walmart og ...? Nederlands) IT organisasjonen er flyttet opp i ICA Ahold, og skal få systemene til å virke sammen (synergier) IT satsningen bør kunne virke sammen med Aholds andre forretninger i framtiden

ICA Ahold organisasjon Gamle eiere av ICA (Sverige) Verdenes 3. største holding-selskap innen dagligvarer. Beholder lokale brands. Eier mange forretning i Europa og USA Stein Erik Hagen

IT Arkitektur En åpen arkitektur – integrasjon mot eksisterende systemer, Ahold systemer J2EE – utprøvd teknologi Bruker webMethods som broker i en Asynkron XML basert Løst koblet Meldingsdrevet arkitektur Min observasjon: Sessions’ Software Fortress

ICA Ahold arkitektur (presentert av Ragnvald) Etc. Integrasjon Presentasjon Forretning Data Workflow-baserte systemer Asynchronous XML messaging Kampanjer Integrasjon Presentasjon Forretning Data Message Broker (webMethods) Assortement Integrasjon Presentasjon Forretning Data Pricing Integrasjon Presentasjon Forretning Data

Problemer: Sentrale Fortress-basert arkitektur har mange utfordringer Synkronisering av data (replikering) Riktig oppdeling i fortresses Teknologiske vanskeligheter Ingen referanseprosjekter Vanskelig å bruke teknologiene Vanskelig å fase inn nye løsninger som erstatter eksisterende systemer Andre systemer som ikke skal byttes ut har avhengigheter Mange problemer med meldingshub er pga ”essensiell kompleksistet” med samspillende, autonome systemet

Dedikert database (replikerer data fra andre fortress) Pricing MVC/Struts Presentasjon Integrasjon J2EE basert Forretning JDO (ikke krav) Data Dedikert database (replikerer data fra andre fortress)

Problemer: Fortress Tar for lang tid å utvikle J2EE er ikke produktivt Lurer på om det var riktige valg Standardisert arkitektur ønskelig (Vanskelig å følge opp) Sårbar for teknologiske endringer Feil, mangler, og inkompabilitet i servere

Notat: Mine anbefalinger for et fortress Kommunikasjon kun via presentasjon og integrasjon Aldri be om data (reaktor), selv ikke fra andre systemer under request-håndtering Autogenerer integrasjon -> database replikering basert på metadata Integrasjon inn: Kun til database/DAO Integrasjon ut: Trigges av businesslogikk, betjenes asynkront (men sikkert) fra integrasjonslag mot database Legg opp til at enkelte fortress kan ha unik arkitektur: Integrasjonsfortress (midlertidig) og teknologi-eksperimenter

Notat: Fortress: Design anbefaling Portlets eller tilsvarende sikrer presenasjon-integrasjon mellom fortress Asynchronous Session beans (eller annen teknologi) Bør autogenereres i så stor grad som mulig change Signal Services DAO, Entity Beans eller JDO Broadcast changes RDBMS-OO Replicate incoming objects

Konklusjoner MDA og OptimalJ kan løse mye av problemene med utvikling av uavhengige fortress Med en så omfattende arkitektur kan det være verdifullt å utvide OptimalJ for å generere mer av fortresset Produktivitet Interoperabilitet (teknologiendringer og legacy) Kvalitet (kan håndheve arkitektur) Vi har liten tro på at OptimalJ vil hjelpe mye på de sentrale problemene Ragnvald var veldig interessert i MDA og OptimalJ En demonstrasjon med flere fra ICA holdes 11. september