SOA Governance Is Not IT Governance Reborn

Selvom jeg normalt taler for mere forretningsorientering i IT, og selvom jeg også synes, at det er de forretningsmæssige fordele der gør SOA rigtig interessant, så skal vi dog ikke spille IT helt ud af banen.

Under alle omstændigheder kommer man jo hurtigt til at skulle træffe nogle forskellige valg, som bygger på de konkrete muligheder i forhold til den givne Informations Teknologi. Og da Version2 jo er et sted for teknikere – kunne vi jo stille spørgsmålet: Hvad kan IT siden gøre, for at understøtte SOA governance?

Nu sidder jeg på leverandørsiden. I vores virksomhed – hvor vi udvikler software til forbedring af datakvalitet - har vi valgt at udgangspunkt i det programmel, som vi har udviklet gennem mange år. Dette programmel er gennemprøvet og dækker en række forretningsmæssige behov. De enkelte funktioner er nu gjort tilgængelige som SOA komponenter samtidig med, at man via funktionalitet som kan implementeres centralt kan skabe og vedligeholde de regler, som komponenterne anvender.

Det spændende er nu, at vi kan indgå i en dialog med aftagere af disse tjenester om, hvilke af de udtrykte udfordringer i forretningen disse tjenester kan løse og hvilke regler og andre opsætninger, der vil være det mest optimale – og dette kan ske uden at være dybt afhængige af alle de andre gode leverandører, der løser alle de andre udfordringer.

Der er ingen tvivl om at service-orientering udsat for IT-governance giver meget lidt mening. Men jeg synes nu stadig at SOA betegnelsen anvendes ret uklart. Er det forretningsarkitekturen eller IT-arkitekturen vi udsætter for service-orientering i SOA? (eller begge dele?). Svaret afhænger vist af øjnene der ser....

Har skrevet lidt mere om det her:
http://www.enterpriseagility.dk/?p=14

@Henrik:
"De enkelte funktioner er nu gjort tilgængelige som SOA komponenter"

Hvad er SOA komponenter? Det lyder for mig som om i "bare" udstiller jeres funktionalitet som services? (forhåbentlig med noget af det som meta-data). Hvori opstår arkitektur-delen?

@Lars: Faktisk laver vi netop som leverandør ikke arkitektur overhovedet – men udstiller ”bare”. Det bliver så til SOA komponenter, når det hos aftageren indgår som en værdifuld tjeneste i en større sammenhæng. I vores tilfælde – hvor vi forbedrer indholdet i en eksisterende form, ved at kontrollere data, transformere data og fremfinde data i eksisterende strukturer – behøver der ikke engang at indgå nye metadata - det kommer an på de respektive tjenester.

Alternativet i en traditionel ”produkt og platform orienteret arkitektur” er, at vi enten skal lave aftaler med de enkelte andre leverandører om at inkludere vores komponenter i deres produkter eller at vi skal installere en import og eksport løsning ved siden af.