Smidig utfordring til «databasefolket»

Scott Ambler er oppgitt over dårlige databaser, men mest over at ingen gjør noe med dem.

Scott Ambler er blant de mest taleføre forkjempere for «smidig utvikling» eller «agile method». I korte trekk går metoden ut på å dele et utviklingsprosjekt i korte etapper med klare mål, trekke kunden (brukeren) med i hver etappe, og sette kode i produksjon så fort som mulig. Dette gjøres i stedet for «vannfallsmetoden» der kunder presenterte detaljerte kravspesifikasjoner, og kommer tilbake etter et år eller to for å se resultatet.

Ambler var i Norge i slutten av mai: Han dokumenterte hvordan den smidige metoden både sparer ressurser og gir raskere resultater enn vannfallsmetoden. Han var invitert hit av konsulentselskapet Bouvet, et av flere som sliter for å få kunder, særlig innen offentlig sektor, til å innse fordelene med smidig utvikling.

    Les også:

Et av de nyeste tilskuddene til den smidige metode, er noe Ambler kaller «Agile Data Method».

– Her beskriver vi hvordan databasestyrere kan bli mer effektive. Vi mener databasefolket til en viss grad ikke er funksjonelt. De er mer opptatt av politikk enn å få gjort jobben. Ingen av dem tar et skritt tilbake for å betrakte helheten og tenke over hva som skjer.

Blant «databasefolkets» forsømte oppgaver er kvalitetssikring.

– Data er en av bedriftens viktigske eiendeler. Da må man teste for å sikre at data holder tilstrekkelig kvalitet. Mange som driver med databaser snakker mye om kvalitet, men gjør lite for det, og de tester ikke. Resultatet er at ingen har en god database, og man har heller ingen plan for å rette opp forholdet. Denne situasjonen vil snart endre seg.

Ambler ser en konflikt mellom databasefolkene og «objektfolkene».

– Databasefolkene kjemper for å få lagrede prosedyrer inn i databasene. Men de gjør ingen god jobb med å skrive dem, og de tester ikke.

Å bytte navn på et felt (en kolonne) er ifølge Ambler trivielt.

– Tar du opp dette med databasefolk, roper de at det ikke går an, fordi du ødelegger for 50 applikasjoner. Men poenget er at det er trivielt. Noen få har bygget databasen for at det skal være enkelt. De andre har ikke funnet ut av det ennå. Når utviklerne ber om en ny kolonne i databasen, tar det databasestyrerne to måneder å følge opp.

Det er et stort behov for gjøre databaser mer smidige, mener Ambler. Man må kunne legge om databaser like raskt og enkelt som man legger om eller utvider applikasjoner. Men hans opplevelse er at databasestyrerne oppfatter «sin» database som ferdig kravspesifisert en gang for alle.

– Vi som står for den smidige metoden, er i ferd med å arbeide fram den smidige datametoden. Vi gjenoppfinner alt som har med data å gjøre, og vi er i gang med å utvikle egne verktøy for å håndtere databaser på en mer smidig måte.

Det engelske faguttrykket for smidig omstrukturering av databaser er «refactoring». Ambler har allerede skrevet boka Refactoring Databases. Han lover verktøy innen to år.

Verktøyene vil også omfatte det andre ankepunktet Ambler har mot databaser: Manglende testing.

– Databaser bør være i stand til å teste det de lagrer, for eksempel lagrede prosedyrer. Men det er vanskelig å vinne gehør for testing i forbindelse med databaser. Jeg var på en konferanse hos Oracle for en måned siden, og bare ett innlegg utenom mitt tok opp testing. Går du på Java-arrangementer, snakker alle om testing.

Ambler lover følgelig at det også vil komme verktøy for testing av databaser.

På ett punkt bøyer Ambler seg for databasefolkets kompetanse.

– De kan det med inn- og utdata. Java-folket har ingen forståelse for det, og applikasjonene er ofte håpløse når de skal hente og lagre data.

Et poeng for Ambler er at det må komme bedre kontakt og større fellesskap mellom databasefolket og utviklerne, slik at alle kan dra nytte av smidig utvikling, og samtidig oppnå en effektiv og hensiktsmessig håndtering av data.

Til toppen