Fælles SOA-datamodel - eller glem SOA.

En fælles datamodel for en given organisation er et krav for SOA kan fungere i praksis ? Det er et fundamentalt krav for interoperabilitet.

Jeg pointerer ofte vigtigheden af en fælles datamodel i en SOA, men bliver ofte mødt med overbærende smil og kommentaren:
'Den sang har vi hørt mange gange før, vi har forsøgt, og det kan ikke lade sig gøre'.
Og jeg er jo nødt til at give dem ret, det er stort set umuligt at lave en fuld datamodel for en hel organisation. Af de mange problemer der kan listes i denne sammenhæng, er tidsfaktoren nok den største. Det tager så lang tid at lave modellen at den allerede er forældet inden den er færdig.

Så hvis påstanden er, at en fælles datamodel er en forudsætning for SOA's succes, er der vel et problem' Helt klart? hvis det ikke var fordi at SOA ændrer den måde man kan arbejde med den fælles datamodel.

Der er nogle helt fundamentale forskelle i forhold til'normal' relationel data modellering: 

  • Domæner

    En datamodel i en SOA kontekst er en model på et højere niveau - domæner. I realiteten er det kun data der kommunikeres på tværs af domæner der er interessante. En fælles SOA datamodel har ikke til formål at modellere alle data i organisationen.

  • Beskeder

    SOA opererer med Services der udveksler hierarkisk opbyggede beskeder. Den fuldt modelerede relationelle model har mindre værdi i denne sammenhæng. Fokus er på de enkelte begreber hvoraf beskeder kan bygges. OIOXML er et godt eksempel herpå.

Så buttom line: jeg vil stå ved min påstand om, at en fuldt specificeret datamodel er en forudsætning for succesfuld SOA, men at man naturligvis skal ændrer sin måde at modellere på. SOA er et paradigmeskifte, og kræver en udvikling af de metoder vi allerede har.  
 
Så den klassiske kommentar - 'SOA er ny vin på gamle flasker'' Ja gu' er det så, vi skal stadigvæk udvikle systemer der understøtter forretningen, men SOA-paradigmet kommer med nogle muligheder, der kræver at vi udvikler de metoder og værktøjer vi kender og bruger. Så kan det jo være at faktisk kommer tættere på at kunne håndtere nogle af de ting vi har forsøgt før?

Kommentarer (6)
Anders H

(det virker som om du har byttet om på dine to overskrifter)
- Domæner: Det virker som om, du prøver at sige at SOA er til besked udveksling, mens databaser er til lagring. Det er ikke klart hvorfor det skulle give en forskel. Data skal jo udveksles med databasen for at kunne lagres og det gøres jo i samme datamodel, som data bliver lagret i. Omvendt vil en del kommunikation i en SOA jo handle om data, der er lagret i en eller flere databaser.
- Beskeder: Her lader det til, at du mener, at man i en SOA bygger sine beskedtyper op af allerede definerede fragmenter i modsætning til databaser, hvor man skulle have frihed til at begynde fra ren tavle hver gang. Det er naturligvis forkert. Der er vel ikke rigtig noget i en virksomhed med så lang levetid som datamodellen i databasen. Det man i en SOA vil udtrykke via hirakier i beskeder, er jo det samme som man i en RDB vil udtrykke via domæner for typer, referencer mellem relationerne, og nogle gange blot navngivning. Så at genbruge typer i nye beskeder, svare blot til at bruge fremmednøgler til eksisterende tabeller i en database. I en SOA besked vil man måske være fristet til at dele typen op i flere niveauer, hvilket kunne svare til at udnormalisere i flere tabeller i en database (man vil måske se person.name.first og person.name.last i en SOA besked i stedet for person.name i en database eller person.address.postalarea.code i stedet for person.zipcode). Men dette mener jeg højst er en lidt ændret tærskelværdi for hvornår man vælger at udnormalisere ikke ligefrem en fundamental forskel.

Hvis det har været et problem at få lavet en god datamodel hurtigt, har det nok snarere skyldes, at de skræddere, der har været på sagen har skulle finde den helt rigtige tråd til de nye klæder.

Rasmus Knippel

Tak for din kommentar. Jeg vil i det følgende forsøge at kommentere retur:

  • Domæne
    Tror vi ”taler” lidt forbi hinanden p.g.a. fortolkningen af Domæne (burde nok have uddybet lidt). Det jeg mener her, er mere i forhold til forretningsmæssige domæner. Et godt eksempel er f.eks. HR (Human resource). Inden for et domæne vil der blive udvekslet en mængde data, der aldrig vil komme uden for f.eks. HR-domænets grænser. Mit argument er så, at ud fra et SOA perspektiv, er det kun de data der udveksles ud af et domæne, der skal indgå i den fælles SOA datamodel. Inden for det givne domæne, er der således frihed til at modellere og gemme data som det vurderes bedst indenfor domænets grænser.

  • Beskeder
    Først lige skal jeg pointere, at jeg er helt indforstået med, at der vil eksistere en datamodel i de bagvedliggende databaser. Jeg tror dog, at vi her igen taler forbi hinanden p.g.a. at jeg ikke havde forklaret hvad jeg mente med Domæne (min fejl).

Med hensyn til din sidste kommentar, om at kunne lave en datamodel hurtigt, er jeg ikke enig med dig. Dette kan dog være fordi vi fortolker fælles datamodel forskelligt. Med fælles datamodel mener jeg den fulde datamodel for en organisation (en Enterprise Data Model), og ikke en given applikation. Problemet med at skabe en sådan for store virksomheder (eller f.eks. en kommune) er, at man ikke når at blive færdig før datamodellen har ændret sig.

