Tilstede

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

2. 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

3. 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

4. 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

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

6. 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

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

8. 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

9. 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

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

11. 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