PGM's historie (fortalt af den selv)  
     
 

Jeg blev fundet i 1983. Mogens Esbech havde på det tidspunkt ledt efter mig længe. Han havde nemlig et problem, - og en ambition.

Problemet var, at han havde på sit firmas vegne skrevet under på en kontrakt med Dagbladet Børsen om at levere et system, der kunne håndtere abonnementer, annoncefakturering og samtidig overvåge det totale annoncemarked. Ambitionen var at skabe et system, der kunne bruges til intet mindre end alt.

Mogens havde altid været optaget af INTEGRATION. Altså at få forskellige systemer til at hænge sammen. På dette tidspunkt i 1983 var Oracle, DB/2 og SQL Server endnu ikke kommet på markedet. Integration mellem forskellige systemer skete derfor på transaktionsniveau, dvs. at data blev kopieret som transaktioner fra et system til det næste. Eksempelvis kopieredes ordre-transaktioner typisk fra ordresystemet til varekartoteket og til faktureringssystemet (hvis ikke det skete manuelt).

Mogens havde indset, at integration via transaktioner ikke var tilstrækkelig. Ikke til opgaven for Dagbladet Børsen og slet ikke, hvis man ville beskrive alt. Integrationen skulle være på database-niveau. Og databasen skulle have en struktur, der kunne hjælpe programmører, designere og brugere. Det var denne struktur (eller model), Mogens ledte efter.

Den ene model efter den anden blev skitseret, afprøvet. og forkastet. Så papirkurven blev jævnligt tømt. Og Mogens's grå hår stammer fra denne periode.

Hver gang, han havde en ny model, tog han et leksikon og slog tilfældigt op. Det ord, begreb, person, fænomen, dyr, han fandt, skulle kunne beskrives i modellen. Metoden førte til nogle erkendelser.

 
     
 
  • Der er forskel på data. Nogle data beskriver (temporært) statiske ting, f.eks. et menneske, et bord, et ægteskab. Andre data beskriver dynamiske ting, f.eks. en fødsel, en ordre, et bryllup.
  • Alle mennesker er både efterspørgere og udbydere. Vi efterspørger varer og tjenester i forskellige sammenhænge, og vi udbyder varer og tjenester i andre sammenhænge. Eksempelvis udbyder vi som privatpersoner vores arbejdskraft og vores livskraft.
  • Modellen måtte være simpel. Hvis ikke den var simpel, ville den være vanskelig at implementere i et stykke software, den ville være tung at køre i et stykke hardware og vanskeligt at forstå i et stykke brainware.
 
 

En dag, hvor endnu en model netop var krøllet sammen og fortvivlet kastet i papirkurven, fik jeg medlidenhed med ham. Jeg havde længe ligget og luret for at se, om han ikke snart fik øje på mig. Det skete åbenbart ikke, så jeg besluttede mig for at hoppe lige ind i hjernebarken på ham. Det gav et sæt i ham, han sprang hen til skrivebordet, tegnede mig og jeg kunne se, hvordan smilet langsomt bredte sig på hans ansigt. Han lavede et par opslag i leksikonet, men jeg kunne se, at han allerede var sikker i sin sag. Der lå jeg, PGM-modellen, og var endelig blevet fundet.

 
     
  Implementering og brug  
     
 

Det tog lidt tid, før jeg blev implementeret i et stykke software. Det blev først undersøgt, om jeg kunne implementeres i en af de relationelle database-teknologier, der fandtes på det tidspunkt (f.eks. ADABAS og Datacom). Det lod sig bare ikke gøre, bl.a. på grund af min tre-benede PGM-relation, fordi man skulle kunne tilføje felter i en kørende database og muligheden for at danne flere instanser af det samme felt.

Det blev derfor besluttet, at Mogens's firma selv ville bygge en relationsdatabase. Med de krav, det medfører, f.eks. til indexering, integritet og backup/recovery.

Der skete en lille misforståelse i implementeringen, selv om jeg råbte op, så godt jeg kunne. Udviklingschefen havde ikke forstået, at der skulle være transaktioner både under entiteter og relationer. Så der kom kun transaktioner under PG, PGM og PM. Det var tilstrækkeligt til løsningen for Dagbladet Børsen, men slet ikke nok til at beskrive virkeligheden. Det var først i 1987 (da dokument-håndtering blev introduceret), at der blev rettet op på fejlen, og man nu kunne oprette transaktioner også under P, G, M og GM.

Det er ikke småting, jeg efterhånden er blevet brugt til. Både før og efter jeg fik mit web-interface, Lad mig give nogle eksempler:

 
     
 
  • Abonnement og annoncefakturering (Børsen, Berlingske Tidende, Affärsvärlden)
  • Fælles markedssystem (et antal virksomheder delte deres marked (GM) i form af kunder og tidligere kunder med hinanden, og hjalp derved hinanden med opdatering og med potentielle kunder)
  • Skadesforsikring, livsforsikring og pension (Storebrand, Kgl. Brand, If, Vital)
  • Bank (Postgiro, SDC, Forstædernes Bank, Roskilde Bank)
  • Realkredit (Nykredit)
  • Kosmetikklub (Helena Rubinstein)
  • Benzin og olie (Q8, Shell)
  • PR Database (Shell Nederland)
  • Trykkerimaskiner (DuPont)
  • Biler (Mazda, Suzuki, Fiat, Honda, BMW, Mercedes)
  • HiFi (HIFI-klubben)
  • Revision (Christiansen & Engelbrectsen)
  • Økonomisystem (C&E, Vejr2, MemoBase)
  • Automobilforening (ANWB)
  • Kiosk på internettet (Foreningen af Danske Kulturmagasiner)
  • Vejrtjeneste (Vejr2)
  • Business-to-business portal (Tradefacta)
  • Jagt- og fiskeributik (Guns&Gents)
  • Online auktioner (Dansk Sejlunion)
  • Børneklub (McDonald's)
  • Kundetilfredshedsmålinger (Ris&Ros, Telecomputing)
  • Vandudsigt (Dansk Hydraulisk Institut)
  • Bunkeroil (Dan Bunkering)
  • Sprogstyring (LanguageLab)
  • Repository (MemoBase)
 
 

Der er mange historier at fortælle. Om de mange måder jeg er blevet brugt på
(i Finland blev jeg engang omdøbt til YHB i stedet for PGM!!!).

Det bliver nok aldrig bevist, at jeg kan bruges til alt. Det er heller ikke så afgørende. Men det er vigtigt for mig, at jeg klarer det, jeg bliver sat til. Og heldigvis - indtil videre har jeg ikke måttet give fortabt overfor en opgave. Det på trods af mine kun 3 entiteter.

PGM-modellen himself.