Så med hensyn til at lave en hurtig datamodel mener jeg ikke, at det kan lade sig gøre i større organisationer. Min pointe er så med min post, at man med SOA kan hæve abstraktionsniveauet, således, at man kan lave en fælles SOA datamodel der kun vedrører de data der udveksles mellem domæner – og modellere lokalt inden for de enkelte domæner.

En udfordring ved denne fremgangsmåde er naturligvis, at de domæner man definerer, ofte vil gå på tværs af den silo-struktur de fleste organisationer er indrettet efter – både i forhold til organisation og systemer.

Anders H

Hvorfor siger du nu i overskriften, at der ikke er nogen fundamentale forskelle? Har du allerede skiftet holdning?

Jeg tror, ikke vi taler forbi hinanden. Jeg antog, du med "domæne" mente det samme "domæne", som man finder i "domænespecifikke sprog" og det lader stadig til at være korrekt.

  • Domæne - Du har stadig ikke begyndt at motivere hvorfor der skulle være forskel på at modellere beskeder frem for databaser.

  • Beskeder - Nej, det lod ikke til at vi talte forbi hinanden.

Hvis man skal løse et meget stort problem, er det jo gammelkendt metode, at dele det op i mindre dele og løse dem hver for sig, men sådan at de stadig spiller sammen. Det gøres også inden for databasemodellering. Min sidste kommentar gik mere på at jeg har set store, højt betale udviklingshuse være meget lang tid om at lave noget makværk (og nogle af resultaterne finder man på OIOXML).

Rasmus Knippel

Grunden til at jeg pointerer at det er en evolution er netop i overskriften er, som du selv pointerer, at vi stadigt skal bruge den viden og de metoder vi har – det er ikke nogen fundamental forskel, men blot en evolution.

Og ja, jeg giver dig helt ret i, at det er en gammelkendt metode at opdele store problemer i mindre bidder. Mit argument er dog her, at man nu også kan have en Enterprise Datamodel baseret på de beskeder der udveksles mellem domæner, og resten af datamodellen defineres lokalt i det enkelte domæne.

Med hensyn til at modellere beskeder, giver jeg dig igen ret i man bør genbruge de modelleringsmetoder man har – forskellen er blot hvordan man betragter det der skal modelleres – hvad skal med og hvad skal ikke med.

Og med hensyn til din sidste kommentar… Helt enig.

Martin Rytter

Idealet om at etablere en fælles datamodel for en hel organisation er sjældent realistisk. Man bør naturligvis stræbe mod dette mål, som man altid bør stræbe mod simple løsninger. Jeg for så vidt vi er meget enige her.

Men hvordan er det lige ude i virkeligheden? I virkelighedens verden har organisationer mange systemer. Nogle systemer retter man ikke bare i. Nogle systemer er udviklet af 3th parties. Nogle er udviklet inhouse.

Jeg har stadig til gode at se et eneste eksempel på vellykkedet "design it all up front" hvor problemområdet har været bare nogenlunde komplekst (dermed ikke sagt at man ikke skal bruge tid på at tænke sig om).

I stedet for at tale så meget om SOA burde vi tale noget mere om integration i mere bred forstand. Læs fx "Enterprise integration patterns" [hohpe&woolf]. Her er mange kloge ord og ikke så meget hype (hvilket man ellers ofte støder på om dette emne).

Udfordringen ved at integrere systemer er netop ofte at systemer er forskellige. Integration handler om at få ting til at virke alligevel.

Peter Gaarde

Jeg kunne ikke være mere enig i vigtigheden af en fælles datamodel, men at kalde den det, mener jeg er helt hen i vejret.

Informationsarkitektur eller begrebsmodel er mere passende, og ligger også op til at det ikke er en ting underlagt udviklere og den kørende teknologi. En fælles forståelse for virksomhedens begreber er essentielt for bl.a. SOA (men ikke kun!).

Jeg er så enig med Rasmus i at niveauet skal hæves (også en grund til at støde datamodel ordet langt væk), da en sådan model ikke bør være teknologi eller database afhængig. I sin mest detaljerede form kan den indeholde oplysninger om hvordan begrebet kan udveksles som eks xml, hvorfor modellen/arkitekturen bliver anvendelig i SOA´en.

Men det er ekstremt vigtigt at det er forretningen der ejer informationsarkitekturen, og at den aldrig bliver implementeringsspecifik.

Alt for længe har udviklere defineret virksomheders samlede IT-understøttede viden udfra ideer om performance og acessibility. Nu er det tid til at forretningen tager ansvar for den, og en fælles informationsarkitektur er i sig selv ligeså vigtig som virksomhedens teknologiarkitektur.

Til Martin Rytter: Ved at gøre informationsarkitekturen/begrebsmodellen teknologiuafhængig ryger man ikke i de problemer omkring underliggende systemer, og information bliver faktisk styrende for udviklingen af services, og ikke omvendt. Som gammel bibliotekar passer det mig rigtig godt...

Mht til det du siger omkring integration har du helt ret, det er bare som om alt skal pakkes ind i en sætning med SOA i disse dage. Morgenthal har også skrevet en god bog om emnet "Enterprise Information Integration".

Log ind eller Opret konto for at kommentere